On Wed, 29 Nov 2023 02:25:20 GMT, Mikael Vidstedt wrote:
> When building linux-aarch64 at Oracle using jib,
> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
> building natively or cross compiling (on linux-x64). Among other things this
> has the (harmless) effect of
On Wed, 29 Nov 2023 06:45:17 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change will attempts to workaround an issue
> in dsymutil?
>
> The previous attempt to use `--reproducer Off` has shown that it fails to
> build on some other Xcode versions other than 14.3.1. Users have
Can I please get a review of this change will attempts to workaround an issue
in dsymutil?
The previous attempt to use `--reproducer Off` has shown that it fails to build
on some other Xcode versions other than 14.3.1. Users have reported it to fail
on Xcode 15.0.1 and Xcode from a 12.4
On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote:
>> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved.
>>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved.
>>
>> Is
When building linux-aarch64 at Oracle using jib,
--openjdk-target=aarch64-linux-gnu is always specified regardless of if
building natively or cross compiling (on linux-x64). Among other things this
has the (harmless) effect of tricking configure into thinking that it's cross
compiling even for
> The goal is to develop faster sort routines for x86_64 CPUs by taking
> advantage of AVX2 instructions. This enhancement provides an order of
> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>
> For serial sort on random data, this PR shows upto ~7.5x
On Tue, 28 Nov 2023 21:48:13 GMT, Erik Joelsson wrote:
> This is a backout of
> [JDK-8320863](https://bugs.openjdk.org/browse/JDK-8320863). That fix only
> works on a very limited selection of Xcode versions, and is causing the build
> to fail on other versions, including at least 12, 13 and
On Tue, 28 Nov 2023 21:48:13 GMT, Erik Joelsson wrote:
> This is a backout of
> [JDK-8320863](https://bugs.openjdk.org/browse/JDK-8320863). That fix only
> works on a very limited selection of Xcode versions, and is causing the build
> to fail on other versions, including at least 12, 13 and
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Build changes look good.
-
Marked as reviewed by erikj (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1754115586
This is a backout of
[JDK-8320863](https://bugs.openjdk.org/browse/JDK-8320863). That fix only works
on a very limited selection of Xcode versions, and is causing the build to fail
on other versions, including at least 12, 13 and 15.
-
Commit messages:
- Revert "8320863: dsymutil
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Tue, 28 Nov 2023 00:08:00 GMT, Srinivas Vamsi Parasa
wrote:
>> src/hotspot/share/opto/library_call.cpp line 5391:
>>
>>> 5389: BasicType bt = elem_type->basic_type();
>>> 5390: // Disable the intrinsic for 64-bit types with AVX2
>>> 5391: if ((bt == T_LONG || bt == T_DOUBLE) &&
On Tue, 28 Nov 2023 12:25:57 GMT, Jatin Bhateja wrote:
>> src/hotspot/share/opto/library_call.cpp line 5448:
>>
>>> 5446: BasicType bt = elem_type->basic_type();
>>> 5447: // Disable the intrinsic for 64-bit types with AVX2
>>> 5448: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) {
On Tue, 28 Nov 2023 12:23:00 GMT, Jatin Bhateja wrote:
>> Srinivas Vamsi Parasa has updated the pull request with a new target base
>> due to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains 11
>>
> The goal is to develop faster sort routines for x86_64 CPUs by taking
> advantage of AVX2 instructions. This enhancement provides an order of
> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>
> For serial sort on random data, this PR shows upto ~7.5x
On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan
wrote:
>> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors
>
> Yes, Vamsi is part of Intel Java team. He also has the author status
> (https://openjdk.org/census#sparasa).
> @sviswa7 I am asking about the copyright
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Tue, 28 Nov 2023 17:04:30 GMT, Magnus Ihse Bursie wrote:
> In quite a few places we are using the late evaluation assignment `=` instead
> of normal assignment `:=` in spec.gmk.in.
This pull request has now been integrated.
Changeset: adad1320
Author:Magnus Ihse Bursie
URL:
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Tue, 28 Nov 2023 17:04:30 GMT, Magnus Ihse Bursie wrote:
> In quite a few places we are using the late evaluation assignment `=` instead
> of normal assignment `:=` in spec.gmk.in.
Marked as reviewed by erikj (Reviewer).
-
PR Review:
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
On Tue, 28 Nov 2023 14:29:25 GMT, Magnus Ihse Bursie wrote:
> To facilitate running make in the build configuration directory, we create a
> Makefile out of a template. Unfortunately, this references the real Makefile
> at $TOPDIR instead of $WORKSPACE_ROOT. They are normally equivalent, but
In quite a few places we are using the late evaluation assignment `=` instead
of normal assignment `:=` in spec.gmk.in.
-
Commit messages:
- 8320767: Use := for non-recursive assignment in spec.gmk.in
Changes: https://git.openjdk.org/jdk/pull/16859/files
Webrev:
Over the year, even though we have tried to be diligent, there have been
commits that modify files without updating the copyright year. Here is a mass
update of the copyright years in the build system (`make/**`, `.github/**`).
Feel free to verify that these files have indeed been modified in
On Tue, 28 Nov 2023 14:29:25 GMT, Magnus Ihse Bursie wrote:
> To facilitate running make in the build configuration directory, we create a
> Makefile out of a template. Unfortunately, this references the real Makefile
> at $TOPDIR instead of $WORKSPACE_ROOT. They are normally equivalent, but
> In theory, you can run "make install" on a newly built JDK to have it
> installed in /usr/local/bin, just as with many system tools.
>
> This is not recommended to do. You might mess up your boot JDK, and Java
> installations generally do not work like this. (Instead, you are likely to
>
On Mon, 27 Nov 2023 14:43:09 GMT, Magnus Ihse Bursie wrote:
> In theory, you can run "make install" on a newly built JDK to have it
> installed in /usr/local/bin, just as with many system tools.
>
> This is not recommended to do. You might mess up your boot JDK, and Java
> installations
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes
On Tue, 28 Nov 2023 14:32:14 GMT, Pavel Rappo wrote:
> Please review this PR to support _JEP 463 Implicitly Declared Classes and
> Instance Main Method (Second Preview)_ in JavaDoc.
>
> [JEP 463](https://openjdk.org/jeps/463) is the next iteration of [JEP
> 445](https://openjdk.org/jeps/445),
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes
Please review this PR to support _JEP 463 Implicitly Declared Classes and
Instance Main Method (Second Preview)_ in JavaDoc.
[JEP 463](https://openjdk.org/jeps/463) is the next iteration of [JEP
445](https://openjdk.org/jeps/445), which introduced the ability to have a
source file as a
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes
To facilitate running make in the build configuration directory, we create a
Makefile out of a template. Unfortunately, this references the real Makefile at
$TOPDIR instead of $WORKSPACE_ROOT. They are normally equivalent, but if you
are using custom additions, they might not be.
-
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes
On Tue, 21 Nov 2023 14:42:07 GMT, Kevin Rushforth wrote:
> At some point we are likely to use stabilization branches in the mainline jdk
> repo rather than a separate repo. In preparation, this PR excludes branches
> matching `jdk*`, like we currently do for `master` and `pr/*`.
>
> A
On Tue, 28 Nov 2023 12:23:12 GMT, Jatin Bhateja wrote:
>> Srinivas Vamsi Parasa has updated the pull request with a new target base
>> due to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains 11
>>
On Sat, 18 Nov 2023 01:21:09 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX2 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>>
On Tue, 28 Nov 2023 10:21:25 GMT, Per Minborg wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed SwitchBootstrapTest
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404:
>
>> (failed to
On Mon, 27 Nov 2023 10:01:50 GMT, Adam Sotona wrote:
>> Classfile API is an internal library under package `jdk.internal.classfile`
>> in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves
>> it into `java.lang.classfile`.
>> It repackages all uses across JDK
Can I please get a review of this change which proposes to workaround a bug in
`dsymutil` tool on macos?
As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
shipped in Xcode 14.3.1 has a bug which causes it to create a temporary
directories and leave them around,
On Tue, 28 Nov 2023 01:37:01 GMT, Xiaohong Gong wrote:
>>> In fact, I am not even sure why it seems to the PR author to be a good idea
>>> to let the default be dependent on the build machine at all. My personal
>>> opinion is that it would be better to select either "SVE enabled" or "SVE
>>>
On Thu, 23 Nov 2023 05:28:28 GMT, Galder Zamarreño wrote:
> FYI @theRealAph
>
> It includes a couple of commits to integrate with Capstone v6 while still
> working with Capstone v5 and before:
> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
> `CS_ARCH_ARM64`. See [this
>
44 matches
Mail list logo