This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time
frame.
It is fixing a deadlock issue between `VirtualThread` class critical sections
with the `interruptLock` (in methods: `unpark()`, `interrupt()`,
`getAndClearInterrupt()`, `threadState()`, `toString()`),
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1].
> To close
> Time to start making preparations for JDK 23.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update copyright year.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16505/files
- new:
> Time to start making preparations for JDK 23.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 21 commits:
- Merge branch 'master' into JDK-8319413
- Merge branch 'master' into JDK-8319413
- Merge branch 'master' into
On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa wrote:
>>> LGTM, thanks!
>>
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type
>> `bt`. Latest change is more complicated than it was before. Please revert it
>> back (undo last change). I will
On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa wrote:
>>> LGTM, thanks!
>>
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type
>> `bt`. Latest change is more complicated than it was before. Please revert it
>> back (undo last change). I will
On Wed, 6 Dec 2023 23:12:13 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 Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa wrote:
>> LGTM, thanks!
>
>> LGTM, thanks!
>
> Thanks Jatin!
> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`.
> Latest change is more complicated than it was before. Please revert it back
> (undo last
> 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 Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa wrote:
>> LGTM, thanks!
>
>> LGTM, thanks!
>
> Thanks Jatin!
@vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`.
Latest change is more complicated than it was before. Please revert it back
(undo last change). I
> 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 Wed, 6 Dec 2023 18:41:26 GMT, Vladimir Kozlov wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add missing header files
>
> src/hotspot/share/opto/library_call.cpp line 5393:
>
>> 5391: if
On Wed, 6 Dec 2023 17:48:04 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.
>>
> Time to start making preparations for JDK 23.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 18 commits:
- Regenerate JDK 22 symbol files.
- Merge branch 'master' into JDK-8319413
- Merge branch 'master' into
On Wed, 6 Dec 2023 18:26:34 GMT, Vladimir Kozlov wrote:
>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this
>> PR today before the fork.
>
>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this
>> PR today before the fork.
>
> Too late. Changes
On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on the Windows platform, version information are
> embedded as compiled resources into every native library and executable,
> which typically contain version numbers, copyright information, product name
> and
On Wed, 6 Dec 2023 18:05:22 GMT, Sandhya Viswanathan
wrote:
> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR
> today before the fork.
Too late. Changes looks fine to me (I am still on fence that we moving to C++
implementation of intrinsics and require latest
On Wed, 6 Dec 2023 17:48:04 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.
>>
> 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 Wed, 6 Dec 2023 17:44:25 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 Wed, 6 Dec 2023 17:42:39 GMT, Jatin Bhateja wrote:
> LGTM, thanks!
Thanks Jatin!
-
PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843372385
On Tue, 5 Dec 2023 19:19:23 GMT, Jatin Bhateja wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove unused avx2 64 bit sort functions; add assertions
>
>
On Tue, 5 Dec 2023 19:37:34 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 17
>> additional
On Wed, 6 Dec 2023 11:59:19 GMT, Magnus Ihse Bursie wrote:
>> Hi Magnus (@magicus),
>>
>>> Are you saying that when compiling with GCC 6, it will just silently ignore
>>> `-std=c++17`? I'd have assumed that it printed a warning or error about an
>>> unknown or invalid option, if C++17 is not
> 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, 5 Dec 2023 19:33:48 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 17
>> additional
On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on the Windows platform, version information are
> embedded as compiled resources into every native library and executable,
> which typically contain version numbers, copyright information, product name
> and
When building OpenJDK on the Windows platform, version information are embedded
as compiled resources into every native library and executable, which typically
contain version numbers, copyright information, product name and vendor name
(called "Company name" in this context).
Currently, the
On 12/6/23 14:35, erik.joels...@oracle.com wrote:
On 12/6/23 04:18, Andrew Haley wrote:
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sysroot=
On 12/6/23 04:18, Andrew Haley wrote:
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sysroot= usually means? In that case, you're
building against
On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie wrote:
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
>
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sysroot= usually means? In that case, you're
building against an incompatible set of libraries. By
On Mon, 4 Dec 2023 22:15:24 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, 5 Dec 2023 17:26:06 GMT, Srinivas Vamsi Parasa wrote:
>> That sounds weird. You can't check for if compiler options should be enabled
>> or not inside source code files.
>>
>> Are you saying that when compiling with GCC 6, it will just silently ignore
>> `-std=c++17`? I'd have assumed
On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
The pull request at https://github.com/openjdk/jdk/pull/16971/files has
effectively addressed the issue I was facing.
Thank you for your time and effort in addressing this matter！
Magnus Ihse Bursie 于2023年12月5日周二 18:36写道：
> On closer inspection, it would probably be more prudential to set the
>
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1].
> To close
On Tue, 5 Dec 2023 13:03:22 GMT, Magnus Ihse Bursie wrote:
>> Thanks for the suggestion @magicus !
>>
>> The check in current `lib-sleef.m4` is very common:
>>
>> - If user has specified libsleef root by '--with-libsleef', we assume it is
>> the manually built sleef lib. So only `lib/` and
On Fri, 1 Dec 2023 16:26:02 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong 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 ten additional
>>
40 matches
Mail list logo
