On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-com
On Thu, 15 May 2025 03:15:23 GMT, Ioi Lam wrote:
>> src/hotspot/share/runtime/arguments.cpp line 3060:
>>
>>> 3058: }
>>> 3059:
>>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args)
>>> {
>>
>> I don't like that we pollute `Arguments` code with AOT specific flags
>>
On Wed, 14 May 2025 06:16:15 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-com
On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-comm
On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-comm
On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-comm
On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote:
>> This is the implementation of the draft [JEP: Ahead-of-time Command Line
>> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>>
>> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
>> cache using the "one-comm
On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam wrote:
> This is the implementation of the draft [JEP: Ahead-of-time Command Line
> Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022)
>
> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT
> cache using the "one-command
On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov wrote:
> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats.
> Usually, only `Float64Vector` shape satisfies that condiditon, but
> with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well.
>
> Adjus
On Mon, 7 Apr 2025 23:20:05 GMT, Vladimir Ivanov wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java
>> line 60:
>>
>>> 58: }
>>> 59:
>>> 60: public static class X64 {
>>
>> Should we create `src/jdk.incubator.vector/cpu/` for CPU specific
>> inform
On Mon, 7 Apr 2025 23:32:05 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only symbol lookup for now. But it still en
On Thu, 10 Apr 2025 08:08:32 GMT, Aleksey Shipilev wrote:
>> Kim Barrett has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - remove timeout by using waitForReferenceProcessing
>> - make ill-timed gc in non-concurrent case less likely
>>
On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov wrote:
> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in
> JVM) to Java FFM API.
>
> Since FFM API doesn't support vector calling conventions yet, migration
> affects only symbol lookup for now. But it still enables
On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski
wrote:
>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>>
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on
>> Windows only
>> - This issue also uncovered that -Xcheck:
On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski
wrote:
>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>>
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on
>> Windows only
>> - This issue also uncovered that -Xcheck:
On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai wrote:
> Can I please get a review of this backport of
> https://github.com/openjdk/jdk/pull/23420 into jdk24?
>
> This proposes to bring in those same backouts into `jdk24` to prevent the
> issue noted in that PR description. jdk24 is in rampdown
On Thu, 28 Nov 2024 18:22:24 GMT, Aleksey Shipilev wrote:
> Found this while cleaning up x86_32 code for removal.
>
> In our current code there is a block added by
> [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373):
> https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305
On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote:
>>> With that said, it is sure as heck confusing! Which also apparently
>>> Microsoft acknowledges by phasing in the term "Windows API". So I agree
>>> that we should try to rename everything currently called "win32" into
>>> "windows"
On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote:
> With that said, it is sure as heck confusing! Which also apparently Microsoft
> acknowledges by phasing in the term "Windows API". So I agree that we should
> try to rename everything currently called "win32" into "windows". But I'd
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie wrote:
> > Bug in macroAssembler_x86.cpp - should be _WINDOWS
>
> So what does that mean? That the code is currently broken and is incorrectly
> included on Windows? If so, it should be fixed in a separate PR. Or is it
> just a stylistic issu
On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 22 Oct 2024 16:19:48 GMT, Ioi Lam wrote:
> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://openjdk.org/jeps/483).
>
>
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://gith
On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang wrote:
> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was
> based against the master from a few months ago and caused build failures on
> all platforms upon integration. The reverted commit can build again on my
> persona
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
On Thu, 19 Sep 2024 21:15:11 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam wrote:
>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> Add the following command-line options as specified in JEP 483:
>>
>>
>> - `-XX:AOTMode=off/record/create/auto/on`
On Thu, 22 Aug 2024 11:21:46 GMT, Markus Grönlund wrote:
>> Is it an implicit invariant that execution always continues in the
>> interpreter after an uncommon trap? I.e., I don't need to explicitly tell it
>> to "re-execute" there?
>
> It is updated to use Action::none to keep the nmethod. The
On Thu, 22 Aug 2024 12:10:37 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Please help review this change set that implements C2 intrinsics for
>> jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>>
>> This work is a consequence of
>> [JDK-8338417](https://bugs.o
On Wed, 21 Aug 2024 20:11:05 GMT, Markus Grönlund wrote:
> Greetings,
>
> Please help review this change set that implements C2 intrinsics for
> jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>
> This work is a consequence of
> [JDK-8338417](https://bugs.openjdk.
On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Wed, 12 Jun 2024 20:04:40 GMT, Ferenc Rakoczi wrote:
> tier1,2,3 mach5 tests all passed.
Thank you for testing.
-
PR Comment: https://git.openjdk.org/jdk/pull/19632#issuecomment-2163863932
On Wed, 12 Jun 2024 14:08:43 GMT, Ferenc Rakoczi wrote:
>> This PR removes some unnecessary conversions between byte arrays and long
>> arrays during SHA3 digest computations.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Tue, 11 Jun 2024 09:55:11 GMT, Ferenc Rakoczi wrote:
>> This PR removes some unnecessary conversions between byte arrays and long
>> arrays during SHA3 digest computations.
>
> Some microbenchmark data (the percentages are improvements in ops/sec):
> Benchmark
On Tue, 11 Jun 2024 17:30:37 GMT, Ferenc Rakoczi wrote:
>> Thank you for explanation.
>>
>> An other question. Is any other use of `longBuf` array after
>> `implCompress0()` call which load values from it? Because Intrinsic code
>> will not update it.
>
> There is no other use.. That array is
On Thu, 6 Jun 2024 17:41:20 GMT, Scott Gibbons wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright & a couple of comment typos
>
> Hi, everyone. I see that JDK 23 has now been forked, and new commits go
On Thu, 30 May 2024 16:16:45 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Thu, 30 May 2024 15:16:34 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Stupid EOL at end
>> - Add @test block; fix test indentation
>
> About the fuzzer: we have it in our closed tests.
On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 28 May 2024 16:00:10 GMT, Scott Gibbons wrote:
>> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
>>
>>> 26: * @summary Test indexOf and lastIndexOf
>>> 27: * @run main/othervm IndexOf
>>> 28: * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp
>>> -XX:-TieredCompilatio
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
Good.
-
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19427#pullrequestreview-2083281226
On Fri, 24 May 2024 19:55:40 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 24 May 2024 15:33:46 GMT, Scott Gibbons wrote:
>> Thanks for checking. Well I know that the
>> `MacroAssembler::movdqu(XMMRegister dst, AddressLiteral src, Register
>> rscratch)` method actually generates rip-relative addresses. Maybe we could
>> copy some of that code.
>
> Changed to
On Fri, 24 May 2024 15:32:26 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 24 May 2024 15:32:26 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 24 May 2024 14:49:05 GMT, Daniel Jeliński wrote:
>> Just did the experiment and it turns out that `mov64(r15,
>> (int64_t)small_jump_table)` and `lea(r15,
>> ExternalAddress(small_jump_table))` produce exactly the same code:
>>
>> `0x7fffe463d68b: 49 bf a0 d5 63 e4 ff 7f 00 00 m
On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Thu, 23 May 2024 21:50:15 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> src/hotspot/cpu/x86/stubGenerator_x8
On Thu, 23 May 2024 19:54:39 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Sat, 20 Apr 2024 22:31:48 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Sat, 20 Apr 2024 19:09:43 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Fri, 19 Apr 2024 20:54:32 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_array
On Fri, 19 Apr 2024 20:13:03 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Fri, 19 Apr 2024 15:43:17 GMT, Jorn Vernee wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add enter() and leave(); remove Windows-specific register stuff
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote:
> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of
> `StringUTF16::equals`. At the time I did some performance verification
> focused on x86 showing that simplifying and only using `StringLatin1::equals`
> was either neu
On Tue, 16 Jan 2024 23:51:15 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4111:
>>
>>> 4109: if ((UseAVX == 2) && EnableX86ECoreOpts &&
>>> VM_Version::supports_avx2()) {
>>> 4110: StubRoutines::_string_indexof = generate_string_indexof();
>>> 4111: }
>
On Thu, 11 Jan 2024 23:06:32 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
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 Fri, 8 Dec 2023 00:33:49 GMT, Srinivas Vamsi Parasa wrote:
> > Testing have only one failure in closed tests and I need to fix it before
> > this can be pushed.
>
> Thanks Vladimir for the update. Is the test failure because of this PR?
Yes. One of our test, which checks integrity of built
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 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 te
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 change). I w
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.
>>
>>
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 C+
On Tue, 5 Dec 2023 14:55:02 GMT, Viktor Klang wrote:
>> Splits GatherersTest out to distinct files per built-in gatherer
>>
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on
>> the ProblemList.
>>
>> Adding increased maxOutputSize for Gatherer-related tests to impr
On Thu, 2 Nov 2023 02:02:18 GMT, Joe Darcy wrote:
>> Due to their longer-than-typical running time and because the vector API is
>> not (yet) in the base module, move the vector API tests in tier 1 to tier 2.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit
On Wed, 1 Nov 2023 20:36:38 GMT, Joe Darcy wrote:
>> I would suggest to determine the set of tests which run "at most 10 seconds
>> total" and run only them in tier1.
>> Also taking into account API coverage.
>
>> I would suggest to determine the set of tests which run "at most 10 seconds
>> to
On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote:
> Due to their longer-than-typical running time and because the vector API is
> not (yet) in the base module, move the vector API tests in tier 1 to tier 2.
I would suggest to determine the set of tests which run "at most 10 seconds
total" and
On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote:
> Due to their longer-than-typical running time and because the vector API is
> not (yet) in the base module, move the vector API tests in tier 1 to tier 2.
jdk_vector_sanity was added to tier1 to catch issues early in GHA.
See #10879 and discu
On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work, t
On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon wrote:
> The Graal code base has
> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
> its module to `jdk.compiler.graal` as part of preparations for Project
> Galahad. Due to the way Java modules work, this
On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon wrote:
> The Graal code base has
> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
> its module to `jdk.compiler.graal` as part of preparations for Project
> Galahad. Due to the way Java modules work, this
On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to address the follow-up comments to the SIMD
>> accelerated sort PR (#14227) which implemented AVX512 intrinsics for
>> Arrays.sort() methods.
>> The proposed changes are:
>>
>> 1) Restriction of the AVX
On Wed, 11 Oct 2023 23:40:55 GMT, Sandhya Viswanathan
wrote:
> > It makes sense to let `-XX:ControlIntrinsic=` overrule
> > `VM_Version::is_intel()` check and enable the intrinsics when `AVX512DQ` is
> > supported.
>
> May be it could be done as part of
> https://bugs.openjdk.org/browse/JDK-
On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to address the follow-up comments to the SIMD
>> accelerated sort PR (#14227) which implemented AVX512 intrinsics for
>> Arrays.sort() methods.
>> The proposed changes are:
>>
>> 1) Restriction of the AVX
On Wed, 11 Oct 2023 19:06:24 GMT, Vladimir Kozlov wrote:
>> @vnkozlov Please advice if we can integrate this PR or if you would like to
>> run some tests first.
>
> Okay. I will start testing for current changes. @sviswa7 please file RFE for
> Zen 4. If we get patch
On Wed, 11 Oct 2023 18:31:44 GMT, Sandhya Viswanathan
wrote:
>> Also @forceinline in these changes only works for case when new intrinsics
>> are not used.
>> I would suggest to adapt/update JMH benchmark to cover all cases and see
>> effect @forceinline without intrinsics.
>> That will tell u
On Tue, 10 Oct 2023 18:40:30 GMT, R1chterScale wrote:
>> The goal of this PR is to address the follow-up comments to the SIMD
>> accelerated sort PR (#14227) which implemented AVX512 intrinsics for
>> Arrays.sort() methods.
>> The proposed changes are:
>>
>> 1) Restriction of the AVX512 sort a
On Tue, 10 Oct 2023 20:21:56 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to address the follow-up comments to the SIMD
>> accelerated sort PR (#14227) which implemented AVX512 intrinsics for
>> Arrays.sort() methods.
>> The proposed changes are:
>>
>> 1) Restriction of the AVX
On Tue, 10 Oct 2023 20:14:51 GMT, iaroslavski wrote:
> Is ok that partitionDualPivot, partitionSinglePivot and mixedInsertionSort,
> insertionSort are annotated differently?
Good question. Someone familiar with this Java code should answer.
Note, **@forceinline** annotation is used by C2 JIT
1 - 100 of 192 matches
Mail list logo
