From kbarrett at openjdk.org  Tue Apr  1 09:08:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Apr 2025 09:08:24 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <ytsRZsgirljfgN1UGhjQQCWAQJeSRq419ILX2Urzl7w=.ec5e07e0-4d53-450d-9aa9-467c280613cc@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
 <ytsRZsgirljfgN1UGhjQQCWAQJeSRq419ILX2Urzl7w=.ec5e07e0-4d53-450d-9aa9-467c280613cc@github.com>
Message-ID: <zI2D_JpCkXGj14e4IeCaAKoQihBMD4yfZkQ_9Y1oceQ=.93d88b17-d95e-4b82-b59a-0047f8e8b64e@github.com>

On Mon, 31 Mar 2025 10:02:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I know the source code is bundled with the test image, but I'm not 100% sure if it just includes `src`, or if the entire top-level source is included. I'll need to check that, including what is the best way to get a proper reference to the top-level directory from a test.

There was some discussion of this when recently adding the sources/TestNoNULL.java test.  The code used here
appears to similar in function (though different code) to the approach taken in that earlier test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24247#issuecomment-2768685198

From tschatzl at openjdk.org  Tue Apr  1 09:24:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Apr 2025 09:24:12 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v29]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <XrN8xT98Ce6iCKdLk190rZnKe9lg0N8ojgzx-BArS40=.b5b50a65-2e17-4ec2-a24a-76140ca4a492@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
 - * make young gen length revising independent of refinement thread
     * use a service task
     * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
 - * fix IR code generation tests that change due to barrier cost changes
 - * factor out card table and refinement table merging into a single
     method
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
 - * obsolete G1UpdateBufferSize
   
   G1UpdateBufferSize has previously been used to size the refinement
   buffers and impose a minimum limit on the number of cards per thread
   that need to be pending before refinement starts.
   
   The former function is now obsolete with the removal of the dirty
   card queues, the latter functionality has been taken over by the new
   diagnostic option `G1PerThreadPendingCardThreshold`.
   
   I prefer to make this a diagnostic option is better than a product option
   because it is something that is only necessary for some test cases to
   produce some otherwise unwanted behavior (continuous refinement).
   
   CSR is pending.
 - * more documentation on why we need to rendezvous the gc threads
 - Merge branch 'master' into 8342381-card-table-instead-of-dcq
 - ... and 27 more: https://git.openjdk.org/jdk/compare/aff5aa72...51fb6e63

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=28
  Stats: 7089 lines in 110 files changed: 2610 ins; 3555 del; 924 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From stefank at openjdk.org  Tue Apr  1 11:12:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Apr 2025 11:12:37 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
Message-ID: <4RCTjaaCqzo0ZjzZIIlEmWVMqQU90-j-HeuGvZAVV7M=.360d98b4-3aa7-46bc-a3cb-efdaaf12db0d@github.com>

On Fri, 28 Mar 2025 22:24:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds `test/hotspot/jtreg/sources/SortIncludes.java`, a tool to check that blocks of include statements in C++ files are sorted and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)).
>> 
>> By virtue of using `SortedSet`, the tool also removes duplicate includes (e.g. `"compiler/compilerDirectives.hpp"` on line [37](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L37) and line [41](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L41)). Sorting uses lowercased strings so that `_` sorts before letters, preserving the prevailing convention in the code base. I've also updated the style guide to clarify this sort-order.
>> 
>> The tool does nothing about re-ordering blocks of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually for now.
>> 
>> I have used the tool to fix the ordering of a subset of HotSpot sources and added a test to keep them sorted. That test can be expanded over time to keep includes sorted in other HotSpot directories.
>> 
>> When `TestIncludesAreSorted.java` fails, it tries to provide actionable advice. For example:
>> 
>> java.lang.RuntimeException: The unsorted includes listed below should be fixable by running:
>> 
>>     java /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/sources/SortIncludes.java --update /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1 /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/ci /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/compiler /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/jvmci
>> 
>> 	at TestIncludesAreSorted.main(TestIncludesAreSorted.java:80)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> Caused by: java.lang.RuntimeException: 36 files with unsorted headers found:
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Compilation.cpp
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Runtime1.cpp
>> /Users/dnsimo...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert Windows path to Unix path

This looks good to me.

I personally would have preferred to have the tool somewhere other than in the test directory, but I've gotten feedback from other HotSpot devs that they think its better to have the tool there.

I leave the review of TEST.group to someone else.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24247#pullrequestreview-2732333629

From kbarrett at openjdk.org  Tue Apr  1 14:34:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Apr 2025 14:34:16 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
Message-ID: <NkNkvFDz_c71wW1fUzaUfDu7Gu6jXOHZDsua4RyEew0=.c4da857d-0fbd-4100-b567-e526c72cab58@github.com>

On Fri, 28 Mar 2025 22:24:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds `test/hotspot/jtreg/sources/SortIncludes.java`, a tool to check that blocks of include statements in C++ files are sorted and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)).
>> 
>> By virtue of using `SortedSet`, the tool also removes duplicate includes (e.g. `"compiler/compilerDirectives.hpp"` on line [37](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L37) and line [41](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L41)). Sorting uses lowercased strings so that `_` sorts before letters, preserving the prevailing convention in the code base. I've also updated the style guide to clarify this sort-order.
>> 
>> The tool does nothing about re-ordering blocks of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually for now.
>> 
>> I have used the tool to fix the ordering of a subset of HotSpot sources and added a test to keep them sorted. That test can be expanded over time to keep includes sorted in other HotSpot directories.
>> 
>> When `TestIncludesAreSorted.java` fails, it tries to provide actionable advice. For example:
>> 
>> java.lang.RuntimeException: The unsorted includes listed below should be fixable by running:
>> 
>>     java /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/sources/SortIncludes.java --update /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1 /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/ci /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/compiler /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/jvmci
>> 
>> 	at TestIncludesAreSorted.main(TestIncludesAreSorted.java:80)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> Caused by: java.lang.RuntimeException: 36 files with unsorted headers found:
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Compilation.cpp
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Runtime1.cpp
>> /Users/dnsimo...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert Windows path to Unix path

test/hotspot/jtreg/TEST.groups line 142:

> 140: 
> 141: tier1_common = \
> 142:   sources \

I don't understand this change.  How does this end up doing anything different than before?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24247#discussion_r2022491702

From dnsimon at openjdk.org  Tue Apr  1 15:39:18 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 1 Apr 2025 15:39:18 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <NkNkvFDz_c71wW1fUzaUfDu7Gu6jXOHZDsua4RyEew0=.c4da857d-0fbd-4100-b567-e526c72cab58@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
 <NkNkvFDz_c71wW1fUzaUfDu7Gu6jXOHZDsua4RyEew0=.c4da857d-0fbd-4100-b567-e526c72cab58@github.com>
Message-ID: <B2v3MPPwE_hpiosI8UF7xvHe5jvcRMC5lGq6Fb4gw3k=.76e22d04-7b16-422c-915f-b00829db5059@github.com>

On Tue, 1 Apr 2025 09:25:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert Windows path to Unix path
>
> test/hotspot/jtreg/TEST.groups line 142:
> 
>> 140: 
>> 141: tier1_common = \
>> 142:   sources \
> 
> I don't understand this change.  How does this end up doing anything different than before?

This makes `sources` be tested in GHA: https://github.com/openjdk/jdk/blob/a1ab1d8de411aace21decd133e7e74bb97f27897/.github/workflows/test.yml#L88

An alternative would be to add a separate GHA jobs just for `sources`:

          - test-name: 'hs/tier1 sources'
            test-suite: 'test/hotspot/jtreg/:tier1_sources'
            debug-suffix: -debug

Given how small `sources` is ([currently only 1 test](https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/sources)), it felt like it should just be folded into common.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24247#discussion_r2023111780

From vpaprotski at openjdk.org  Tue Apr  1 18:47:39 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 1 Apr 2025 18:47:39 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
Message-ID: <EJivEu11kfoa-vPPJSaUzXV9AkqsOdIo6bpQb6QaGC0=.4b1c695a-0291-49ee-8094-20cd39ecc91b@github.com>

On Sat, 22 Mar 2025 20:02:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further readability improvements.
>  - Added asserts for array sizes

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 342:

> 340: // Performs two keccak() computations in parallel. The steps of the
> 341: // two computations are executed interleaved.
> 342: static address generate_double_keccak(StubGenerator *stubgen, MacroAssembler *_masm) {

This function seems ok. I didnt do as line-by-line 'exact' review as for the NTT intrinsics, but just put the new version into a diff next to the original function. Seems like a reasonable clean 'refactor' (hardcode the blocksize, add new input registers 10-14. Makes it really easy to spot vs 0-4 original registers..)

I didnt realize before that the 'top 3 limbs' are wasted. I guess it doesnt matter, there are registers to spare aplenty and it makes the entire algorithm cleaner and easier to follow.

I did also stare at the algorithm with the 'What about AVX2' question.. This function would pretty much need to be rewritten it looks like :/

Last two questions.. 
- how much performance is gained from doubling this function up?
- If thats worth it.. what if instead it was quadrupled the input? (I scanned the java code, it looked like NR was parametrized already to 2..). It looks like there are almost enough registers here to go to 4 (I think 3 would need to be freed up somehow.. alternatively, the upper 3 limbs are empty in all operations, perhaps it could be used instead.. at the expense of readability)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2017636762

From vpaprotski at openjdk.org  Tue Apr  1 18:47:39 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 1 Apr 2025 18:47:39 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12]
In-Reply-To: <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>
Message-ID: <tIkWHGy0LorvXtfcA3zDte84Ovm8ekTDJV8m1DaGZ8E=.750425b6-c540-4e49-8489-105f1db4e90b@github.com>

On Mon, 31 Mar 2025 14:40:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to comments by Volodymyr.

No further comments from me. (I did leave two questions, but nothing that requires code changes)

Thanks for addressing all my many (lengthy) comments and questions. And the refactor!

-------------

Marked as reviewed by vpaprotski (Author).

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2723440925

From sviswanathan at openjdk.org  Tue Apr  1 23:11:45 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Apr 2025 23:11:45 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12]
In-Reply-To: <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>
Message-ID: <JZ0pqbEz_yb5fTO9-BJuNLrli0Ueb7Z9axQ9TxV6iB0=.0e34d0de-cb0e-46c9-aa0b-8b3380a3a599@github.com>

On Mon, 31 Mar 2025 14:40:56 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to comments by Volodymyr.

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 359:

> 357:   __ kmovbl(k4, rax);
> 358:   __ addl(rax, 16);
> 359:   __ kmovbl(k5, rax);

We could use the sequence from generate_sha3_implCompress to setup the K registers, that has less dependency:
 
  __ movl(rax, 0x1F);
  __ kmovbl(k5, rax);
  __ kshiftrbl(k4, k5, 1);
  __ kshiftrbl(k3, k5, 2);
  __ kshiftrbl(k2, k5, 3);
  __ kshiftrbl(k1, k5, 4);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2023769620

From duke at openjdk.org  Wed Apr  2 07:38:34 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Apr 2025 07:38:34 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Reacting to comment by Sandhya.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/7a9f6645..e4ab10bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=11-12

  Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

PR: https://git.openjdk.org/jdk/pull/23860

From duke at openjdk.org  Wed Apr  2 07:45:14 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Apr 2025 07:45:14 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12]
In-Reply-To: <JZ0pqbEz_yb5fTO9-BJuNLrli0Ueb7Z9axQ9TxV6iB0=.0e34d0de-cb0e-46c9-aa0b-8b3380a3a599@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>
 <JZ0pqbEz_yb5fTO9-BJuNLrli0Ueb7Z9axQ9TxV6iB0=.0e34d0de-cb0e-46c9-aa0b-8b3380a3a599@github.com>
Message-ID: <_3aVrAsKu82hHiEvG-gkLScqZrm-7M6nDo6vcA7EHds=.19728142-3151-462d-95ea-bdbc36c236a7@github.com>

On Tue, 1 Apr 2025 22:43:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reacting to comments by Volodymyr.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 359:
> 
>> 357:   __ kmovbl(k4, rax);
>> 358:   __ addl(rax, 16);
>> 359:   __ kmovbl(k5, rax);
> 
> We could use the sequence from generate_sha3_implCompress to setup the K registers, that has less dependency:
>  
>   __ movl(rax, 0x1F);
>   __ kmovbl(k5, rax);
>   __ kshiftrbl(k4, k5, 1);
>   __ kshiftrbl(k3, k5, 2);
>   __ kshiftrbl(k2, k5, 3);
>   __ kshiftrbl(k1, k5, 4);

Thanks! (I had copied/doubled this function from the single state version before you made me do this change on that one and I forgot to update the copy :-) ) Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2024255339

From duke at openjdk.org  Wed Apr  2 08:22:22 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Apr 2025 08:22:22 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <EJivEu11kfoa-vPPJSaUzXV9AkqsOdIo6bpQb6QaGC0=.4b1c695a-0291-49ee-8094-20cd39ecc91b@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <EJivEu11kfoa-vPPJSaUzXV9AkqsOdIo6bpQb6QaGC0=.4b1c695a-0291-49ee-8094-20cd39ecc91b@github.com>
Message-ID: <iQOWzKwFwlkNhTImJBQYkDGvdD2Tx-RUIlb157Y3XG4=.3d3e40f1-7a38-4790-831b-ab14187b377a@github.com>

On Thu, 27 Mar 2025 21:42:08 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further readability improvements.
>>  - Added asserts for array sizes
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 342:
> 
>> 340: // Performs two keccak() computations in parallel. The steps of the
>> 341: // two computations are executed interleaved.
>> 342: static address generate_double_keccak(StubGenerator *stubgen, MacroAssembler *_masm) {
> 
> This function seems ok. I didnt do as line-by-line 'exact' review as for the NTT intrinsics, but just put the new version into a diff next to the original function. Seems like a reasonable clean 'refactor' (hardcode the blocksize, add new input registers 10-14. Makes it really easy to spot vs 0-4 original registers..)
> 
> I didnt realize before that the 'top 3 limbs' are wasted. I guess it doesnt matter, there are registers to spare aplenty and it makes the entire algorithm cleaner and easier to follow.
> 
> I did also stare at the algorithm with the 'What about AVX2' question.. This function would pretty much need to be rewritten it looks like :/
> 
> Last two questions.. 
> - how much performance is gained from doubling this function up?
> - If thats worth it.. what if instead it was quadrupled the input? (I scanned the java code, it looked like NR was parametrized already to 2..). It looks like there are almost enough registers here to go to 4 (I think 3 would need to be freed up somehow.. alternatively, the upper 3 limbs are empty in all operations, perhaps it could be used instead.. at the expense of readability)

Well, the algorithm (keccak()) is doing the same things on 5 array elements (It works on essentially a 5x5 matrix doing row and column operations, so putting 5 array entries in a vector register was the "natural" thing to do).

This function can only be used under very special circumstances, which occur during the generation of tha "A matrix" in ML-KEM and ML-DSA, the speed of that matrix generation has almost doubled (I don't have exact numbers).

We are using 7 registers per state and 15 for the constants, so we have only 3 to spare. We could perhaps juggle with the constants keeping just the ones that will be needed next in registers and reloading them "just in time", but that might slow things down a bit - more load instructions executed + maybe some load delay. On the other hand, more parallelism. I might try it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2024317665

From mchevalier at openjdk.org  Wed Apr  2 14:15:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 2 Apr 2025 14:15:00 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v2]
In-Reply-To: <sAdJdvQ5yetHi0iHkW2LNhOODBZeDjnGj399bKRL0JQ=.0de18bc8-4ec8-45dd-92c8-fe496296c33a@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
 <sAdJdvQ5yetHi0iHkW2LNhOODBZeDjnGj399bKRL0JQ=.0de18bc8-4ec8-45dd-92c8-fe496296c33a@github.com>
Message-ID: <hdlgrn6mpICPRVchHdXY52nIWcY0-s-iX2VQruHOdmY=.aa9f3d78-d02a-4c51-b523-324a9c97eaa2@github.com>

On Mon, 31 Mar 2025 11:46:57 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   not reinventing the wheel
>
> src/hotspot/share/opto/memnode.cpp line 2214:
> 
>> 2212:     if (tkls->offset() == in_bytes(Klass::layout_helper_offset()) &&
>> 2213:         tkls->isa_instklassptr() && // not directly typed as an array
>> 2214:         !tkls->is_instklassptr()->might_be_an_array() // not the supertype of all T[] (java.lang.Object) or has an interface that is not Serializable or Cloneable
> 
> Could we do the same by using `TypeKlassPtr::maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)` and define a `TypeAryKlassPtr::BOTTOM` to be a static field for the `array_interfaces`?
> 
> AFAICT,   `TypeKlassPtr::maybe_java_subtype_of()` already covers that case so it would avoid some logic duplication. Also in the test above, maybe you could simplify the test a little but by removing `tkls->isa_instklassptr()`?

I think it should be

TypeAryKlassPtr::BOTTOM->maybe_java_subtype_of(tkls)

rather than

tkls->maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)


My reasoning: if `TypeAryKlassPtr::BOTTOM` is `java.lang.Object + Cloneable + Serializable` any array is a subtype of that. But so is any class implementing these interfaces. As well as as any `Object` implementing more interfaces. But for these two last cases, we know they cannot be array, which is what we want to know: are we sure it's not an array, or could it be an array?

But if we check if `tkls` is a supertype of `java.lang.Object + Cloneable + Serializable`, then it has to be an `Object` (the most general class) and it implements a subset of `Cloneable` and `Serializable`. In this case, it can be an array. If `tkls` is not a super-type of `java.lang.Object + Cloneable + Serializable`, there are 2 cases:
- either it is an array type directly (so, I think, in a way or another, we need to check for `is_instklassptr`), and so a fortiori it can be an array type.
-  it's an instance type and then cannot be an array since there is nothing between array types and `java.lang.Object + Cloneable + Serializable`. I.e. there is no type `T` that is not an array type, that is a super-type of at least one array type and that is not a super-type of `java.lang.Object + Cloneable + Serializable` (that is that is not `java.lang.Object` or that implements at least another interface).

In other words, our question is

\exists T: T is an array type /\ T <= tkls

(where `A <= B` means `A is a subtype of B`) which is equivalent to

    tkls >= (java.lang.Object + Cloneable + Serializable)
/ (tkls <= (java.lang.Object + Cloneable + Serializable) /\ tkls is an array type)


We can spare the call to `is_instklassptr` by using a virtual method instead or probably other mechanisms, that's an implementation detail. But I think we need to distinguish cases: both `int[]` and `MyClass + Cloneable + Serializable + MyInterface` are sub-types of `java.lang.Object + Cloneable + Serializable` but for one, we can conclude it's definitely an array, and the other, it's definitely not. Without distinguishing cases, the only sound approximation would be to that that everything can be an array (both sub and super types of `java.lang.Object + Cloneable + Serializable`).

Does that makes sense? Did I get something wrong? is the `BOTTOM` not what you had in mind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24245#discussion_r2024918440

From mchevalier at openjdk.org  Wed Apr  2 14:49:15 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 2 Apr 2025 14:49:15 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v5]
In-Reply-To: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
Message-ID: <DJ1X6aZ311S6mEx6X9oG50RMqx5yQ-JXOuT8AzDFhlY=.43af8e0c-4092-436e-84da-1f2ba69ef449@github.com>

> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
> 
> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
> 
> tl;dr:
> - C1: no problem, no change
> - C2:
>   - with intrinsics:
>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>     - without overflow: no problem, no change
>   - without intrinsics: no problem, no change
> 
> Before the fix:
> 
> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
> MathExact.C1_1.loopNegateLInBounds                 1000000  avgt    3     2.422 ?    3.59...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Apply @iwanowww's refactoring

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23916/files
  - new: https://git.openjdk.org/jdk/pull/23916/files/80a67a55..34b3b75c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=03-04

  Stats: 152 lines in 4 files changed: 71 ins; 57 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23916/head:pull/23916

PR: https://git.openjdk.org/jdk/pull/23916

From mchevalier at openjdk.org  Wed Apr  2 14:49:17 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 2 Apr 2025 14:49:17 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v4]
In-Reply-To: <ZLUElOfUHk5akhNTT4axkoTzDe5y1NtL_IIDoxs3K-A=.d1259344-7b55-4634-b5d1-daafe9e42921@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <ZLUElOfUHk5akhNTT4axkoTzDe5y1NtL_IIDoxs3K-A=.d1259344-7b55-4634-b5d1-daafe9e42921@github.com>
Message-ID: <1RzVI3uVrE2YscRJPUC3KeGoF5pshACXrfZX9fooPAk=.cbcc9de2-c5d4-4f8a-82f3-444f7ee7ae0a@github.com>

On Mon, 31 Mar 2025 08:33:42 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into fix/Deoptimization-and-re-compilation-cycle-with-C2-compiled-code
>  - guess_exception_from_deopt_reason out of builtin_throw
>  - Use builtin_throw
>  - Merge branch 'master' into fix/Deoptimization-and-re-compilation-cycle-with-C2-compiled-code
>  - More exhaustive bench
>  - Limit inlining of math Exact operations in case of too many deopts

I've applied the suggested refactoring. It looks fine to me, tests seems happy, microbench shows similar profile.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23916#issuecomment-2772794493

From kbarrett at openjdk.org  Wed Apr  2 17:11:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Apr 2025 17:11:57 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
Message-ID: <wJ98gwUclHm6SYoXgz4FyVZfeGhJHnF8k6ox-DsVkn8=.cc9aef65-7fe9-4815-a2c6-6b91244e81f3@github.com>

On Fri, 28 Mar 2025 22:24:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds `test/hotspot/jtreg/sources/SortIncludes.java`, a tool to check that blocks of include statements in C++ files are sorted and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)).
>> 
>> By virtue of using `SortedSet`, the tool also removes duplicate includes (e.g. `"compiler/compilerDirectives.hpp"` on line [37](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L37) and line [41](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L41)). Sorting uses lowercased strings so that `_` sorts before letters, preserving the prevailing convention in the code base. I've also updated the style guide to clarify this sort-order.
>> 
>> The tool does nothing about re-ordering blocks of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually for now.
>> 
>> I have used the tool to fix the ordering of a subset of HotSpot sources and added a test to keep them sorted. That test can be expanded over time to keep includes sorted in other HotSpot directories.
>> 
>> When `TestIncludesAreSorted.java` fails, it tries to provide actionable advice. For example:
>> 
>> java.lang.RuntimeException: The unsorted includes listed below should be fixable by running:
>> 
>>     java /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/sources/SortIncludes.java --update /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1 /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/ci /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/compiler /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/jvmci
>> 
>> 	at TestIncludesAreSorted.main(TestIncludesAreSorted.java:80)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> Caused by: java.lang.RuntimeException: 36 files with unsorted headers found:
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Compilation.cpp
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Runtime1.cpp
>> /Users/dnsimo...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert Windows path to Unix path

Marked as reviewed by kbarrett (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24247#pullrequestreview-2737009362

From kbarrett at openjdk.org  Wed Apr  2 17:11:58 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Apr 2025 17:11:58 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <B2v3MPPwE_hpiosI8UF7xvHe5jvcRMC5lGq6Fb4gw3k=.76e22d04-7b16-422c-915f-b00829db5059@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
 <NkNkvFDz_c71wW1fUzaUfDu7Gu6jXOHZDsua4RyEew0=.c4da857d-0fbd-4100-b567-e526c72cab58@github.com>
 <B2v3MPPwE_hpiosI8UF7xvHe5jvcRMC5lGq6Fb4gw3k=.76e22d04-7b16-422c-915f-b00829db5059@github.com>
Message-ID: <yO-wTbL64QArwb7YPzTSuAm1k0vy0LHz8hHLKUTZi2A=.7722aed5-fac1-454e-8b2e-5276727b122c@github.com>

On Tue, 1 Apr 2025 15:35:45 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> test/hotspot/jtreg/TEST.groups line 142:
>> 
>>> 140: 
>>> 141: tier1_common = \
>>> 142:   sources \
>> 
>> I don't understand this change.  How does this end up doing anything different than before?
>
> This makes `sources` be tested in GHA: https://github.com/openjdk/jdk/blob/a1ab1d8de411aace21decd133e7e74bb97f27897/.github/workflows/test.yml#L88
> 
> An alternative would be to add a separate GHA jobs just for `sources`:
> 
>           - test-name: 'hs/tier1 sources'
>             test-suite: 'test/hotspot/jtreg/:tier1_sources'
>             debug-suffix: -debug
> 
> Given how small `sources` is ([currently only 1 test](https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/sources)), it felt like it should just be folded into common.

Ah, the workflows definition is what I was having trouble finding. I
understand now. In light of that, the proposed change to the groups looks
fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24247#discussion_r2025256054

From vlivanov at openjdk.org  Wed Apr  2 17:13:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Apr 2025 17:13:58 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v5]
In-Reply-To: <DJ1X6aZ311S6mEx6X9oG50RMqx5yQ-JXOuT8AzDFhlY=.43af8e0c-4092-436e-84da-1f2ba69ef449@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <DJ1X6aZ311S6mEx6X9oG50RMqx5yQ-JXOuT8AzDFhlY=.43af8e0c-4092-436e-84da-1f2ba69ef449@github.com>
Message-ID: <khpEa8RMkxFgLKYKVAjsGxCa-XAenQvOIwsS3jHrDbU=.4d8d18ee-36d0-448a-b0e1-8857ce4a2a98@github.com>

On Wed, 2 Apr 2025 14:49:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @iwanowww's refactoring

Looks good.

src/hotspot/share/opto/library_call.cpp line 2009:

> 2007:   if (builtin_throw_too_many_traps(Deoptimization::Reason_intrinsic,
> 2008:                                    env()->ArithmeticException_instance())) {
> 2009:     // It has been already too many times, but we cannot use builtin_throw care (e.g. we care about backtraces),

Remove "care" in "builtin_throw care"?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23916#pullrequestreview-2737016248
PR Review Comment: https://git.openjdk.org/jdk/pull/23916#discussion_r2025260344

From mchevalier at openjdk.org  Wed Apr  2 17:23:03 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 2 Apr 2025 17:23:03 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v6]
In-Reply-To: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
Message-ID: <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>

> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
> 
> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
> 
> tl;dr:
> - C1: no problem, no change
> - C2:
>   - with intrinsics:
>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>     - without overflow: no problem, no change
>   - without intrinsics: no problem, no change
> 
> Before the fix:
> 
> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
> MathExact.C1_1.loopNegateLInBounds                 1000000  avgt    3     2.422 ?    3.59...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  fix typo in comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23916/files
  - new: https://git.openjdk.org/jdk/pull/23916/files/34b3b75c..238b129d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23916/head:pull/23916

PR: https://git.openjdk.org/jdk/pull/23916

From mchevalier at openjdk.org  Wed Apr  2 17:23:03 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 2 Apr 2025 17:23:03 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v5]
In-Reply-To: <khpEa8RMkxFgLKYKVAjsGxCa-XAenQvOIwsS3jHrDbU=.4d8d18ee-36d0-448a-b0e1-8857ce4a2a98@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <DJ1X6aZ311S6mEx6X9oG50RMqx5yQ-JXOuT8AzDFhlY=.43af8e0c-4092-436e-84da-1f2ba69ef449@github.com>
 <khpEa8RMkxFgLKYKVAjsGxCa-XAenQvOIwsS3jHrDbU=.4d8d18ee-36d0-448a-b0e1-8857ce4a2a98@github.com>
Message-ID: <SlCiRzgZfXqmopZm7ak85HOs489m7tBWJK6lVEo0mCs=.7a187752-9e4b-4eee-990f-5b45ac547ad8@github.com>

On Wed, 2 Apr 2025 17:11:00 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply @iwanowww's refactoring
>
> src/hotspot/share/opto/library_call.cpp line 2009:
> 
>> 2007:   if (builtin_throw_too_many_traps(Deoptimization::Reason_intrinsic,
>> 2008:                                    env()->ArithmeticException_instance())) {
>> 2009:     // It has been already too many times, but we cannot use builtin_throw care (e.g. we care about backtraces),
> 
> Remove "care" in "builtin_throw care"?

Thanks! Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23916#discussion_r2025271377

From vlivanov at openjdk.org  Wed Apr  2 18:10:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Apr 2025 18:10:50 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v6]
In-Reply-To: <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
Message-ID: <uXDD1zwK8eSbbRf_bsx_pNlQHxzBWmuMF4AVHV7-ufM=.c595db1e-0261-4095-b404-38cdc63ce420@github.com>

On Wed, 2 Apr 2025 17:23:03 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in comment

Marked as reviewed by vlivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23916#pullrequestreview-2737157109

From jbhateja at openjdk.org  Wed Apr  2 18:24:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Apr 2025 18:24:55 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13]
In-Reply-To: <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
Message-ID: <P9dkHJUBTIv2yQFURkRhy8QY-jPrmTVDB1QCsAsKOrM=.f127a77b-d659-4212-a47f-a17c1a1c64b0@github.com>

On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to comment by Sandhya.

@ferakocz , I verified new version of patch on Linux and windows and it works fine.

Thanks for addressing my comments.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2737186292

From dnsimon at openjdk.org  Wed Apr  2 22:32:58 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Apr 2025 22:32:58 GMT
Subject: RFR: 8352645: Add tool support to check order of includes [v6]
In-Reply-To: <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
 <dGKFXPuQ5d-HbQYJ9Z7cn8MTLoV_7IWW5-6dftqO49c=.21f8dec7-35e5-46ab-ad24-3050ff5e200e@github.com>
Message-ID: <lkUB-YPbE6hcpdIlJJ7ncGS3aKMTQQ-ZRur3-PZ0Os8=.be57f024-9efe-443a-8531-1e9ce0127d35@github.com>

On Fri, 28 Mar 2025 22:24:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds `test/hotspot/jtreg/sources/SortIncludes.java`, a tool to check that blocks of include statements in C++ files are sorted and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)).
>> 
>> By virtue of using `SortedSet`, the tool also removes duplicate includes (e.g. `"compiler/compilerDirectives.hpp"` on line [37](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L37) and line [41](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L41)). Sorting uses lowercased strings so that `_` sorts before letters, preserving the prevailing convention in the code base. I've also updated the style guide to clarify this sort-order.
>> 
>> The tool does nothing about re-ordering blocks of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually for now.
>> 
>> I have used the tool to fix the ordering of a subset of HotSpot sources and added a test to keep them sorted. That test can be expanded over time to keep includes sorted in other HotSpot directories.
>> 
>> When `TestIncludesAreSorted.java` fails, it tries to provide actionable advice. For example:
>> 
>> java.lang.RuntimeException: The unsorted includes listed below should be fixable by running:
>> 
>>     java /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/sources/SortIncludes.java --update /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1 /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/ci /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/compiler /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/jvmci
>> 
>> 	at TestIncludesAreSorted.main(TestIncludesAreSorted.java:80)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> Caused by: java.lang.RuntimeException: 36 files with unsorted headers found:
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Compilation.cpp
>> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Runtime1.cpp
>> /Users/dnsimo...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert Windows path to Unix path

Thanks for all the discussion and reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24247#issuecomment-2773874524

From dnsimon at openjdk.org  Wed Apr  2 22:32:59 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Apr 2025 22:32:59 GMT
Subject: Integrated: 8352645: Add tool support to check order of includes
In-Reply-To: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
References: <2R1Lazv-rFiErR_ZtJjyT77Wm2XeaKQ8hA5HDg8o1v4=.084054ad-a46b-4206-bc1e-5e9d2bdbaaa2@github.com>
Message-ID: <u8kxGcSpsZWpinzvQe6P0B8D6bBMB5aIaJQtQBD1noA=.18e43e4b-1c68-4a99-ae5e-01b865e6cf74@github.com>

On Wed, 26 Mar 2025 09:21:59 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds `test/hotspot/jtreg/sources/SortIncludes.java`, a tool to check that blocks of include statements in C++ files are sorted and that there's at least one blank line between user and sys includes (as per the [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)).
> 
> By virtue of using `SortedSet`, the tool also removes duplicate includes (e.g. `"compiler/compilerDirectives.hpp"` on line [37](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L37) and line [41](https://github.com/openjdk/jdk/blob/059f190f4b0c7836b89ca2070400529e8d33790b/src/hotspot/share/c1/c1_Compilation.cpp#L41)). Sorting uses lowercased strings so that `_` sorts before letters, preserving the prevailing convention in the code base. I've also updated the style guide to clarify this sort-order.
> 
> The tool does nothing about re-ordering blocks of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually for now.
> 
> I have used the tool to fix the ordering of a subset of HotSpot sources and added a test to keep them sorted. That test can be expanded over time to keep includes sorted in other HotSpot directories.
> 
> When `TestIncludesAreSorted.java` fails, it tries to provide actionable advice. For example:
> 
> java.lang.RuntimeException: The unsorted includes listed below should be fixable by running:
> 
>     java /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/sources/SortIncludes.java --update /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1 /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/ci /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/compiler /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/jvmci
> 
> 	at TestIncludesAreSorted.main(TestIncludesAreSorted.java:80)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)
> Caused by: java.lang.RuntimeException: 36 files with unsorted headers found:
> 
> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Compilation.cpp
> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Runtime1.cpp
> /Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/c1/c1_Optim...

This pull request has now been integrated.

Changeset: 814730ea
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/814730eae76d7b60a6082dc6f9e30618b7d8524b
Stats:     486 lines in 53 files changed: 407 ins; 55 del; 24 mod

8352645: Add tool support to check order of includes

Reviewed-by: stefank, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/24247

From thartmann at openjdk.org  Thu Apr  3 12:01:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 3 Apr 2025 12:01:59 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v6]
In-Reply-To: <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
Message-ID: <jL-1vLXKoeBG7-QvjqeCrQ3HM196UHq-74WNQBCdPiI=.a7b2d36c-684e-4f93-97b8-48e64fe07d99@github.com>

On Wed, 2 Apr 2025 17:23:03 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in comment

Took me a while to parse the code but the refactoring definitely improves the situation :slightly_smiling_face: Looks good!

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23916#pullrequestreview-2739594615

From mchevalier at openjdk.org  Thu Apr  3 13:01:15 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 3 Apr 2025 13:01:15 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v7]
In-Reply-To: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
Message-ID: <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>

> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
> 
> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
> 
> tl;dr:
> - C1: no problem, no change
> - C2:
>   - with intrinsics:
>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>     - without overflow: no problem, no change
>   - without intrinsics: no problem, no change
> 
> Before the fix:
> 
> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
> MathExact.C1_1.loopNegateLInBounds                 1000000  avgt    3     2.422 ?    3.59...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Remove useless flags in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23916/files
  - new: https://git.openjdk.org/jdk/pull/23916/files/238b129d..e7c8f3e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23916&range=05-06

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23916/head:pull/23916

PR: https://git.openjdk.org/jdk/pull/23916

From mchevalier at openjdk.org  Thu Apr  3 13:01:16 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 3 Apr 2025 13:01:16 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v6]
In-Reply-To: <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <MAnmkyphGfEoQ65QcFC72olK3lEmaUNwWzA50JJi3N4=.246532c0-bd2a-463a-b766-a5f85df2cf2a@github.com>
Message-ID: <xUcVlwZ5f1iZWM6VEjT7WeqWBpvV3DKeLgXaHsWcNNs=.50206d1b-dde0-4ffc-ba7b-7856c08e5b53@github.com>

On Wed, 2 Apr 2025 17:23:03 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in comment

I've made the test flags tighter as discussed offline. I'll need a fresh approval.

And for completeness, there are the bench result on this last state. We can see that things behave as we expect: builtin_throw is taken and making the situation a lot better. When intrinsics or builtin_throw are disabled, we see C1-like perfs.

Benchmark                                              (SIZE)  Mode  Cnt    Score      Error  Units
MathExact.C1_1.loopAddIInBounds                       1000000  avgt    3    1.616 ?    7.813  ms/op
MathExact.C1_1.loopAddIOverflow                       1000000  avgt    3  654.971 ?  573.250  ms/op
MathExact.C1_1.loopAddLInBounds                       1000000  avgt    3    1.398 ?    0.274  ms/op
MathExact.C1_1.loopAddLOverflow                       1000000  avgt    3  629.620 ?   41.181  ms/op
MathExact.C1_1.loopDecrementIInBounds                 1000000  avgt    3    2.048 ?    0.340  ms/op
MathExact.C1_1.loopDecrementIOverflow                 1000000  avgt    3  681.702 ?   63.721  ms/op
MathExact.C1_1.loopDecrementLInBounds                 1000000  avgt    3    3.057 ?   13.688  ms/op
MathExact.C1_1.loopDecrementLOverflow                 1000000  avgt    3  660.457 ?  295.393  ms/op
MathExact.C1_1.loopIncrementIInBounds                 1000000  avgt    3    2.531 ?   13.692  ms/op
MathExact.C1_1.loopIncrementIOverflow                 1000000  avgt    3  647.970 ?   65.451  ms/op
MathExact.C1_1.loopIncrementLInBounds                 1000000  avgt    3    5.350 ?   25.080  ms/op
MathExact.C1_1.loopIncrementLOverflow                 1000000  avgt    3  681.097 ?   72.604  ms/op
MathExact.C1_1.loopMultiplyIInBounds                  1000000  avgt    3    1.552 ?    3.145  ms/op
MathExact.C1_1.loopMultiplyIOverflow                  1000000  avgt    3  648.402 ?   62.995  ms/op
MathExact.C1_1.loopMultiplyLInBounds                  1000000  avgt    3    2.501 ?    0.720  ms/op
MathExact.C1_1.loopMultiplyLOverflow                  1000000  avgt    3  701.498 ?   47.948  ms/op
MathExact.C1_1.loopNegateIInBounds                    1000000  avgt    3    2.074 ?    0.949  ms/op
MathExact.C1_1.loopNegateIOverflow                    1000000  avgt    3  665.143 ?  537.941  ms/op
MathExact.C1_1.loopNegateLInBounds                    1000000  avgt    3    5.487 ?    7.165  ms/op
MathExact.C1_1.loopNegateLOverflow                    1000000  avgt    3  687.085 ?   20.738  ms/op
MathExact.C1_1.loopSubtractIInBounds                  1000000  avgt    3    1.329 ?    0.769  ms/op
MathExact.C1_1.loopSubtractIOverflow                  1000000  avgt    3  683.922 ?   70.434  ms/op
MathExact.C1_1.loopSubtractLInBounds                  1000000  avgt    3    1.384 ?    0.386  ms/op
MathExact.C1_1.loopSubtractLOverflow                  1000000  avgt    3  664.380 ?  480.847  ms/op
MathExact.C1_2.loopAddIInBounds                       1000000  avgt    3    1.862 ?    0.815  ms/op
MathExact.C1_2.loopAddIOverflow                       1000000  avgt    3  660.421 ?  506.723  ms/op
MathExact.C1_2.loopAddLInBounds                       1000000  avgt    3    1.829 ?    0.221  ms/op
MathExact.C1_2.loopAddLOverflow                       1000000  avgt    3  681.209 ?   78.976  ms/op
MathExact.C1_2.loopDecrementIInBounds                 1000000  avgt    3    3.533 ?   11.302  ms/op
MathExact.C1_2.loopDecrementIOverflow                 1000000  avgt    3  682.639 ?  225.392  ms/op
MathExact.C1_2.loopDecrementLInBounds                 1000000  avgt    3    3.402 ?    1.031  ms/op
MathExact.C1_2.loopDecrementLOverflow                 1000000  avgt    3  697.283 ?  306.867  ms/op
MathExact.C1_2.loopIncrementIInBounds                 1000000  avgt    3    3.326 ?    5.072  ms/op
MathExact.C1_2.loopIncrementIOverflow                 1000000  avgt    3  658.514 ?  636.731  ms/op
MathExact.C1_2.loopIncrementLInBounds                 1000000  avgt    3    3.718 ?    0.422  ms/op
MathExact.C1_2.loopIncrementLOverflow                 1000000  avgt    3  693.863 ?   49.201  ms/op
MathExact.C1_2.loopMultiplyIInBounds                  1000000  avgt    3    1.924 ?    2.800  ms/op
MathExact.C1_2.loopMultiplyIOverflow                  1000000  avgt    3  609.308 ?   94.814  ms/op
MathExact.C1_2.loopMultiplyLInBounds                  1000000  avgt    3    3.459 ?    0.625  ms/op
MathExact.C1_2.loopMultiplyLOverflow                  1000000  avgt    3  713.503 ?  556.995  ms/op
MathExact.C1_2.loopNegateIInBounds                    1000000  avgt    3    3.195 ?    0.726  ms/op
MathExact.C1_2.loopNegateIOverflow                    1000000  avgt    3  684.176 ?   27.164  ms/op
MathExact.C1_2.loopNegateLInBounds                    1000000  avgt    3    3.483 ?    0.947  ms/op
MathExact.C1_2.loopNegateLOverflow                    1000000  avgt    3  656.284 ?  582.286  ms/op
MathExact.C1_2.loopSubtractIInBounds                  1000000  avgt    3    1.728 ?    0.315  ms/op
MathExact.C1_2.loopSubtractIOverflow                  1000000  avgt    3  688.029 ?   25.201  ms/op
MathExact.C1_2.loopSubtractLInBounds                  1000000  avgt    3    1.941 ?    0.169  ms/op
MathExact.C1_2.loopSubtractLOverflow                  1000000  avgt    3  694.341 ?  339.431  ms/op
MathExact.C1_3.loopAddIInBounds                       1000000  avgt    3    3.122 ?    0.910  ms/op
MathExact.C1_3.loopAddIOverflow                       1000000  avgt    3  688.731 ?  308.210  ms/op
MathExact.C1_3.loopAddLInBounds                       1000000  avgt    3    5.492 ?   36.236  ms/op
MathExact.C1_3.loopAddLOverflow                       1000000  avgt    3  697.053 ?  229.958  ms/op
MathExact.C1_3.loopDecrementIInBounds                 1000000  avgt    3    9.155 ?   72.182  ms/op
MathExact.C1_3.loopDecrementIOverflow                 1000000  avgt    3  708.458 ?  788.701  ms/op
MathExact.C1_3.loopDecrementLInBounds                 1000000  avgt    3    6.402 ?    3.658  ms/op
MathExact.C1_3.loopDecrementLOverflow                 1000000  avgt    3  705.992 ?  213.542  ms/op
MathExact.C1_3.loopIncrementIInBounds                 1000000  avgt    3    7.699 ?   61.434  ms/op
MathExact.C1_3.loopIncrementIOverflow                 1000000  avgt    3  697.353 ?  105.457  ms/op
MathExact.C1_3.loopIncrementLInBounds                 1000000  avgt    3    6.380 ?    0.839  ms/op
MathExact.C1_3.loopIncrementLOverflow                 1000000  avgt    3  669.240 ?  522.870  ms/op
MathExact.C1_3.loopMultiplyIInBounds                  1000000  avgt    3    3.225 ?    0.140  ms/op
MathExact.C1_3.loopMultiplyIOverflow                  1000000  avgt    3  624.811 ?  457.059  ms/op
MathExact.C1_3.loopMultiplyLInBounds                  1000000  avgt    3    6.110 ?    1.265  ms/op
MathExact.C1_3.loopMultiplyLOverflow                  1000000  avgt    3  718.460 ?   68.166  ms/op
MathExact.C1_3.loopNegateIInBounds                    1000000  avgt    3    6.085 ?    1.430  ms/op
MathExact.C1_3.loopNegateIOverflow                    1000000  avgt    3  675.036 ?  341.177  ms/op
MathExact.C1_3.loopNegateLInBounds                    1000000  avgt    3    9.410 ?   93.522  ms/op
MathExact.C1_3.loopNegateLOverflow                    1000000  avgt    3  652.042 ?  166.119  ms/op
MathExact.C1_3.loopSubtractIInBounds                  1000000  avgt    3    3.432 ?   11.899  ms/op
MathExact.C1_3.loopSubtractIOverflow                  1000000  avgt    3  654.208 ?  120.258  ms/op
MathExact.C1_3.loopSubtractLInBounds                  1000000  avgt    3    5.166 ?   38.529  ms/op
MathExact.C1_3.loopSubtractLOverflow                  1000000  avgt    3  691.094 ?   80.676  ms/op
MathExact.C2.loopAddIInBounds                         1000000  avgt    3    2.276 ?    1.750  ms/op
MathExact.C2.loopAddIOverflow                         1000000  avgt    3    1.173 ?    1.392  ms/op
MathExact.C2.loopAddLInBounds                         1000000  avgt    3    0.985 ?    0.167  ms/op
MathExact.C2.loopAddLOverflow                         1000000  avgt    3    1.990 ?    5.310  ms/op
MathExact.C2.loopDecrementIInBounds                   1000000  avgt    3    2.072 ?    0.173  ms/op
MathExact.C2.loopDecrementIOverflow                   1000000  avgt    3    1.911 ?    0.288  ms/op
MathExact.C2.loopDecrementLInBounds                   1000000  avgt    3    1.845 ?    0.424  ms/op
MathExact.C2.loopDecrementLOverflow                   1000000  avgt    3    2.757 ?   27.268  ms/op
MathExact.C2.loopIncrementIInBounds                   1000000  avgt    3    2.136 ?    0.517  ms/op
MathExact.C2.loopIncrementIOverflow                   1000000  avgt    3    2.199 ?    4.024  ms/op
MathExact.C2.loopIncrementLInBounds                   1000000  avgt    3    1.957 ?    0.365  ms/op
MathExact.C2.loopIncrementLOverflow                   1000000  avgt    3    2.053 ?    0.779  ms/op
MathExact.C2.loopMultiplyIInBounds                    1000000  avgt    3    1.174 ?    0.941  ms/op
MathExact.C2.loopMultiplyIOverflow                    1000000  avgt    3    1.971 ?   10.040  ms/op
MathExact.C2.loopMultiplyLInBounds                    1000000  avgt    3    0.997 ?    0.318  ms/op
MathExact.C2.loopMultiplyLOverflow                    1000000  avgt    3    2.847 ?    4.548  ms/op
MathExact.C2.loopNegateIInBounds                      1000000  avgt    3    4.783 ?    2.454  ms/op
MathExact.C2.loopNegateIOverflow                      1000000  avgt    3    1.915 ?    0.009  ms/op
MathExact.C2.loopNegateLInBounds                      1000000  avgt    3    2.824 ?   28.297  ms/op
MathExact.C2.loopNegateLOverflow                      1000000  avgt    3    4.766 ?   32.627  ms/op
MathExact.C2.loopSubtractIInBounds                    1000000  avgt    3    0.990 ?    0.264  ms/op
MathExact.C2.loopSubtractIOverflow                    1000000  avgt    3    1.181 ?    2.120  ms/op
MathExact.C2.loopSubtractLInBounds                    1000000  avgt    3    2.363 ?    1.575  ms/op
MathExact.C2.loopSubtractLOverflow                    1000000  avgt    3    2.429 ?    7.120  ms/op
MathExact.C2_no_builtin_throw.loopAddIInBounds        1000000  avgt    3    1.040 ?    0.181  ms/op
MathExact.C2_no_builtin_throw.loopAddIOverflow        1000000  avgt    3  580.950 ?  112.050  ms/op
MathExact.C2_no_builtin_throw.loopAddLInBounds        1000000  avgt    3    1.223 ?    5.700  ms/op
MathExact.C2_no_builtin_throw.loopAddLOverflow        1000000  avgt    3  585.712 ?   61.699  ms/op
MathExact.C2_no_builtin_throw.loopDecrementIInBounds  1000000  avgt    3    2.114 ?    0.663  ms/op
MathExact.C2_no_builtin_throw.loopDecrementIOverflow  1000000  avgt    3  604.866 ?  578.502  ms/op
MathExact.C2_no_builtin_throw.loopDecrementLInBounds  1000000  avgt    3    2.167 ?    9.268  ms/op
MathExact.C2_no_builtin_throw.loopDecrementLOverflow  1000000  avgt    3  621.175 ?  225.858  ms/op
MathExact.C2_no_builtin_throw.loopIncrementIInBounds  1000000  avgt    3    1.950 ?    0.326  ms/op
MathExact.C2_no_builtin_throw.loopIncrementIOverflow  1000000  avgt    3  633.735 ?  830.255  ms/op
MathExact.C2_no_builtin_throw.loopIncrementLInBounds  1000000  avgt    3    2.397 ?   11.911  ms/op
MathExact.C2_no_builtin_throw.loopIncrementLOverflow  1000000  avgt    3  627.599 ?  141.709  ms/op
MathExact.C2_no_builtin_throw.loopMultiplyIInBounds   1000000  avgt    3    1.167 ?    1.187  ms/op
MathExact.C2_no_builtin_throw.loopMultiplyIOverflow   1000000  avgt    3  623.224 ?  298.374  ms/op
MathExact.C2_no_builtin_throw.loopMultiplyLInBounds   1000000  avgt    3    0.944 ?    0.743  ms/op
MathExact.C2_no_builtin_throw.loopMultiplyLOverflow   1000000  avgt    3  658.380 ?  137.021  ms/op
MathExact.C2_no_builtin_throw.loopNegateIInBounds     1000000  avgt    3    2.119 ?    0.642  ms/op
MathExact.C2_no_builtin_throw.loopNegateIOverflow     1000000  avgt    3  643.102 ?  452.213  ms/op
MathExact.C2_no_builtin_throw.loopNegateLInBounds     1000000  avgt    3    2.036 ?    0.862  ms/op
MathExact.C2_no_builtin_throw.loopNegateLOverflow     1000000  avgt    3  586.103 ?   26.173  ms/op
MathExact.C2_no_builtin_throw.loopSubtractIInBounds   1000000  avgt    3    2.552 ?    3.677  ms/op
MathExact.C2_no_builtin_throw.loopSubtractIOverflow   1000000  avgt    3  635.294 ?  217.034  ms/op
MathExact.C2_no_builtin_throw.loopSubtractLInBounds   1000000  avgt    3    1.093 ?    1.685  ms/op
MathExact.C2_no_builtin_throw.loopSubtractLOverflow   1000000  avgt    3  661.541 ? 1358.199  ms/op
MathExact.C2_no_intrinsics.loopAddIInBounds           1000000  avgt    3    2.185 ?   15.103  ms/op
MathExact.C2_no_intrinsics.loopAddIOverflow           1000000  avgt    3  831.812 ? 1260.546  ms/op
MathExact.C2_no_intrinsics.loopAddLInBounds           1000000  avgt    3    2.145 ?    0.088  ms/op
MathExact.C2_no_intrinsics.loopAddLOverflow           1000000  avgt    3  709.930 ?  658.722  ms/op
MathExact.C2_no_intrinsics.loopDecrementIInBounds     1000000  avgt    3    2.288 ?    0.950  ms/op
MathExact.C2_no_intrinsics.loopDecrementIOverflow     1000000  avgt    3  646.879 ?  186.231  ms/op
MathExact.C2_no_intrinsics.loopDecrementLInBounds     1000000  avgt    3    1.894 ?    0.421  ms/op
MathExact.C2_no_intrinsics.loopDecrementLOverflow     1000000  avgt    3  641.577 ?  323.040  ms/op
MathExact.C2_no_intrinsics.loopIncrementIInBounds     1000000  avgt    3    2.027 ?    0.249  ms/op
MathExact.C2_no_intrinsics.loopIncrementIOverflow     1000000  avgt    3  657.092 ?  229.818  ms/op
MathExact.C2_no_intrinsics.loopIncrementLInBounds     1000000  avgt    3    3.220 ?   16.992  ms/op
MathExact.C2_no_intrinsics.loopIncrementLOverflow     1000000  avgt    3  603.468 ?   73.240  ms/op
MathExact.C2_no_intrinsics.loopMultiplyIInBounds      1000000  avgt    3    1.295 ?    0.413  ms/op
MathExact.C2_no_intrinsics.loopMultiplyIOverflow      1000000  avgt    3  593.005 ?  576.291  ms/op
MathExact.C2_no_intrinsics.loopMultiplyLInBounds      1000000  avgt    3    1.093 ?    0.916  ms/op
MathExact.C2_no_intrinsics.loopMultiplyLOverflow      1000000  avgt    3  618.956 ?  554.204  ms/op
MathExact.C2_no_intrinsics.loopNegateIInBounds        1000000  avgt    3    2.035 ?    0.047  ms/op
MathExact.C2_no_intrinsics.loopNegateIOverflow        1000000  avgt    3  650.591 ? 1248.923  ms/op
MathExact.C2_no_intrinsics.loopNegateLInBounds        1000000  avgt    3    3.505 ?   20.475  ms/op
MathExact.C2_no_intrinsics.loopNegateLOverflow        1000000  avgt    3  660.686 ?  201.612  ms/op
MathExact.C2_no_intrinsics.loopSubtractIInBounds      1000000  avgt    3    1.109 ?    0.726  ms/op
MathExact.C2_no_intrinsics.loopSubtractIOverflow      1000000  avgt    3  670.468 ?  475.269  ms/op
MathExact.C2_no_intrinsics.loopSubtractLInBounds      1000000  avgt    3    1.208 ?    0.806  ms/op
MathExact.C2_no_intrinsics.loopSubtractLOverflow      1000000  avgt    3  597.522 ?   32.465  ms/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23916#issuecomment-2775707480

From roland at openjdk.org  Thu Apr  3 13:06:49 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 3 Apr 2025 13:06:49 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v2]
In-Reply-To: <hdlgrn6mpICPRVchHdXY52nIWcY0-s-iX2VQruHOdmY=.aa9f3d78-d02a-4c51-b523-324a9c97eaa2@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
 <sAdJdvQ5yetHi0iHkW2LNhOODBZeDjnGj399bKRL0JQ=.0de18bc8-4ec8-45dd-92c8-fe496296c33a@github.com>
 <hdlgrn6mpICPRVchHdXY52nIWcY0-s-iX2VQruHOdmY=.aa9f3d78-d02a-4c51-b523-324a9c97eaa2@github.com>
Message-ID: <5c7yEX837btOgbGnTKNn8a7hlPljZRwh0TpgZI6Ogb0=.1c7f3aed-8e8c-4efe-beed-68ea192bcb99@github.com>

On Wed, 2 Apr 2025 14:11:34 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/memnode.cpp line 2214:
>> 
>>> 2212:     if (tkls->offset() == in_bytes(Klass::layout_helper_offset()) &&
>>> 2213:         tkls->isa_instklassptr() && // not directly typed as an array
>>> 2214:         !tkls->is_instklassptr()->might_be_an_array() // not the supertype of all T[] (java.lang.Object) or has an interface that is not Serializable or Cloneable
>> 
>> Could we do the same by using `TypeKlassPtr::maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)` and define a `TypeAryKlassPtr::BOTTOM` to be a static field for the `array_interfaces`?
>> 
>> AFAICT,   `TypeKlassPtr::maybe_java_subtype_of()` already covers that case so it would avoid some logic duplication. Also in the test above, maybe you could simplify the test a little but by removing `tkls->isa_instklassptr()`?
>
> I think it should be
> 
> TypeAryKlassPtr::BOTTOM->maybe_java_subtype_of(tkls)
> 
> rather than
> 
> tkls->maybe_java_subtype_of(TypeAryKlassPtr::BOTTOM)
> 
> 
> My reasoning: if `TypeAryKlassPtr::BOTTOM` is `java.lang.Object + Cloneable + Serializable` any array is a subtype of that. But so is any class implementing these interfaces. As well as as any `Object` implementing more interfaces. But for these two last cases, we know they cannot be array, which is what we want to know: are we sure it's not an array, or could it be an array?
> 
> But if we check if `tkls` is a supertype of `java.lang.Object + Cloneable + Serializable`, then it has to be an `Object` (the most general class) and it implements a subset of `Cloneable` and `Serializable`. In this case, it can be an array. If `tkls` is not a super-type of `java.lang.Object + Cloneable + Serializable`, there are 2 cases:
> - either it is an array type directly (so, I think, in a way or another, we need to check for `is_instklassptr`), and so a fortiori it can be an array type.
> -  it's an instance type and then cannot be an array since there is nothing between array types and `java.lang.Object + Cloneable + Serializable`. I.e. there is no type `T` that is not an array type, that is a super-type of at least one array type and that is not a super-type of `java.lang.Object + Cloneable + Serializable` (that is that is not `java.lang.Object` or that implements at least another interface).
> 
> In other words, our question is
> 
> \exists T: T is an array type /\ T <= tkls
> 
> (where `A <= B` means `A is a subtype of B`) which is equivalent to
> 
>     tkls >= (java.lang.Object + Cloneable + Serializable)
> / (tkls <= (java.lang.Object + Cloneable + Serializable) /\ tkls is an array type)
> 
> 
> We can spare the call to `is_instklassptr` by using a virtual method instead or probably other mechanisms, that's an implementation detail. But I think we need to distinguish cases: both `int[]` and `MyClass + Cloneable + Serializable + MyInterface` are sub-types of `java.lang.Object + Cloneable + Serializable` but for one, we can conclude it's definitely an array, and the other, it's definitely not. Without distinguishing cases, the only sound approximation would be to that that everything can be an array (both sub and super types of `java.lang.Object + Cloneable + Serializable`).
> 
> Does that makes sense? Did I get something wrong? is the `BOTTOM` not what you had in mind?

Yes, what I suggested doesn't work indeed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24245#discussion_r2026954565

From thartmann at openjdk.org  Thu Apr  3 13:13:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 3 Apr 2025 13:13:51 GMT
Subject: RFR: 8346989: C2: deoptimization and re-compilation cycle with
 Math.*Exact in case of frequent overflow [v7]
In-Reply-To: <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
Message-ID: <5fCOI-cNWoRD89POiHnHraJaiy_73Hlt1xZCNGLcHrY=.aebffb74-c8e5-475e-a853-3576673d6161@github.com>

On Thu, 3 Apr 2025 13:01:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove useless flags in tests

Marked as reviewed by thartmann (Reviewer).

Great, thank you!

-------------

PR Review: https://git.openjdk.org/jdk/pull/23916#pullrequestreview-2739795916
PR Comment: https://git.openjdk.org/jdk/pull/23916#issuecomment-2775743849

From mchevalier at openjdk.org  Fri Apr  4 06:54:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 4 Apr 2025 06:54:53 GMT
Subject: RFR: 8346989: C2: deoptimization and re-execution cycle with
 Math.*Exact in case of frequent overflow [v7]
In-Reply-To: <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
Message-ID: <PZqZvf02pJ6YhLZeMkHdtC6CqXk8qNYQTk_nxdaQcTQ=.5798d026-717e-47cb-92b4-629e9c09dcc0@github.com>

On Thu, 3 Apr 2025 13:01:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove useless flags in tests

Thanks @iwanowww and @TobiHartmann!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23916#issuecomment-2777705340

From duke at openjdk.org  Fri Apr  4 06:54:53 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 06:54:53 GMT
Subject: RFR: 8346989: C2: deoptimization and re-execution cycle with
 Math.*Exact in case of frequent overflow [v7]
In-Reply-To: <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
 <SvOmLQvEzEYusf1s_yMvSDNBZpI0Vq6OJmfCgUg0S5g=.cb117280-e15e-447c-be98-97b103aeef0a@github.com>
Message-ID: <vxMRfNkWNGj2vg1FNWD1IZ4qoWfXjGYvh6K9XzZvPS0=.95848dc4-226f-4603-981e-3dcecba02ecd@github.com>

On Thu, 3 Apr 2025 13:01:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
>> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
>> 
>> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
>> 
>> tl;dr:
>> - C1: no problem, no change
>> - C2:
>>   - with intrinsics:
>>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>>     - without overflow: no problem, no change
>>   - without intrinsics: no problem, no change
>> 
>> Before the fix:
>> 
>> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
>> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
>> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
>> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
>> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
>> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
>> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
>> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
>> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
>> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
>> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
>> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
>> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
>> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
>> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
>> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
>> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
>> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
>> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
>> MathExact.C1_1.loop...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove useless flags in tests

@marc-chevalier 
Your change (at version e7c8f3e06f46e85cb3c2dc974db84b10a57bd086) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23916#issuecomment-2777706873

From tschatzl at openjdk.org  Fri Apr  4 08:10:34 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 4 Apr 2025 08:10:34 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - * missing file from merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
 - * make young gen length revising independent of refinement thread
     * use a service task
     * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
 - * fix IR code generation tests that change due to barrier cost changes
 - * factor out card table and refinement table merging into a single
     method
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
 - * obsolete G1UpdateBufferSize
   
   G1UpdateBufferSize has previously been used to size the refinement
   buffers and impose a minimum limit on the number of cards per thread
   that need to be pending before refinement starts.
   
   The former function is now obsolete with the removal of the dirty
   card queues, the latter functionality has been taken over by the new
   diagnostic option `G1PerThreadPendingCardThreshold`.
   
   I prefer to make this a diagnostic option is better than a product option
   because it is something that is only necessary for some test cases to
   produce some otherwise unwanted behavior (continuous refinement).
   
   CSR is pending.
 - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=29
  Stats: 7089 lines in 110 files changed: 2610 ins; 3555 del; 924 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From sviswanathan at openjdk.org  Sat Apr  5 00:44:56 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 5 Apr 2025 00:44:56 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13]
In-Reply-To: <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
Message-ID: <kJNQoNjlpokqv37o3ec8Js21IqCG1ASybG9VqDiwSDo=.ce1283d9-1bfe-4ed6-a613-d49ad1dca4e0@github.com>

On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to comment by Sandhya.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 339:

> 337: 
> 338:   // levels 2 to 7 are done in 2 batches, by first saving half of the coefficients
> 339:   // from level 1 into memory, doing all the level 2 to level 7 computations

In line number 344 - 347, we seem to be storing all the coefficients from level 1 into memory.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 345:

> 343: 
> 344:   store4Xmms(coeffs, 0, xmm0_3, _masm);
> 345:   store4Xmms(coeffs, 4 * XMMBYTES, xmm4_7, _masm);

This seems to be unnecessary store.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 370:

> 368:   loadPerm(xmm16_19, perms, nttL4PermsIdx, _masm);
> 369:   loadPerm(xmm12_15, perms, nttL4PermsIdx + 64, _masm);
> 370:   load4Xmms(xmm24_27, zetas, 4 * 512, _masm); // for level 3

The comment // for level3 is not relevant here and could be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029437396
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029578599
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029583308

From duke at openjdk.org  Sat Apr  5 14:29:28 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sat, 5 Apr 2025 14:29:28 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

Zihao Lin 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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8344116
 - Fix build
 - Fix test failed
 - 8344116: C2: remove slice parameter from LoadNode::make

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24258/files
  - new: https://git.openjdk.org/jdk/pull/24258/files/a1924c35..3efb1c17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24258&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24258&range=04-05

  Stats: 28443 lines in 792 files changed: 18710 ins; 7734 del; 1999 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

PR: https://git.openjdk.org/jdk/pull/24258

From duke at openjdk.org  Sun Apr  6 06:09:05 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sun, 6 Apr 2025 06:09:05 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <UV5AsCApOF_LUMHmokcDb7FRuhbQaikxcBOXYFRQ0-w=.86d81c61-c14e-4c05-9a0a-6d29c54bfe2d@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

Hi @TobiHartmann , Could you please take a look? Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24258#issuecomment-2781240184

From mchevalier at openjdk.org  Mon Apr  7 05:24:57 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 7 Apr 2025 05:24:57 GMT
Subject: Integrated: 8346989: C2: deoptimization and re-execution cycle with
 Math.*Exact in case of frequent overflow
In-Reply-To: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
References: <8ACplaVM_gN9cbIcQYGJmR4GNINm70PAJQ8uAgucK4Y=.14fdc7e2-e0af-4f0d-acb6-bcfe99ee8f36@github.com>
Message-ID: <0131FJuGwDAfwqB3GKnlj_9xeoinsnsUjNq8LodfkZE=.9501af2c-473f-4387-b319-aac1dff8cd18@github.com>

On Wed, 5 Mar 2025 12:56:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> `Math.*Exact` intrinsics can cause many deopt when used repeatedly with problematic arguments.
> This fix proposes not to rely on intrinsics after `too_many_traps()` has been reached.
> 
> Benchmark show that this issue affects every Math.*Exact functions. And this fix improve them all.
> 
> tl;dr:
> - C1: no problem, no change
> - C2:
>   - with intrinsics:
>     - with overflow: clear improvement. Was way worse than C1, now is similar (~4s => ~600ms)
>     - without overflow: no problem, no change
>   - without intrinsics: no problem, no change
> 
> Before the fix:
> 
> Benchmark                                           (SIZE)  Mode  Cnt     Score      Error  Units
> MathExact.C1_1.loopAddIInBounds                    1000000  avgt    3     1.272 ?    0.048  ms/op
> MathExact.C1_1.loopAddIOverflow                    1000000  avgt    3   641.917 ?   58.238  ms/op
> MathExact.C1_1.loopAddLInBounds                    1000000  avgt    3     1.402 ?    0.842  ms/op
> MathExact.C1_1.loopAddLOverflow                    1000000  avgt    3   671.013 ?  229.425  ms/op
> MathExact.C1_1.loopDecrementIInBounds              1000000  avgt    3     3.722 ?   22.244  ms/op
> MathExact.C1_1.loopDecrementIOverflow              1000000  avgt    3   653.341 ?  279.003  ms/op
> MathExact.C1_1.loopDecrementLInBounds              1000000  avgt    3     2.525 ?    0.810  ms/op
> MathExact.C1_1.loopDecrementLOverflow              1000000  avgt    3   656.750 ?  141.792  ms/op
> MathExact.C1_1.loopIncrementIInBounds              1000000  avgt    3     4.621 ?   12.822  ms/op
> MathExact.C1_1.loopIncrementIOverflow              1000000  avgt    3   651.608 ?  274.396  ms/op
> MathExact.C1_1.loopIncrementLInBounds              1000000  avgt    3     2.576 ?    3.316  ms/op
> MathExact.C1_1.loopIncrementLOverflow              1000000  avgt    3   662.216 ?   71.879  ms/op
> MathExact.C1_1.loopMultiplyIInBounds               1000000  avgt    3     1.402 ?    0.587  ms/op
> MathExact.C1_1.loopMultiplyIOverflow               1000000  avgt    3   615.836 ?  252.137  ms/op
> MathExact.C1_1.loopMultiplyLInBounds               1000000  avgt    3     2.906 ?    5.718  ms/op
> MathExact.C1_1.loopMultiplyLOverflow               1000000  avgt    3   655.576 ?  147.432  ms/op
> MathExact.C1_1.loopNegateIInBounds                 1000000  avgt    3     2.023 ?    0.027  ms/op
> MathExact.C1_1.loopNegateIOverflow                 1000000  avgt    3   639.136 ?   30.841  ms/op
> MathExact.C1_1.loopNegateLInBounds                 1000000  avgt    3     2.422 ?    3.59...

This pull request has now been integrated.

Changeset: 97ed5361
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97ed536125645304aed03a4afbc3ded627de0bb0
Stats:     845 lines in 6 files changed: 769 ins; 59 del; 17 mod

8346989: C2: deoptimization and re-execution cycle with Math.*Exact in case of frequent overflow

Reviewed-by: thartmann, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/23916

From thartmann at openjdk.org  Mon Apr  7 06:02:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Apr 2025 06:02:52 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v2]
In-Reply-To: <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
Message-ID: <uG2G3524j69XB7lehTy5dI_KIdl3mtrO0NMEQlgWui4=.c22d8754-9584-4e66-b805-2168beabdbf6@github.com>

On Mon, 31 Mar 2025 06:49:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
>> 
>> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
>> 
>> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
>> 
>> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
>> 
>> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   not reinventing the wheel

This looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24245#pullrequestreview-2745596627

From adinn at openjdk.org  Mon Apr  7 12:41:57 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Apr 2025 12:41:57 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v6]
In-Reply-To: <qeOJgpN2rrAvUsU18KhD7Mx6UWSsPzDBST3q12Ka4Xw=.a7726c19-a417-4d68-88bf-6486012bbd3c@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <qeOJgpN2rrAvUsU18KhD7Mx6UWSsPzDBST3q12Ka4Xw=.a7726c19-a417-4d68-88bf-6486012bbd3c@github.com>
Message-ID: <G0TE1VwGyRypUbE63e3Oh2H_OLj9CH4KJEdrn5e3OsY=.859f3f12-43da-4328-a37f-56204621162a@github.com>

On Sun, 23 Mar 2025 17:00:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merged master.
>  - Fixed bad assertion.
>  - Fixed mismerge.
>  - Merged master.
>  - A little cleanup
>  - Merged master
>  - removing trailing spaces
>  - kyber aarch64 intrinsics

@ferakocz Thanks for another very good piece of work which appears to me to be functioning correctly and performantly.

The PR suffers from the same problems as the original ML_DSA one i.e. The mapping of data to registers and the overall structure of the generated code and its relation to the related Java code/the original algorithms will be hard for a maintainer to identify. I have reworked your patch to use vector sequences in this [draft PR](https://github.com/openjdk/jdk/pull/24419) in very much the same way as was done for the ML_DSA PR. This has significantly abstracted and clarified the register mappings that are in use in each kyber generator and has also made the higher level structure of the generated code much easier to follow.

Note that my rework of the generation routines was applied to your original PR after rebasing it on master. Before updating the kyber routines I also generalized a few of the VSeq<N> methods that benefit from being shared by both kyber and dilithium, most notably the montmul routines, and I added a few extra helpers.

The reworked version passes the ML_KEM functional test and gives similar performance improvements for the ML_KEM micro benchmark. The generated code does differ in a few places from what your original patch generates but only superficially - most notable is that a few loads/stores that rely on continued post-increments in the original instead use a constant offset or an add/load pair in the reworked code. This makes a very minor difference to code size and does not seem to affect performance.

I would like you to rework your PR to incorporate these changes because I believe it will make a big difference to maintainability.  n.b. it may be easier to integrate my changes by diffing your branch and mine and applying the resulting change set rather than trying to merge the changes. Please let me know if you have problems with the integration and need help.

I still have some further review comments and would also like to see more commenting to explain what the code is doing. However, I think it will be easier to do that after this rework has been integrated into your PR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23663#pullrequestreview-2746672860

From yzheng at openjdk.org  Mon Apr  7 14:27:30 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 7 Apr 2025 14:27:30 GMT
Subject: RFR: 8353735: [JVMCI] Allow specifying storage kind of the callee save
 register
Message-ID: <taWIY9EOZM8y920O4_MFI_-XpScHPSWbgpZqDrxOVdw=.20087dd3-85c4-444d-b4fc-4baae7acc2e2@github.com>

Windows x64 ABI considers the upper portions of YMM0-YMM15 and ZMM0-ZMM15 volatile, that is, destroyed on function calls. This PR allows `RegisterConfig` implementations to refine the storage kind of callee save register, such that JVMCI compiler can exploit this information to avoid backing up full width of these registers.

-------------

Commit messages:
 - [JVMCI] Allow specifying storage kind of the callee save register

Changes: https://git.openjdk.org/jdk/pull/24451/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24451&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353735
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24451.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24451/head:pull/24451

PR: https://git.openjdk.org/jdk/pull/24451

From dnsimon at openjdk.org  Mon Apr  7 14:49:37 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 7 Apr 2025 14:49:37 GMT
Subject: RFR: 8353735: [JVMCI] Allow specifying storage kind of the callee
 save register
In-Reply-To: <taWIY9EOZM8y920O4_MFI_-XpScHPSWbgpZqDrxOVdw=.20087dd3-85c4-444d-b4fc-4baae7acc2e2@github.com>
References: <taWIY9EOZM8y920O4_MFI_-XpScHPSWbgpZqDrxOVdw=.20087dd3-85c4-444d-b4fc-4baae7acc2e2@github.com>
Message-ID: <Ua_Q8L_bJQjnUyqHH7tpqpsJs1K7FYBvztu2XCL4pF0=.4ba355c7-2c10-46e6-9d7e-c85a0c1d34b6@github.com>

On Fri, 4 Apr 2025 14:47:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> Windows x64 ABI considers the upper portions of YMM0-YMM15 and ZMM0-ZMM15 volatile, that is, destroyed on function calls. This PR allows `RegisterConfig` implementations to refine the storage kind of callee save register, such that JVMCI compiler can exploit this information to avoid backing up full width of these registers.

Marked as reviewed by dnsimon (Reviewer).

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/RegisterConfig.java line 98:

> 96: 
> 97:     /**
> 98:      * Gets the storage kind for a callee save register.

I would add a second sentence describing the Window ABI example so that it's clear why this API exists.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24451#pullrequestreview-2747108590
PR Review Comment: https://git.openjdk.org/jdk/pull/24451#discussion_r2031411734

From roland at openjdk.org  Mon Apr  7 15:20:16 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 7 Apr 2025 15:20:16 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v2]
In-Reply-To: <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <hTYBeyYtwi4_FZm-EcINqfS86Y0N7NQS9dwE1VCsC80=.284c8bef-907e-4a6d-beb3-6ce2f611587e@github.com>
Message-ID: <MuwSHJyiEamxbhsgwDho0Zam0SROSnj2JbiKfuWGmSY=.7b4bc247-3613-4d93-93ae-b65ff0f82869@github.com>

On Mon, 31 Mar 2025 06:49:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
>> 
>> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
>> 
>> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
>> 
>> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
>> 
>> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   not reinventing the wheel

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24245#pullrequestreview-2747218926

From cslucas at openjdk.org  Mon Apr  7 19:04:15 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 7 Apr 2025 19:04:15 GMT
Subject: RFR: 8353735: [JVMCI] Allow specifying storage kind of the callee
 save register
In-Reply-To: <taWIY9EOZM8y920O4_MFI_-XpScHPSWbgpZqDrxOVdw=.20087dd3-85c4-444d-b4fc-4baae7acc2e2@github.com>
References: <taWIY9EOZM8y920O4_MFI_-XpScHPSWbgpZqDrxOVdw=.20087dd3-85c4-444d-b4fc-4baae7acc2e2@github.com>
Message-ID: <4o1jkl6NOwwVZ0--oMiBOOLnRzE0OIO6JazFL_gV4UU=.7d25433e-7507-49f0-afab-091bb7f2305d@github.com>

On Fri, 4 Apr 2025 14:47:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> Windows x64 ABI considers the upper portions of YMM0-YMM15 and ZMM0-ZMM15 volatile, that is, destroyed on function calls. This PR allows `RegisterConfig` implementations to refine the storage kind of callee save register, such that JVMCI compiler can exploit this information to avoid saving full width of these registers.

LGTM

-------------

Marked as reviewed by cslucas (Author).

PR Review: https://git.openjdk.org/jdk/pull/24451#pullrequestreview-2747807421

From sviswanathan at openjdk.org  Tue Apr  8 00:12:15 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 8 Apr 2025 00:12:15 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13]
In-Reply-To: <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
Message-ID: <hBL-CmwYi2SdxcVDCktCYuz28HPq6xp3D0YwNoac2mA=.e8c0bb2c-801f-4fef-8831-345153419dff@github.com>

On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to comment by Sandhya.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 802:

> 800:   __ evpbroadcastd(zero, scratch, Assembler::AVX_512bit); // 0
> 801:   __ addl(scratch, 1);
> 802:   __ evpbroadcastd(one, scratch, Assembler::AVX_512bit); // 1

A better way to initialize (0, 1, -1) vectors is:
// load 0 into int vector
vpxor(zero, zero, zero, Assembler::AVX_512bit);
// load -1 into int vector
vpternlogd(minusOne, 0xff, minusOne, minusOne, Assembler::AVX_512bit);
// load 1 into int vector
vpsubd(one, zero, minusOne, Assembler::AVX_512bit);

Where minusOne could be xmm31. 

A broadcast from r register to xmm register is more expensive.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 982:

> 980:   __ evporq(xmm19, k0, xmm19, xmm23, false, Assembler::AVX_512bit);
> 981: 
> 982:   __ evpsubd(xmm12, k0, zero, one, false, Assembler::AVX_512bit); // -1

The -1 initialization could be done outside the loop.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1015:

> 1013:   __ addptr(lowPart, 4 * XMMBYTES);
> 1014:   __ cmpl(len, 0);
> 1015:   __ jcc(Assembler::notEqual, L_loop);

It looks to me that subl and cmpl could be merged:
  __ addptr(highPart, 4 * XMMBYTES);
  __ addptr(lowPart, 4 * XMMBYTES);
  __ subl(len, 4 * XMMBYTES);
  __ jcc(Assembler::notEqual, L_loop);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2032172061
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2032171059
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2031979828

From thartmann at openjdk.org  Tue Apr  8 08:05:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Apr 2025 08:05:29 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <ckmsCGQWmE8_DR7uyfvs4nTYaoUNw73Wlf9LJ9GshFE=.c48d2a36-9da5-4358-a27d-04ee530cd41c@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

I think @rwestrel should have a look at this, since he suggested the cleanup in https://github.com/openjdk/jdk/pull/21834.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24258#issuecomment-2785582950

From roland at openjdk.org  Tue Apr  8 13:14:25 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 8 Apr 2025 13:14:25 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <F05XhIeM-2KYesDRQ4dtGv2iui5GvLh3hF_udP5IFjM=.8fd0ede3-df42-4d10-9aa9-85e6ea500d4a@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 223:

> 221:     MergeMemNode* mm = opt_access.mem();
> 222:     PhaseGVN& gvn = opt_access.gvn();
> 223:     Node* mem = mm->memory_at(gvn.C->get_alias_index(access.addr().type()));

Can we get rid of all uses of `access.addr().type()`?

src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp line 105:

> 103:     // stores.  In theory we could relax the load from ctrl() to
> 104:     // no_ctrl, but that doesn't buy much latitude.
> 105:     Node* card_val = __ load( __ ctrl(), card_adr, TypeInt::BYTE, T_BYTE);

We could asssert that `C->get_alias_index(kit->type(card_adr) == Compile::AliasIdxRaw`, that is that computed slice is the same as hardcoded slide. Similar asserts could be added for every location where a slice/address type is removed in this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2033149694
PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2033162534

From duke at openjdk.org  Tue Apr  8 21:27:08 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 8 Apr 2025 21:27:08 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Reacting to mor comments from Sandhya.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/e4ab10bb..0b0d0969

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=12-13

  Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

PR: https://git.openjdk.org/jdk/pull/23860

From duke at openjdk.org  Tue Apr  8 21:29:26 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 8 Apr 2025 21:29:26 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13]
In-Reply-To: <kJNQoNjlpokqv37o3ec8Js21IqCG1ASybG9VqDiwSDo=.ce1283d9-1bfe-4ed6-a613-d49ad1dca4e0@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <WPb92OXxq17brOLXL4xigtIrlAm69DXYo-qQnLLjqww=.bbdbeffe-af85-4151-a68c-239a38c51033@github.com>
 <kJNQoNjlpokqv37o3ec8Js21IqCG1ASybG9VqDiwSDo=.ce1283d9-1bfe-4ed6-a613-d49ad1dca4e0@github.com>
Message-ID: <B4Oq7Pdu_lq_PMFAR3hqKEE3qWsKaeTnKGf4cW2nZOs=.75cbc4e5-e3d4-41a1-8a73-624537c482a1@github.com>

On Sat, 5 Apr 2025 00:27:05 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reacting to comment by Sandhya.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 345:
> 
>> 343: 
>> 344:   store4Xmms(coeffs, 0, xmm0_3, _masm);
>> 345:   store4Xmms(coeffs, 4 * XMMBYTES, xmm4_7, _masm);
> 
> This seems to be unnecessary store.

Thanks for catching that. Changed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 370:
> 
>> 368:   loadPerm(xmm16_19, perms, nttL4PermsIdx, _masm);
>> 369:   loadPerm(xmm12_15, perms, nttL4PermsIdx + 64, _masm);
>> 370:   load4Xmms(xmm24_27, zetas, 4 * 512, _masm); // for level 3
> 
> The comment // for level3 is not relevant here and could be removed.

Ooops. Deleted the comment.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 802:
> 
>> 800:   __ evpbroadcastd(zero, scratch, Assembler::AVX_512bit); // 0
>> 801:   __ addl(scratch, 1);
>> 802:   __ evpbroadcastd(one, scratch, Assembler::AVX_512bit); // 1
> 
> A better way to initialize (0, 1, -1) vectors is:
> // load 0 into int vector
> vpxor(zero, zero, zero, Assembler::AVX_512bit);
> // load -1 into int vector
> vpternlogd(minusOne, 0xff, minusOne, minusOne, Assembler::AVX_512bit);
> // load 1 into int vector
> vpsubd(one, zero, minusOne, Assembler::AVX_512bit);
> 
> Where minusOne could be xmm31. 
> 
> A broadcast from r register to xmm register is more expensive.

Changed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 982:
> 
>> 980:   __ evporq(xmm19, k0, xmm19, xmm23, false, Assembler::AVX_512bit);
>> 981: 
>> 982:   __ evpsubd(xmm12, k0, zero, one, false, Assembler::AVX_512bit); // -1
> 
> The -1 initialization could be done outside the loop.

Not really. All registers are used.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1015:
> 
>> 1013:   __ addptr(lowPart, 4 * XMMBYTES);
>> 1014:   __ cmpl(len, 0);
>> 1015:   __ jcc(Assembler::notEqual, L_loop);
> 
> It looks to me that subl and cmpl could be merged:
>   __ addptr(highPart, 4 * XMMBYTES);
>   __ addptr(lowPart, 4 * XMMBYTES);
>   __ subl(len, 4 * XMMBYTES);
>   __ jcc(Assembler::notEqual, L_loop);

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057184
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057342
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057700
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057565
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057463

From sviswanathan at openjdk.org  Tue Apr  8 22:01:42 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 8 Apr 2025 22:01:42 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
Message-ID: <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com>

On Tue, 8 Apr 2025 21:27:08 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to mor comments from Sandhya.

Overall very clean and nicely done PR. Thanks a lot for considering my inputs.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2751503300

From mchevalier at openjdk.org  Wed Apr  9 07:20:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Apr 2025 07:20:00 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v3]
In-Reply-To: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
Message-ID: <bWiSM_qt-U_nWWTPCWRfJpxMrC7ttFp-jPsGFqYB3mY=.f4823a96-7ccd-46e3-acee-62d068a4b428@github.com>

> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
> 
> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
> 
> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
> 
> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
> 
> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
> 
> Thanks,
> Marc

Marc Chevalier 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 five additional commits since the last revision:

 - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
 - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
 - not reinventing the wheel
 - Revert now useless fix
 - Generalize the not-array proof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24245/files
  - new: https://git.openjdk.org/jdk/pull/24245/files/daaaf9ae..b1fb82a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24245&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24245&range=01-02

  Stats: 74611 lines in 2220 files changed: 27997 ins; 41827 del; 4787 mod
  Patch: https://git.openjdk.org/jdk/pull/24245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24245/head:pull/24245

PR: https://git.openjdk.org/jdk/pull/24245

From mchevalier at openjdk.org  Wed Apr  9 09:19:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Apr 2025 09:19:39 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v3]
In-Reply-To: <bWiSM_qt-U_nWWTPCWRfJpxMrC7ttFp-jPsGFqYB3mY=.f4823a96-7ccd-46e3-acee-62d068a4b428@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <bWiSM_qt-U_nWWTPCWRfJpxMrC7ttFp-jPsGFqYB3mY=.f4823a96-7ccd-46e3-acee-62d068a4b428@github.com>
Message-ID: <1kzdW30AxgS9RnVEzxrwkkQk8dwxOT79wloukL-Vz38=.8c62c7ef-10b0-4011-8744-7ae24211362c@github.com>

On Wed, 9 Apr 2025 07:20:00 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
>> 
>> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
>> 
>> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
>> 
>> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
>> 
>> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
>  - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
>  - not reinventing the wheel
>  - Revert now useless fix
>  - Generalize the not-array proof

The branch was a bit old, so I've merged master in it and run tests. It seems all good!
Thanks @TobiHartmann and @rwestrel for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24245#issuecomment-2788948220

From duke at openjdk.org  Wed Apr  9 09:19:40 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 09:19:40 GMT
Subject: RFR: 8348853: Fold layout helper check for objects implementing
 non-array interfaces [v3]
In-Reply-To: <bWiSM_qt-U_nWWTPCWRfJpxMrC7ttFp-jPsGFqYB3mY=.f4823a96-7ccd-46e3-acee-62d068a4b428@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
 <bWiSM_qt-U_nWWTPCWRfJpxMrC7ttFp-jPsGFqYB3mY=.f4823a96-7ccd-46e3-acee-62d068a4b428@github.com>
Message-ID: <qmcrvTiC9elR5w06JnEOLOmkm8GUkZeg0HL5kjEr8gc=.03f5f3b0-67d7-4388-8a02-50983e5bde6d@github.com>

On Wed, 9 Apr 2025 07:20:00 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
>> 
>> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
>> 
>> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
>> 
>> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
>> 
>> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
>  - Merge branch 'master' into feat/Fold-layout-helper-check-for-objects-implementing-non-array-interfaces
>  - not reinventing the wheel
>  - Revert now useless fix
>  - Generalize the not-array proof

@marc-chevalier 
Your change (at version b1fb82a28a4f6c3f126d312727cb9f89a9f51669) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24245#issuecomment-2788951877

From mchevalier at openjdk.org  Wed Apr  9 09:31:49 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Apr 2025 09:31:49 GMT
Subject: Integrated: 8348853: Fold layout helper check for objects implementing
 non-array interfaces
In-Reply-To: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
References: <CptyYNIV6gQls75ydTAEKDlNDgQyFA6vXepsdzxvTyA=.c0bf07ae-4da7-4649-b36a-d568755cf4ac@github.com>
Message-ID: <LcipvYqkg-0t-nsVLTlW_9eiDfnLxb_K9nodRw8oF2M=.37c307d9-8530-4bb9-be9a-0a37ffe74274@github.com>

On Wed, 26 Mar 2025 09:16:17 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> If `TypeInstKlassPtr` represents an array type, it has to be `java.lang.Object`. From contraposition, if it is not `java.lang.Object`, we can conclude it is not an array, and we can skip some array checks, for instance.
> 
> In this PR, we improve this deduction with an interface base reasoning: arrays implements only Cloneable and Serializable, so if a type implements anything else, it cannot be an array.
> 
> This change partially reverts the changes from [JDK-8348631](https://bugs.openjdk.org/browse/JDK-8348631) (#23331) (in `LibraryCallKit::generate_array_guard_common`) and the test still passes.
> 
> The way interfaces are check might be done differently. The current situation is a balance between visibility (not to leak too much things explicitly private), having not overly general methods for one use-case and avoiding too concrete (and brittle) interfaces.
> 
> Tested with tier1..3, hs-precheckin-comp and hs-comp-stress
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: a1d566ce
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1d566ce4b0315591ece489347c5d1c253f06be9
Stats:     34 lines in 5 files changed: 23 ins; 7 del; 4 mod

8348853: Fold layout helper check for objects implementing non-array interfaces

Reviewed-by: thartmann, roland

-------------

PR: https://git.openjdk.org/jdk/pull/24245

From ayang at openjdk.org  Wed Apr  9 10:36:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Apr 2025 10:36:44 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
Message-ID: <fTW6CPZ_grZelZwXhc0IblYf2CEpjb5fhA9ovVU7sVw=.594576dc-e9b3-4bdf-84e7-d403d0190e38@github.com>

On Fri, 4 Apr 2025 08:10:34 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - * missing file from merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 170:

> 168:   }
> 169:   return result;
> 170: }

I see in `G1ConcurrentRefineThread::do_refinement`:

      // The yielding may have completed the task, check.
      if (!state.is_in_progress()) {

I wonder if it's simpler to use `is_in_progress` consistently to detect whether we should restart sweep, instead of `_sweep_start_epoch`.

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 349:

> 347:   }
> 348: 
> 349:   bool has_sweep_rt_work = is_in_progress() && _state == State::SweepRT;

Why `is_in_progress()`?

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 79:

> 77: 
> 78:   void inc_cards_scanned(size_t increment = 1) { _cards_scanned += increment; }
> 79:   void inc_cards_clean(size_t increment = 1) { _cards_clean += increment; }

The sole caller always passes in arg, so no need for default-arg-value.

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 87:

> 85:   void add_atomic(G1ConcurrentRefineStats* other);
> 86: 
> 87:   G1ConcurrentRefineStats& operator+=(const G1ConcurrentRefineStats& other);

Seems that these operators are not used after this PR.

src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:

> 81:         break;
> 82:       }
> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.

Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)

src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 156:

> 154: 
> 155:       _refine_stats.inc_cards_scanned(claim.size());
> 156:       _refine_stats.inc_cards_clean(claim.size() - scanned);

I feel these two "scanned" mean sth diff; the local var should probably be sth like `num_dirty_cards`.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 207:

> 205: 
> 206:   if (!interrupted_by_gc) {
> 207:     state.add_yield_duration(G1CollectedHeap::heap()->safepoint_duration() - synchronize_duration_at_sweep_start);

I think this is recorded to later calculate actual refine-time, i.e. sweep-time - yield-time. However, why can't yield-duration be recorded in this refine-control-thread directly --  accumulation of `jlong yield_duration = os::elapsed_counter() - yield_start`. I feel that is easier to reason than going through g1heap.

src/hotspot/share/gc/g1/g1ReviseYoungListTargetLengthTask.cpp line 75:

> 73:   {
> 74:     MutexLocker x(G1ReviseYoungLength_lock, Mutex::_no_safepoint_check_flag);
> 75:     G1Policy* p = g1h->policy();

Can probably use the existing `policy`.

src/hotspot/share/gc/g1/g1ReviseYoungListTargetLengthTask.cpp line 88:

> 86: }
> 87: 
> 88: G1ReviseYoungLengthTargetLengthTask::G1ReviseYoungLengthTargetLengthTask(const char* name) :

I wonder if the class name can be shortened a bit, sth like `G1ReviseYoungLengthTask`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033251162
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033222407
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033929489
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033975054
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033934399
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033910496
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2032008908
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2029855278
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2029855435

From rcastanedalo at openjdk.org  Wed Apr  9 12:03:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Apr 2025 12:03:49 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
Message-ID: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>

On Fri, 4 Apr 2025 08:10:34 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - * missing file from merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

Hi Thomas, great simplification and encouraging results! I reviewed the compiler-related parts of the changeset, including x64 and aarch64 changes.

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 246:

> 244:     __ cbz(new_val, done);
> 245:   }
> 246:   // Storing region crossing non-null, is card young?

Suggestion:

  // Storing region crossing non-null.

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:

> 99: }
> 100: 
> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,

Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 145:

> 143: 
> 144:   __ bind(is_clean_card);
> 145:   // Card was clean. Dirty card and go to next..

This code seems unreachable if `!UseCondCardMark`, meaning we only dirty cards here if `UseCondCardMark` is enabled. Is that intentional?

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 319:

> 317:                                             const Register thread,
> 318:                                             const Register tmp1,
> 319:                                             const Register tmp2,

Since `tmp2` is not needed in the x64 post-barrier, I suggest not passing it around for this platform, for simplicity and also to make optimization opportunities more visible in the future. Here is my suggestion: https://github.com/robcasloz/jdk/commit/855ec8df4a641f8c491c5c09acea3ee434b7e230, feel free to merge if you agree.

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 38:

> 36: #include "c1/c1_LIRAssembler.hpp"
> 37: #include "c1/c1_MacroAssembler.hpp"
> 38: #endif // COMPILER1

I suggest removing the conditional compilation directives and grouping these includes together with the above `c1` ones.

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 147:

> 145:     state->do_input(_thread);
> 146: 
> 147:     // Use temp registers to ensure these they use different registers.

Suggestion:

    // Use temps to enforce different registers.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 307:

> 305:              + 6  // same region check: Uncompress (new_val) oop, xor, shr, (cmp), jmp
> 306:              + 4  // new_val is null check
> 307:              + 4; // card not clean check.

It probably does not affect the unrolling heuristics too much, but you may want to make the last cost component conditional on `UseCondCardMark`.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 396:

> 394:   bool needs_liveness_data(const MachNode* mach) const {
> 395:     return G1BarrierStubC2::needs_pre_barrier(mach) ||
> 396:            G1BarrierStubC2::needs_post_barrier(mach);

Suggestion:

    // Liveness data is only required to compute registers that must be
    // preserved across the runtime call in the pre-barrier stub.
    return G1BarrierStubC2::needs_pre_barrier(mach);

src/hotspot/share/gc/g1/g1BarrierSet.hpp line 56:

> 54: //
> 55: // The refinement threads mark cards in the current collection set specially on the
> 56: // card table - this is fine wrt to synchronization with the mutator, because at

Suggestion:

// card table - this is fine wrt synchronization with the mutator, because at

test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java line 521:

> 519:         phase = CompilePhase.FINAL_CODE)
> 520:     @IR(counts = {IRNode.COUNTED_LOOP, "2"},
> 521:         phase = CompilePhase.FINAL_CODE)

I suggest to remove this extra IR check to avoid over-specifying the expected loop shape. For example, running this test with loop unrolling disabled (`-XX:LoopUnrollLimit=0`) would now fail because only one counted loop would be found.

-------------

Changes requested by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-2753154117
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035174209
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035175921
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035177738
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035183250
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035186980
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035192666
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035210464
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035196251
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035198219
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035201056

From tschatzl at openjdk.org  Wed Apr  9 12:41:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 12:41:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
Message-ID: <Bn3lOZk7rk_VhnaZ0tQfZLoIWsD5r0moPg6-7uLScWk=.e956af46-3218-4e63-9ad4-e608f07294a7@github.com>

On Wed, 9 Apr 2025 11:35:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
>> 
>>  - * missing file from merge
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 145:
> 
>> 143: 
>> 144:   __ bind(is_clean_card);
>> 145:   // Card was clean. Dirty card and go to next..
> 
> This code seems unreachable if `!UseCondCardMark`, meaning we only dirty cards here if `UseCondCardMark` is enabled. Is that intentional?

Great find!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035280909

From tschatzl at openjdk.org  Wed Apr  9 12:50:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 12:50:42 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
Message-ID: <oUeBCoxLt3yq4WW5ozwkmNQ9gG3serjASbsnQ2873ig=.eb437d04-a608-43e6-b5bd-28744cd872b1@github.com>

On Wed, 9 Apr 2025 11:34:09 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
>> 
>>  - * missing file from merge
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:
> 
>> 99: }
>> 100: 
>> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
> 
> Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?

I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
I will try to redo numbers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035298557

From tschatzl at openjdk.org  Wed Apr  9 14:38:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 14:38:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <fTW6CPZ_grZelZwXhc0IblYf2CEpjb5fhA9ovVU7sVw=.594576dc-e9b3-4bdf-84e7-d403d0190e38@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <fTW6CPZ_grZelZwXhc0IblYf2CEpjb5fhA9ovVU7sVw=.594576dc-e9b3-4bdf-84e7-d403d0190e38@github.com>
Message-ID: <lOSK0cnsvwEcWVAptet6vDxJNXEwtnNwRgdMMypcNxc=.efc363d5-5d03-44ab-b747-fc50c0f68f67@github.com>

On Tue, 8 Apr 2025 19:59:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
>> 
>>  - * missing file from merge
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:
> 
>> 81:         break;
>> 82:       }
>> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.
> 
> Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)

"NoInteresting" means that the card contains no interesting reference at all. "HasRefToOld" means that there has been an interesting reference in the card.

The distinction between these groups of cards seems interesting to me. E.g. out of X non-clean cards, there were A with a reference to the collection set, B that were already marked as containing a card to the collection, C not having any interesting card any more (transitioned from clean -> dirty -> clean, and cleared by the mutator), D being non-parsable, and E having references to old (and no other references).

I could add a separate counter for these type of cards too - they can be inferred from the total number of scanned minus the others though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035512686

From duke at openjdk.org  Wed Apr  9 17:12:47 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 9 Apr 2025 17:12:47 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
 <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com>
Message-ID: <FJTDvKao0z5frSWzS2ZWCGznRxY1J6Mg2wbmwyslcnI=.b0486218-690a-42a4-8493-138ec4000c10@github.com>

On Tue, 8 Apr 2025 21:58:57 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Overall very clean and nicely done PR. Thanks a lot for considering my inputs.

That is in no small part thanks to the reviewers, especially to Volodymyr!
@lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790417248

From sviswanathan at openjdk.org  Wed Apr  9 18:42:45 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Apr 2025 18:42:45 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <FJTDvKao0z5frSWzS2ZWCGznRxY1J6Mg2wbmwyslcnI=.b0486218-690a-42a4-8493-138ec4000c10@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
 <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com>
 <FJTDvKao0z5frSWzS2ZWCGznRxY1J6Mg2wbmwyslcnI=.b0486218-690a-42a4-8493-138ec4000c10@github.com>
Message-ID: <u59jgL2LqXcwfMHekqHS5t-sHVe6W8sgUfuv2s-77d8=.322433e6-cb42-4699-a2ba-a28f586f0616@github.com>

On Wed, 9 Apr 2025 17:09:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Overall very clean and nicely done PR. Thanks a lot for considering my inputs.
>
>> Overall very clean and nicely done PR. Thanks a lot for considering my inputs.
> 
> That is in no small part thanks to the reviewers, especially to Volodymyr!
> @lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration?

@ferakocz Once you do /integrate, I will be honored to sponsor your PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790618572

From duke at openjdk.org  Wed Apr  9 19:33:37 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 19:33:37 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
Message-ID: <oQdKP1c5EfsimI8TcY5sOFwQ77N2AEcFJBxDNh9khto=.6b4d1034-9b2f-434c-9753-275524175cb4@github.com>

On Tue, 8 Apr 2025 21:27:08 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reacting to mor comments from Sandhya.

@ferakocz 
Your change (at version 0b0d0969d6ac629bf2ca997d2286c4d28f91c1b9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790791121

From duke at openjdk.org  Wed Apr  9 19:33:35 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 9 Apr 2025 19:33:35 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14]
In-Reply-To: <FJTDvKao0z5frSWzS2ZWCGznRxY1J6Mg2wbmwyslcnI=.b0486218-690a-42a4-8493-138ec4000c10@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com>
 <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com>
 <FJTDvKao0z5frSWzS2ZWCGznRxY1J6Mg2wbmwyslcnI=.b0486218-690a-42a4-8493-138ec4000c10@github.com>
Message-ID: <lnhjS5o6Z20kwDVU4tgQxRKA4QpcP5Mjpm95hOzfWco=.cc4ceef4-7b34-440e-a597-a794abbfc538@github.com>

On Wed, 9 Apr 2025 17:09:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Overall very clean and nicely done PR. Thanks a lot for considering my inputs.
>
>> Overall very clean and nicely done PR. Thanks a lot for considering my inputs.
> 
> That is in no small part thanks to the reviewers, especially to Volodymyr!
> @lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration?

> @ferakocz Once you do /integrate, I will be honored to sponsor your PR.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790788483

From duke at openjdk.org  Wed Apr  9 21:18:35 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 9 Apr 2025 21:18:35 GMT
Subject: Integrated: 8351034: Add AVX-512 intrinsics for ML-DSA
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <UKEQhs4hAb5UQXNyc-MdiT3Vhs448BGwZBDdu2K4WNI=.95fb69d6-a91d-4128-9249-ae86a741fc21@github.com>

On Mon, 3 Mar 2025 11:12:58 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

This pull request has now been integrated.

Changeset: e87ff328
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e87ff328d5cc66454213dee44cf2faeb0e76262f
Stats:     1307 lines in 10 files changed: 1265 ins; 27 del; 15 mod

8351034: Add AVX-512 intrinsics for ML-DSA

Reviewed-by: sviswanathan, lmesnik, vpaprotski, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/23860

From mdoerr at openjdk.org  Wed Apr  9 22:26:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Apr 2025 22:26:31 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
Message-ID: <IWrHmtOiI0GWuRkJg6XQC4v130iqFtvCgLKVf04qZ_s=.a13ae17e-0d21-42bf-8a2f-24e1dee22605@github.com>

On Fri, 4 Apr 2025 08:10:34 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - * missing file from merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

This PR needs an update for x86 platforms when merging: g1BarrierSetAssembler_x86.cpp:117:6: error: 'class MacroAssembler' has no member named 'get_thread'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791114662

From tschatzl at openjdk.org  Thu Apr 10 07:26:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 07:26:28 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v31]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <ixRn7EuMX8T-bx7n49PMWpz26_YlJgBFjEPt9jWG1N8=.7442b05f-6ce1-4135-8c68-511f5fc10389@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - Do not unnecessarily pass around tmp2 in x86
 - Refine needs_liveness_data
 - Reorder includes
 - * missing file from merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 35 more: https://git.openjdk.org/jdk/compare/45b7c748...39aa903f

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=30
  Stats: 7118 lines in 110 files changed: 2586 ins; 3598 del; 934 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Thu Apr 10 07:28:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 07:28:31 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <IWrHmtOiI0GWuRkJg6XQC4v130iqFtvCgLKVf04qZ_s=.a13ae17e-0d21-42bf-8a2f-24e1dee22605@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <IWrHmtOiI0GWuRkJg6XQC4v130iqFtvCgLKVf04qZ_s=.a13ae17e-0d21-42bf-8a2f-24e1dee22605@github.com>
Message-ID: <rAGie3DoeWwYuMTNf7auCwVOpXi84_ojazShjS5vCy0=.923ed647-44ce-44c1-a4a4-53dc3243ca7b@github.com>

On Wed, 9 Apr 2025 22:24:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This PR needs an update for x86 platforms when merging: g1BarrierSetAssembler_x86.cpp:117:6: error: 'class MacroAssembler' has no member named 'get_thread'

I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791807489

From shade at openjdk.org  Thu Apr 10 08:36:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 08:36:33 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <rAGie3DoeWwYuMTNf7auCwVOpXi84_ojazShjS5vCy0=.923ed647-44ce-44c1-a4a4-53dc3243ca7b@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <IWrHmtOiI0GWuRkJg6XQC4v130iqFtvCgLKVf04qZ_s=.a13ae17e-0d21-42bf-8a2f-24e1dee22605@github.com>
 <rAGie3DoeWwYuMTNf7auCwVOpXi84_ojazShjS5vCy0=.923ed647-44ce-44c1-a4a4-53dc3243ca7b@github.com>
Message-ID: <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>

On Thu, 10 Apr 2025 07:25:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.

I think all x86 cleanups related to GC and adjacent code have landed in mainline now. So I expect no more major conflicts with this PR :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791985351

From tschatzl at openjdk.org  Thu Apr 10 09:07:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 09:07:39 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v32]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <boOSGTr4XaayOdjRQ_9rBSpwiWjBBJrjNoM8gMufU-o=.fe1d6aea-34be-4204-8039-3c255ff8b225@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - Do not unnecessarily pass around tmp2 in x86
 - Refine needs_liveness_data
 - Reorder includes
 - * missing file from merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 36 more: https://git.openjdk.org/jdk/compare/f94a4f7a...fcf96a2a

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=31
  Stats: 7112 lines in 110 files changed: 2592 ins; 3594 del; 926 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From ayang at openjdk.org  Thu Apr 10 09:12:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 10 Apr 2025 09:12:32 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <lOSK0cnsvwEcWVAptet6vDxJNXEwtnNwRgdMMypcNxc=.efc363d5-5d03-44ab-b747-fc50c0f68f67@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <fTW6CPZ_grZelZwXhc0IblYf2CEpjb5fhA9ovVU7sVw=.594576dc-e9b3-4bdf-84e7-d403d0190e38@github.com>
 <lOSK0cnsvwEcWVAptet6vDxJNXEwtnNwRgdMMypcNxc=.efc363d5-5d03-44ab-b747-fc50c0f68f67@github.com>
Message-ID: <qpJhHw7gYJBk4pmgH9XlRR27EvNggOvumgyodr77OGQ=.89e3815a-bb91-4597-b35e-c2e37f9a97b4@github.com>

On Wed, 9 Apr 2025 14:32:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:
>> 
>>> 81:         break;
>>> 82:       }
>>> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.
>> 
>> Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)
>
> "NoInteresting" means that the card contains no interesting reference at all. "HasRefToOld" means that there has been an interesting reference in the card.
> 
> The distinction between these groups of cards seems interesting to me. E.g. out of X non-clean cards, there were A with a reference to the collection set, B that were already marked as containing a card to the collection, C not having any interesting card any more (transitioned from clean -> dirty -> clean, and cleared by the mutator), D being non-parsable, and E having references to old (and no other references).
> 
> I could add a separate counter for these type of cards too - they can be inferred from the total number of scanned minus the others though.

I see; "clean again" means the existing interesting pointer was overwritten by mutator.

I misinterpret the comment as cards transitioned from dirty to clean. `  size_t _cards_clean_again;          // Dirtied cards that were cleaned.`

To prevent misunderstanding, what do you think of renaming "NoInteresting" to "NoCrossRegion" and "_cards_clean_again" to "_cards_no_cross_region", or sth alike so that the 1:1 mapping is clearer?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2036885633

From tschatzl at openjdk.org  Thu Apr 10 10:02:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 10:02:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/fcf96a2a..068d2a37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=31-32

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Thu Apr 10 10:02:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 10:02:41 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <IWrHmtOiI0GWuRkJg6XQC4v130iqFtvCgLKVf04qZ_s=.a13ae17e-0d21-42bf-8a2f-24e1dee22605@github.com>
 <rAGie3DoeWwYuMTNf7auCwVOpXi84_ojazShjS5vCy0=.923ed647-44ce-44c1-a4a4-53dc3243ca7b@github.com>
 <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>
Message-ID: <o4fHWklZFhBcINYTh8ZUhY60ahjoeposyLviLPDdeUE=.2ea87c9a-9099-48c9-9a4f-86ade1735d47@github.com>

On Thu, 10 Apr 2025 08:34:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.
> 
> I think all x86 cleanups related to GC and adjacent code have landed in mainline now. So I expect no more major conflicts with this PR :)

Thanks. :)

@TheRealMDoerr: should be fixed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2792213039

From tschatzl at openjdk.org  Thu Apr 10 11:01:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 11:01:42 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <oUeBCoxLt3yq4WW5ozwkmNQ9gG3serjASbsnQ2873ig=.eb437d04-a608-43e6-b5bd-28744cd872b1@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
 <oUeBCoxLt3yq4WW5ozwkmNQ9gG3serjASbsnQ2873ig=.eb437d04-a608-43e6-b5bd-28744cd872b1@github.com>
Message-ID: <VslR2vKPl11fPIF8sINZXYSVSNFhCylO76pwX3aVlHw=.6999766e-7edc-41a5-aa3e-cab0e03aaa6c@github.com>

On Wed, 9 Apr 2025 12:48:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:
>> 
>>> 99: }
>>> 100: 
>>> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
>> 
>> Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?
>
> I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
> I will try to redo numbers.

>From our microbenchmarks (higher numbers are better):

Current code:

Benchmark                                    (size)   Mode  Cnt       Score      Error   Units
ArrayCopyObject.conjoint_micro                   31  thrpt   15  166136.959 ? 5517.157  ops/ms
ArrayCopyObject.conjoint_micro                   63  thrpt   15  108880.108 ? 4331.112  ops/ms
ArrayCopyObject.conjoint_micro                  127  thrpt   15   93159.977 ? 5025.458  ops/ms
ArrayCopyObject.conjoint_micro                 2047  thrpt   15   17234.842 ?  831.344  ops/ms
ArrayCopyObject.conjoint_micro                 4095  thrpt   15    9202.216 ?  292.612  ops/ms
ArrayCopyObject.conjoint_micro                 8191  thrpt   15    3565.705 ?  121.116  ops/ms
ArrayCopyObject.disjoint_micro                   31  thrpt   15  159106.245 ? 5965.576  ops/ms
ArrayCopyObject.disjoint_micro                   63  thrpt   15   95475.658 ? 5415.267  ops/ms
ArrayCopyObject.disjoint_micro                  127  thrpt   15   84249.979 ? 6313.007  ops/ms
ArrayCopyObject.disjoint_micro                 2047  thrpt   15   10682.650 ?  381.832  ops/ms
ArrayCopyObject.disjoint_micro                 4095  thrpt   15    4471.940 ?  216.439  ops/ms
ArrayCopyObject.disjoint_micro                 8191  thrpt   15    1378.296 ?   33.421  ops/ms
ArrayCopy.arrayCopyObject                       N/A   avgt   15      13.880 ?    0.517   ns/op
ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15      14.844 ?    0.751   ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15      11.080 ?    0.703   ns/op
ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15      11.003 ?    0.135   ns/op

Runtime call:

Benchmark                                    (size)   Mode  Cnt      Score       Error   Units
ArrayCopyObject.conjoint_micro                   31  thrpt   15  73100.230 ? 11079.381  ops/ms
ArrayCopyObject.conjoint_micro                   63  thrpt   15  65039.431 ?  1996.832  ops/ms
ArrayCopyObject.conjoint_micro                  127  thrpt   15  58336.711 ?  2260.660  ops/ms
ArrayCopyObject.conjoint_micro                 2047  thrpt   15  17035.419 ?   524.445  ops/ms
ArrayCopyObject.conjoint_micro                 4095  thrpt   15   9207.661 ?   286.526  ops/ms
ArrayCopyObject.conjoint_micro                 8191  thrpt   15   3264.491 ?    73.848  ops/ms
ArrayCopyObject.disjoint_micro                   31  thrpt   15  84587.219 ?  3007.310  ops/ms
ArrayCopyObject.disjoint_micro                   63  thrpt   15  62815.254 ?  1214.310  ops/ms
ArrayCopyObject.disjoint_micro                  127  thrpt   15  58423.470 ?   285.670  ops/ms
ArrayCopyObject.disjoint_micro                 2047  thrpt   15  10720.462 ?   617.173  ops/ms
ArrayCopyObject.disjoint_micro                 4095  thrpt   15   4178.195 ?   178.942  ops/ms
ArrayCopyObject.disjoint_micro                 8191  thrpt   15   1374.268 ?    44.290  ops/ms
ArrayCopy.arrayCopyObject                       N/A   avgt   15     19.667 ?     0.740   ns/op
ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15     21.243 ?     1.891   ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15     16.645 ?     0.504   ns/op
ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15     17.409 ?     0.705   ns/op

Obviously with larger arrays, the impact diminishes, but it's always there. I think the inlined code is worth the effort in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2037086410

From rcastanedalo at openjdk.org  Thu Apr 10 11:22:36 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 10 Apr 2025 11:22:36 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <VslR2vKPl11fPIF8sINZXYSVSNFhCylO76pwX3aVlHw=.6999766e-7edc-41a5-aa3e-cab0e03aaa6c@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <HApaxUVd5DfT30XejRIMW-r6YCdtePlLvQUW9-Waf5c=.fbb7b1bc-d14f-4d52-a206-0968ea3f6d5d@github.com>
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
 <oUeBCoxLt3yq4WW5ozwkmNQ9gG3serjASbsnQ2873ig=.eb437d04-a608-43e6-b5bd-28744cd872b1@github.com>
 <VslR2vKPl11fPIF8sINZXYSVSNFhCylO76pwX3aVlHw=.6999766e-7edc-41a5-aa3e-cab0e03aaa6c@github.com>
Message-ID: <wOAcqPFvzy1CjVuIf5y-aljD7vjoWacG6z3wmwNYwrk=.bf5d3f27-f93a-4b29-aa4c-acca37dcac3d@github.com>

On Thu, 10 Apr 2025 10:58:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
>> I will try to redo numbers.
>
> From our microbenchmarks (higher numbers are better):
> 
> Current code:
> 
> Benchmark                                    (size)   Mode  Cnt       Score      Error   Units
> ArrayCopyObject.conjoint_micro                   31  thrpt   15  166136.959 ? 5517.157  ops/ms
> ArrayCopyObject.conjoint_micro                   63  thrpt   15  108880.108 ? 4331.112  ops/ms
> ArrayCopyObject.conjoint_micro                  127  thrpt   15   93159.977 ? 5025.458  ops/ms
> ArrayCopyObject.conjoint_micro                 2047  thrpt   15   17234.842 ?  831.344  ops/ms
> ArrayCopyObject.conjoint_micro                 4095  thrpt   15    9202.216 ?  292.612  ops/ms
> ArrayCopyObject.conjoint_micro                 8191  thrpt   15    3565.705 ?  121.116  ops/ms
> ArrayCopyObject.disjoint_micro                   31  thrpt   15  159106.245 ? 5965.576  ops/ms
> ArrayCopyObject.disjoint_micro                   63  thrpt   15   95475.658 ? 5415.267  ops/ms
> ArrayCopyObject.disjoint_micro                  127  thrpt   15   84249.979 ? 6313.007  ops/ms
> ArrayCopyObject.disjoint_micro                 2047  thrpt   15   10682.650 ?  381.832  ops/ms
> ArrayCopyObject.disjoint_micro                 4095  thrpt   15    4471.940 ?  216.439  ops/ms
> ArrayCopyObject.disjoint_micro                 8191  thrpt   15    1378.296 ?   33.421  ops/ms
> ArrayCopy.arrayCopyObject                       N/A   avgt   15      13.880 ?    0.517   ns/op
> ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15      14.844 ?    0.751   ns/op
> ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15      11.080 ?    0.703   ns/op
> ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15      11.003 ?    0.135   ns/op
> 
> Runtime call:
> 
> Benchmark                                    (size)   Mode  Cnt      Score       Error   Units
> ArrayCopyObject.conjoint_micro                   31  thrpt   15  73100.230 ? 11079.381  ops/ms
> ArrayCopyObject.conjoint_micro                   63  thrpt   15  65039.431 ?  1996.832  ops/ms
> ArrayCopyObject.conjoint_micro                  127  thrpt   15  58336.711 ?  2260.660  ops/ms
> ArrayCopyObject.conjoint_micro                 2047  thrpt   15  17035.419 ?   524.445  ops/ms
> ArrayCopyObject.conjoint_micro                 4095  thrpt   15   9207.661 ?   286.526  ops/ms
> ArrayCopyObject.conjoint_micro                 8191  thrpt   15   3264.491 ?    73.848  ops/ms
> ArrayCopyObject.disjoint_micro                   31  thrpt   15  84587.219 ?  3007.310  ops/ms
> ArrayCopyObject.disjoint_micro         ...

Fair enough, thanks for the measurements!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2037121277

From duke at openjdk.org  Thu Apr 10 13:19:05 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 10 Apr 2025 13:19:05 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:

 - Code rearrange, some renaming, fixing comments
 - Changes suggested by Andrew Dinn.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/8d5a9e12..74ff3d9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=05-06

  Stats: 2139 lines in 4 files changed: 630 ins; 826 del; 683 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

PR: https://git.openjdk.org/jdk/pull/23663

From adinn at openjdk.org  Thu Apr 10 14:19:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 14:19:46 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <eGKELcIyE860cEKB4UT_FLVAF6AGPNLgueSJSR7N-b8=.a9a22308-fca0-45ab-9509-e620273d086c@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/register_aarch64.hpp line 510:

> 508: 
> 509: // convenience methods for splitting 8-way of 4-way vector register
> 510: // sequences in half -- needed because vector operations can normally

typo: 8-way of 4-way -> 8-way or 4-way

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5012:

> 5010:     assert(!va.is_constant(), "output vector must identify 2 different registers");
> 5011: 
> 5012:     // schedule 2 streams of i<nstructions across the vector sequences

typo: i<nstructions -> instructions

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5167:

> 5165:     // On each level, we fill up the vector registers in such a way that the
> 5166:     // array elements that need to be multiplied by the zetas be in one
> 5167:     // set of vector registers while the corresponding ones that don't need to

grammar: by the zetas be in one ... -> by the zetas are in one ...

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5168:

> 5166:     // array elements that need to be multiplied by the zetas be in one
> 5167:     // set of vector registers while the corresponding ones that don't need to
> 5168:     // be multiplied, in another set. We can do 32 Montgomery multiplications

grammar: be multiplied, in another set. --> be multiplied are in another set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037529145
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037526649
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037535909
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037537834

From adinn at openjdk.org  Thu Apr 10 14:30:39 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 14:30:39 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <FBO9li_-rmDsNAeH-S5vCNVt2n2XZTxPW2JVW_YoyVU=.77d1182c-1899-47e2-ac7a-cdc9f55b00e2@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5278:

> 5276:     // level 4
> 5277:     vs_ldpq(vq, kyberConsts);
> 5278:     int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 };

I'd like to add comment here to explain the coefficient grouping
and likewise at level 5 and 6. So here we have:
// Up to level 3 the coefficients multiplied by or added/subtracted
// to the zetas occur in discrete blocks whose size is some multiple
// of 32. At level 4 coefficients occur in 8 discrete blocks of size 16
// so they are loaded using employing an ldr at 8 distinct offsets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037560706

From adinn at openjdk.org  Thu Apr 10 14:42:35 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 14:42:35 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <1-Ncd4d8AXSun31DFTq_Q-GI0zbOW76QB0LXX2iyF38=.46a32e70-f613-43f0-a485-c5113200ed40@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5300:

> 5298:     // level 5
> 5299:     vs_ldpq(vq, kyberConsts);
> 5300:     int offsets4[4] = { 0, 32, 64, 96 };

Again a comment
// At level 5 related coefficients occur in discrete blocks of size 8 so
// need to be loaded interleaved using an ld2 operation with arrangement 2D

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5319:

> 5317:     vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4);
> 5318: 
> 5319:     // level 6

And again
// At level 6 related coefficients occur in discrete blocks of size 4 so
// need to be loaded interleaved using an ld2 operation with arrangement 4S

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5377:

> 5375:     // level 0
> 5376:     vs_ldpq(vq, kyberConsts);
> 5377:     int offsets4[4] = { 0, 32, 64, 96 };

Again a comment
// At level 0 related coefficients occur in discrete blocks of size 4 so
// need to be loaded interleaved using an ld2 operation with arrangement 4S

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5399:

> 5397:     vs_st2_indexed(vs1, __ T4S, coeffs, tmpAddr, 384, offsets4);
> 5398: 
> 5399:     // level 1

Again a comment
// At level 1 related coefficients occur in discrete blocks of size 8 so
// need to be loaded interleaved using an ld2 operation with arrangement 2D

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5423:

> 5421: 
> 5422:     // level 2
> 5423:     int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 };

Again
// At level 2 coefficients occur in 8 discrete blocks of size 16
// so they are loaded using employing an ldr at 8 distinct offsets.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5464:

> 5462:     vs_str_indexed(vs1, __ Q, coeffs, 256, offsets3);
> 5463: 
> 5464:     // level 3

/ From level 3 upwards coefficients occur in discrete blocks whose size is
// some multiple of 32 so can be loaded using ldpq and suitable indexes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037571231
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037573218
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037577265
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037578385
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037581149
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037585101

From adinn at openjdk.org  Thu Apr 10 14:52:33 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 14:52:33 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <Z0gTAqJvl0QhulAXaFwZBxvudMONQLhj_bekBxhhRik=.618b80b1-3bd0-4b67-afb8-158b4cbdb4e2@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5590:

> 5588:     __ add(tmpAddr, coeffs, 0);
> 5589:     store64shorts(vs2, tmpAddr);
> 5590: 

I'd like to make explicit the fact that we have avoided doing an add here (and in the next two cases) by adding a commented out generation step i.e. at this line insert

    // __ add(tmpAddr, coeffs, 128); // unneeded as implied by preceding load

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5595:

> 5593:     __ add(tmpAddr, coeffs, 128);
> 5594:     store64shorts(vs2, tmpAddr);
> 5595: 

Likewise insert:

    // __ add(tmpAddr, coeffs, 256); // unneeded as implied by preceding load

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5601:

> 5599:     store64shorts(vs2, tmpAddr);
> 5600: 
> 5601:     load64shorts(vs1, tmpAddr);

Likewise insert:

    // __ add(tmpAddr, coeffs, 384); // unneeded as implied by preceding load

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037607688
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037609104
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037611049

From adinn at openjdk.org  Thu Apr 10 16:17:38 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 16:17:38 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <8wo-YxVVmMSocSfA7Te4-txUqtv6JQyxktwIGZ_U3z4=.fadb528c-6d39-4733-be37-7c85387cf3da@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5933:

> 5931:     vs_ld3_post(vin, __ T16B, condensed);
> 5932: 
> 5933:     // expand groups of input bytes in vin to shorts in va and vb

I's like to expand on the data layouts here so that maintenance engineers don't have to work it out every time they look at it. So, I would like to replace this comment as follows

    // The front half of sequence vin (vin[0], vin[1] and vin[2])
    // holds 48 (16x3) contiguous bytes from memory striped
    // horizontally across each of the 16 byte lanes. Equivalently,
    // that is 16 pairs of 12-bit integers. Likewise the back half
    // holds the next 48 bytes in the same arrangement.

    // Each vector in the front half can also be viewed as a vertical
    // strip across the 16 pairs of 12 bit integers. Each byte in
    // vin[0] stores the low 8 bits of the first int in a pair. Each
    // byte in vin[1] stores the high 4 bits of the first int and the
    // low 4 bits of the second int. Each byte in vin[2] stores the
    // high 8 bits of the second int. Likewise the vectors in second
    // half.

    // Converting the data to 16-bit shorts requires first of all
    // expanding each of the 6 x 16B vectors into 6 corresponding
    // pairs of 8H vectors. Mask, shift and add operations on the
    // resulting vector pairs can be used to combine 4 and 8 bit
    // parts of related 8H vector elements.
    //
    // The middle vectors (vin[2] and vin[5]) are actually expanded
    // twice, one copy manipulated to provide the lower 4 bits
    // belonging to the first short in a pair and another copy
    // manipulated to provide the higher 4 bits belonging to the
    // second short in a pair. This is why the the vector sequences va
    // and vb used to hold the expanded 8H elements are of length 8.

    // Expand vin[0] into va[0:1], and vin[1] into va[2:3] and va[4:5]

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5941:

> 5939:     __ ushll(va[4], __ T8H, vin[1], __ T8B, 0);
> 5940:     __ ushll2(va[5], __ T8H, vin[1], __ T16B, 0);
> 5941: 

Insert here

    // Likewise expand vin[3] into vb[0:1], and vin[4] into vb[2:3]
    // and vb[4:5]

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5949:

> 5947:     __ ushll2(vb[5], __ T8H, vin[4], __ T16B, 0);
> 5948: 
> 5949:     // offset duplicated elements in va and vb by 8

To make this clearer it should say

    // shift lo byte of copy 1 of the middle stripe into the high byte

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5955:

> 5953:     __ shl(vb[3], __ T8H, vb[3], 8);
> 5954: 
> 5955:     // expand remaining input bytes in vin to shorts in va and vb

To make this clearer it should say

    // Expand vin[2] into va[6:7] and vin[5] into vb[6:7] but this
    // time pre-shifted by 4 to ensure top bits of input 12-bit int
    // are in bit positions [4..11].

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5962:

> 5960:     __ ushll2(vb[7], __ T8H, vin[5], __ T16B, 4);
> 5961: 
> 5962:     // split the duplicated 8 bit values into two distinct 4 bit

To make this clearer it should say

    // mask hi 4 bits of the 1st 12-bit int in a pair from copy1 and
    // shift lo 4 bits of the 2nd 12-bit int in a pair to the bottom of
    // copy2

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5973:

> 5971:     __ ushr(vb[5], __ T8H, vb[5], 4);
> 5972: 
> 5973:     // sum resulting short values into the front halves of va and

This should be replaced to clarify details of the ordering for summing and grouping

    // sum hi 4 bits and lo 8 bits of the 1st 12-bit int in each pair and
    // hi 8 bits plus lo 4 bits of the 2nd 12-bit int in each pair

    // n.b. the ordering ensures: i) inputs are consumed before they
    // are overwritten ii) the order of 16-bit results across successive
    // pairs of vectors in va and then vb reflects the order of the
    // corresponding 12-bit inputs

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5984:

> 5982:     __ addv(vb[3], __ T8H, vb[5], vb[7]);
> 5983: 
> 5984:     // store results interleaved as shorts

Change to

    // store 64 results interleaved as shorts

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5993:

> 5991:     __ cbz(parsedLength, L_end);
> 5992: 
> 5993:     // if anything is left it should be a final 72 bytes. so we

Clarify as follows

    // if anything is left it should be a final 72 bytes of input
    // i.e. a final 48 12-bit values. so we handle this by loading
    // load 48 bytes into all 16B lanes of front(vin) and only 24
    // bytes into the lower 8B lane of back(vin)

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5999:

> 5997:     vs_ld3(vs_back(vin), __ T8B, condensed);
> 5998: 
> 5999:     // expand groups of input bytes in vin to shorts in va and vb

Modify as above

    // Expand vin[0] into va[0:1], and vin[1] into va[2:3] and va[4:5]

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6009:

> 6007:     __ ushll2(va[5], __ T8H, vin[1], __ T16B, 0);
> 6008: 
> 6009:     __ ushll(vb[0], __ T8H, vin[3], __ T8B, 0);

Add a comment

    // This time expand just the lower 8 lanes

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6013:

> 6011:     __ ushll(vb[4], __ T8H, vin[4], __ T8B, 0);
> 6012: 
> 6013:     // offset duplicated elements in va and vb by 8

As before clarify as follows

    // shift lo byte of copy 1 of the middle stripe into the high byte

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6018:

> 6016:     __ shl(vb[2], __ T8H, vb[2], 8);
> 6017: 
> 6018:     // expand remaining input bytes in vin to shorts in va and vb

Again improve this comment

    // expand vin[2] into va[6:7] and lower 8 lanes of vin[5] into
    // vb[6] pre-shifted by 4 to ensure top bits of the input 12-bit
    // int are in bit positions [4..11].

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6024:

> 6022:     __ ushll(vb[6], __ T8H, vin[5], __ T8B, 4);
> 6023: 
> 6024:     // split the duplicated 8 bit values into two distinct 4 bit

Once again update

    // mask hi 4 bits of each 1st 12-bit int in pair from copy1 and
    // shift lo 4 bits of each 2nd 12-bit int in pair to bottom of
    // copy2

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6033:

> 6031:     __ ushr(vb[4], __ T8H, vb[4], 4);
> 6032: 
> 6033:     // sum resulting short values into the front halves of va and

Again update to provide more detail

    // sum hi 4 bits and lo 8 bits of each 1st 12-bit int in pair and
    // hi 8 bits plus lo 4 bits of each 2nd 12-bit int in pair

    // n.b. ordering ensures: i) inputs are consumed before they are
    // overwritten ii) order of 16-bit results across succsessive
    // pairs of vectors in va and then lower half of vb reflects order
    // of corresponding 12-bit inputs

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6042:

> 6040:     __ addv(vb[1], __ T8H, vb[4], vb[6]);
> 6041: 
> 6042:     // store results interleaved as shorts

Change to

    // store 48 results interleaved as shorts

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037755555
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037758589
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037760493
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037762375
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037764723
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037767700
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037783970
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037771521
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037769694
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037774404
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037776668
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037779831
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037780704
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037781617
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037782757

From adinn at openjdk.org  Thu Apr 10 16:53:32 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Apr 2025 16:53:32 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

@ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate.

I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time).

Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now.

Thanks again for your help in improving this code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2794514677

From rcastanedalo at openjdk.org  Fri Apr 11 13:01:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 13:01:49 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: <c4SP3CvUAdaDBqP008E699Jdg3Q8FRqKTauOO4uUwog=.d20ead95-a8f0-49d6-8930-39c170ce20db@github.com>

On Thu, 10 Apr 2025 10:02:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

Thank you for addressing my comments, Thomas!
The new x64 version of `G1BarrierSetAssembler::gen_write_ref_array_post_barrier` looks correct, but I think it could be significantly simplified, here is my suggestion which is more similar to the aarch64 version: https://github.com/robcasloz/jdk/commit/fbedc0ae1ec5fcfa95b00ad354986885c7a56ce0 (note: did not test it thoroughly).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2796850628

From rcastanedalo at openjdk.org  Fri Apr 11 13:10:33 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 13:10:33 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: <O9b2MIuaCnoJjbczYqHauPcDHDK9K4ve6bcQf13i0mQ=.f9b54038-f5e8-4767-98fb-a91525f4f413@github.com>

On Thu, 10 Apr 2025 10:02:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

> G1 sets UseCondCardMark to true by default. The conditional card mark corresponds to the third filter in the write barrier now, and since I decided to keep all filters for this change, it makes sense to directly use this mechanism.

Do you have performance results for `-UseCondCardMark` vs. `+UseCondCardMark`? The benefit of `+UseCondCardMark` is not obvious from looking at the generated barrier code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2796872496

From rcastanedalo at openjdk.org  Fri Apr 11 14:30:32 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 14:30:32 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: <URYGEP06j5-Hq6rR29IgMRaZ8gLV6eoMAPzafQzES5E=.ba3c67ab-2e61-45c2-9bce-0eb75c5418c8@github.com>

On Thu, 10 Apr 2025 10:02:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

The compiler-related parts of this change (including x64 and aarch64 changes) look good! These are the files I reviewed:
- `src/hotspot/share/gc/g1/g1BarrierSet*`
- `src/hotspot/share/gc/g1/{c1,c2}`
- `src/hotspot/cpu/{x86,aarch64}`
- `test/hotspot/jtreg/compiler`
- `test/hotspot/jtreg/testlibrary_tests`

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-2760546283

From kbarrett at openjdk.org  Sat Apr 12 13:53:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 12 Apr 2025 13:53:24 GMT
Subject: RFR: 8347719: [REDO] Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
Message-ID: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>

Please review this second attempt.  It's mostly similar to the original
attempt:
https://bugs.openjdk.org/browse/JDK-8313396
https://github.com/openjdk/jdk/pull/22890
but improves the workarounds for one clang issue, and adds a workaround for
another clang issue
https://bugs.openjdk.org/browse/JDK-8347649

See globalDefinitions_gcc.hpp for more details about those issues and the
workarounds.

Additions to the testing done for the earlier attempt (see below)

mach5 tier4-5. There is an Oracle-internal build configuration in tier5 that
failed with the earlier attempt.

Local manual build and tier1 test on linux with clang.  
For testing on linux with clang, be aware of these issues:
https://bugs.openjdk.org/browse/JDK-8354316
https://bugs.openjdk.org/browse/JDK-8354467

Below is a repeat of the PR summary for the earlier attempt.  

----------

Please review this change to how HotSpot prevents the use of certain C library
functions (e.g. poisons references to those functions), while permitting a
subset to be used in restricted circumstances. Reasons for poisoning a
function include it being considered obsolete, or a security concern, or there
is a HotSpot function (typically in the os:: namespace) providing similar
functionality that should be used instead.

The old mechanism, based on -Wattribute-warning and the associated attribute,
only worked for gcc. (Clang's implementation differs in an important way from
gcc, which is the subject of a clang bug that has been open for years. MSVC
doesn't provide a similar mechanism.) It also had problems with LTO, due to a
gcc bug.

The new mechanism is based on deprecation warnings, using [[deprecated]]
attributes. We redeclare or forward declare the functions we want to prevent
use of as being deprecated. This relies on deprecation warnings being
enabled, which they already are in our build configuration. All of our
supported compilers support the [[deprecated]] attribute.

Another benefit of using deprecation warnings rather than warning attributes
is the time when the check is performed. Warning attributes are checked only
if the function is referenced after all optimizations have been performed.
Deprecation is checked during initial semantic analysis. That's better for
our purposes here. (This is also part of why gcc LTO has problems with the
old mechanism, but not the new.)

Adding these redeclarations or forward declarations isn't as simple as
expected, due to differences between the various compilers. We hide the
differences behind a set of macros, FORBID_C_FUNCTION and related macros. See
the compiler-specific parts of those macros for details.

In some situations we need to allow references to these poisoned functions.

One common case is where our poisoning is visible to some 3rd party code we
don't want to modify. This is typically 3rd party headers included in HotSpot
code, such as from Google Test or the C++ Standard Library. For these the
BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
where such references are permitted.

Some of the poisoned functions are needed to implement associated HotSpot os::
functions, or in other similarly restricted contexts. For these, a wrapper
function is provided that calls the poisoned function with the warning
suppressed. These wrappers are defined in the permit_forbidden_functions
[note: for REDO this is changed to permit_forbidden_function, per prior review]
namespace, and called using the qualified name. This makes the use of these
functions stand out, suggesting they need careful scrutiny in code reviews and
the like. There are several benefits to this approach vs the old
ALLOW_C_FUNCTION macro. We can centralize the set of such functions. The
syntax for use is simpler (there were syntactic bugs with the old mechanism
that weren't always noticed for a while). The permitted reference is explicit;
there can't be an ALLOW_C_FUNCTION use that isn't actually needed.

Testing:
mach5 tier1-3, which includes various build variants such as slowdebug.
GHA sanity tests
Manual testing for warnings for direct calls to poisoned functions with all 3
compilers, and that the error messages look sane and helpful.

gcc:


<file/containing/reference>: In function 'void test_exit(int)':
<file/containing/reference>:<line>:<column>: error: 'void exit(int)' is deprecated: use os::exit [-Werror=deprecated-declarations]
   32 | void test_exit(int status) { return exit(status); }
      |                                     ~~~~^~~~~~~~


... and more stuff about the declaration ...

clang:


<file/containing/reference>:<line>:<column>: error: 'exit' is deprecated: use os::exit [-Werror,-Wdeprecated-declarations]
void test_exit(int status) { return exit(status); }
                                    ^


... and more stuff about the declaration ...

Visual Studio:


<file/containing/reference>(<line>): warning C4996: 'exit': use os::exit

-------------

Commit messages:
 - improve/add clang-specific workarounds
 - apply original change

Changes: https://git.openjdk.org/jdk/pull/24608/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24608&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347719
  Stats: 627 lines in 32 files changed: 464 ins; 64 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/24608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24608/head:pull/24608

PR: https://git.openjdk.org/jdk/pull/24608

From dnsimon at openjdk.org  Mon Apr 14 12:56:20 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 14 Apr 2025 12:56:20 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
In-Reply-To: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
Message-ID: <mIqVMABSi-QtUrn7JnBW4u424FbOzdMQk8S5kq4McIE=.514cc309-552f-4fff-8698-b7a7c4912b54@github.com>

On Mon, 24 Mar 2025 14:31:54 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.

LGTM and trival.

Actually, can you please add some extra tests to `TestConstantReflectionProvider.java` for out-of-bounds reads.

-------------

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24200#pullrequestreview-2764015041
Changes requested by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24200#pullrequestreview-2764143284

From duke at openjdk.org  Mon Apr 14 12:56:15 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 14 Apr 2025 12:56:15 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
Message-ID: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>

This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.

-------------

Commit messages:
 - Verify bounds for primitive array reads.

Changes: https://git.openjdk.org/jdk/pull/24200/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24200&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352724
  Stats: 13 lines in 1 file changed: 10 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24200.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24200/head:pull/24200

PR: https://git.openjdk.org/jdk/pull/24200

From duke at openjdk.org  Mon Apr 14 12:57:18 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 14 Apr 2025 12:57:18 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v8]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <Kfusi92qVqLhR_LHe9Fzm8sv9KgnktSzW1U3yi7dzJo=.9693a28f-6570-4109-b683-87513187adc9@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Clarified comments as suggested by Andrew Dinn

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/74ff3d9f..d7f7fc8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=06-07

  Stats: 134 lines in 3 files changed: 96 ins; 4 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

PR: https://git.openjdk.org/jdk/pull/23663

From adinn at openjdk.org  Mon Apr 14 13:00:45 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 14 Apr 2025 13:00:45 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <U_uXuMXp73Dbio7OwKLD18HR3AvL0xsnCw-JAdJSNJU=.01568193-4173-4305-8f58-d5ae3f68e6da@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/register_aarch64.hpp line 509:

> 507: }
> 508: 
> 509: // convenience methods for splitting 8-way of 4-way vector register

Suggestion:

// convenience methods for splitting 8-way or 4-way vector register

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5012:

> 5010:     assert(!va.is_constant(), "output vector must identify 2 different registers");
> 5011: 
> 5012:     // schedule 2 streams of i<nstructions across the vector sequences

Suggestion:

    // schedule 2 streams of instructions across the vector sequences

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5166:

> 5164:     //
> 5165:     // On each level, we fill up the vector registers in such a way that the
> 5166:     // array elements that need to be multiplied by the zetas be in one

Suggestion:

    // array elements that need to be multiplied by the zetas are in one

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5168:

> 5166:     // array elements that need to be multiplied by the zetas be in one
> 5167:     // set of vector registers while the corresponding ones that don't need to
> 5168:     // be multiplied, in another set. We can do 32 Montgomery multiplications

Suggestion:

    // be multiplied are in another set. We can do 32 Montgomery multiplications

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5278:

> 5276:     // level 4
> 5277:     vs_ldpq(vq, kyberConsts);
> 5278:     int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 };

I'd like to add comment here to explain the coefficient grouping
and likewise at level 5 and 6. So here we have:
Suggestion:

    // Up to level 3 the coefficients multiplied by or added/subtracted
    // to the zetas occur in discrete blocks whose size is some multiple
    // of 32. At level 4 coefficients occur in 8 discrete blocks of size 16
    // so they are loaded using an ldr at 8 distinct offsets.
    int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 };

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5299:

> 5297: 
> 5298:     // level 5
> 5299:     vs_ldpq(vq, kyberConsts);

Suggestion:

    vs_ldpq(vq, kyberConsts);
    // At level 5 related coefficients occur in discrete blocks of size 8 so
    // need to be loaded interleaved using an ld2 operation with arrangement 2D

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5319:

> 5317:     vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4);
> 5318: 
> 5319:     // level 6

Suggestion:

    // level 6
    // At level 6 related coefficients occur in discrete blocks of size 4 so
    // need to be loaded interleaved using an ld2 operation with arrangement 4S

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5377:

> 5375:     // level 0
> 5376:     vs_ldpq(vq, kyberConsts);
> 5377:     int offsets4[4] = { 0, 32, 64, 96 };

Again a comment
Suggestion:

     // At level 6 related coefficients occur in discrete blocks of size 4 so
     // need to be loaded interleaved using an ld2 operation with arrangement 4S
     int offsets4[4] = { 0, 32, 64, 96 };

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5399:

> 5397:     vs_st2_indexed(vs1, __ T4S, coeffs, tmpAddr, 384, offsets4);
> 5398: 
> 5399:     // level 1

Again a comment
Suggestion:

    // level 1
    // At level 1 related coefficients occur in discrete blocks of size 8 so
    // need to be loaded interleaved using an ld2 operation with arrangement 2D

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5422:

> 5420:     vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4);
> 5421: 
> 5422:     // level 2

Again
Suggestion:

    // level 2
    // At level 2 coefficients occur in 8 discrete blocks of size 16
    // so they are loaded using employing an ldr at 8 distinct offsets.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5464:

> 5462:     vs_str_indexed(vs1, __ Q, coeffs, 256, offsets3);
> 5463: 
> 5464:     // level 3

Suggestion:

    // level 3
    // From level 3 upwards coefficients occur in discrete blocks whose size is
    // some multiple of 32 so can be loaded using ldpq and suitable indexes.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5591:

> 5589:     store64shorts(vs2, tmpAddr);
> 5590: 
> 5591:     load64shorts(vs1, tmpAddr);

I'd like to make explicit the fact that we have avoided doing an add here (and in the next two cases) by adding a commented out generation step i.e. at this line insert
Suggestion:

    // __ add(tmpAddr, coeffs, 128); // unneeded as implied by preceding store
    load64shorts(vs1, tmpAddr);

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5596:

> 5594:     store64shorts(vs2, tmpAddr);
> 5595: 
> 5596:     load64shorts(vs1, tmpAddr);

Likewise insert:
Suggestion:

    // __ add(tmpAddr, coeffs, 256); // unneeded as implied by preceding store
    load64shorts(vs1, tmpAddr);

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5601:

> 5599:     store64shorts(vs2, tmpAddr);
> 5600: 
> 5601:     load64shorts(vs1, tmpAddr);

Likewise insert:
Suggestion:

    // __ add(tmpAddr, coeffs, 384); // unneeded as implied by preceding store
    load64shorts(vs1, tmpAddr);

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5640:

> 5638:     VSeq<4> vs1(0), vs2(4);  // 4 sets of 8x8H inputs/outputs/tmps
> 5639:     VSeq<4> vs3(16), vs4(20);
> 5640:     VSeq<2> vq(30);          // pair of constants for montmul

Suggestion:

    VSeq<2> vq(30);          // pair of constants for montmul: qinv, q

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5642:

> 5640:     VSeq<2> vq(30);          // pair of constants for montmul
> 5641:     VSeq<2> vz(28);          // pair of zetas
> 5642:     VSeq<4> vc(27, 0);       // constant sequence for montmul

Suggestion:

    VSeq<4> vc(27, 0);       // constant for montmul: montRSquareModQ

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6094:

> 6092:     VSeq<8> vc2_1(31, 0);
> 6093:     VSeq<2> vc2_2(31, 0);
> 6094:     FloatRegister vc2_3 = v31;

Suggestion:

    // we also need a pair of corresponding constant sequences
    VSeq<8> vc1_1(30, 0);       // kyber_q
    VSeq<2> vc1_2(30, 0);
    FloatRegister vc1_3 = v30;

    VSeq<8> vc2_1(31, 0);       // kyberBarrettMultiplier
    VSeq<2> vc2_2(31, 0);
    FloatRegister vc2_3 = v31;

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6102:

> 6100:     // load q and the multiplier for the Barrett reduction
> 6101:     __ add(kyberConsts, kyberConsts, 16);
> 6102:     __ ldpq(vc1_3, vc2_3, kyberConsts);

Suggestion:

    __ ldpq(vc1_3, vc2_3, kyberConsts); // kyber_q, kyberBarrettMultiplier

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6111:

> 6109:         __ ldr(vs1_3, __ Q, __ post(coeffs, 16));
> 6110:       }
> 6111:       vs_sqdmulh(vs2_1, __ T8H, vs1_1, vc2_1);

Suggestion:

      vs_sqdmulh(vs2_1, __ T8H, vs1_1, vc2_1); // vs2 <- (2 * vs1 * kyberBarrettMultiplier) >> 16

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6116:

> 6114:         __ sqdmulh(vs2_3, __ T8H, vs1_3, vc2_3);
> 6115:       }
> 6116:       vs_sshr(vs2_1, __ T8H, vs2_1, 11);

Suggestion:

      vs_sshr(vs2_1, __ T8H, vs2_1, 11); // vs2 <- (vs1 * kyberBarrettMultiplier) >> 26

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6121:

> 6119:         __ sshr(vs2_3, __ T8H, vs2_3, 11);
> 6120:       }
> 6121:       vs_mlsv(vs1_1, __ T8H, vs2_1, vc1_1);

Suggestion:

      vs_mlsv(vs1_1, __ T8H, vs2_1, vc1_1); // vs1 <- vs1 - vs2 * kyber_q

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041886663
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041888092
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041889242
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041889966
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041892243
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041892994
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041893924
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041895469
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041896626
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041898215
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041899623
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041902206
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041902833
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041906126
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041909711
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041929011
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041867539
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041868670
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041881429
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041883012
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041883686

From duke at openjdk.org  Mon Apr 14 12:57:35 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 14 Apr 2025 12:57:35 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
Message-ID: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>

On Thu, 10 Apr 2025 16:50:29 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Code rearrange, some renaming, fixing comments
>>  - Changes suggested by Andrew Dinn.
>
> @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate.
> 
> I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time).
> 
> Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now.
> 
> Thanks again for your help in improving this code.

@adinn Hi, Andrew,
 I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2801545565

From adinn at openjdk.org  Mon Apr 14 13:14:19 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 14 Apr 2025 13:14:19 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <E0WVekeVAsmYcrHmyZGS3rw7KO4tTzzA2QA0vRMQ-S0=.f46751a6-3641-4fa8-8a11-47e86f82c42e@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5661:

> 5659:     // load 16 zetas
> 5660:     vs_ldpq_post(vz, zetas);
> 5661:     // load 2 sets of 32 coefficients from the two input arrays

Suggestion:

    // load 2 sets of 32 coefficients from the two input arrays
    // interleaved as shorts. i.e. pairs of shorts adjacent in memory
    // are striped across pairs of vector registers

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2042093533

From jwaters at openjdk.org  Mon Apr 14 13:36:51 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Apr 2025 13:36:51 GMT
Subject: RFR: 8347719: [REDO] Portable implementation of FORBID_C_FUNCTION
 and ALLOW_C_FUNCTION
In-Reply-To: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
References: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
Message-ID: <6ve5WSJL805ZoMYCp-3jc6jvPlQ2H04o37Z1-LRpMQU=.def6aa0b-1e53-4887-9dd1-9ccec5977834@github.com>

On Sat, 12 Apr 2025 13:48:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this second attempt.  It's mostly similar to the original
> attempt:
> https://bugs.openjdk.org/browse/JDK-8313396
> https://github.com/openjdk/jdk/pull/22890
> but improves the workarounds for one clang issue, and adds a workaround for
> another clang issue
> https://bugs.openjdk.org/browse/JDK-8347649
> 
> See globalDefinitions_gcc.hpp for more details about those issues and the
> workarounds.
> 
> Additions to the testing done for the earlier attempt (see below)
> 
> mach5 tier4-5. There is an Oracle-internal build configuration in tier5 that
> failed with the earlier attempt.
> 
> Local manual build and tier1 test on linux with clang.  
> For testing on linux with clang, be aware of these issues:
> https://bugs.openjdk.org/browse/JDK-8354316
> https://bugs.openjdk.org/browse/JDK-8354467
> 
> Below is a repeat of the PR summary for the earlier attempt.  
> 
> ----------
> 
> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances. Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc. (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years. MSVC
> doesn't provide a similar mechanism.) It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated. This relies on deprecation warnings being
> enabled, which they already are in our build configuration. All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed. Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis. That's better for
> our purposes here. (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers. We hide t...

Just a thought, what if we used decltype instead?


[[deprecated("use os::malloc")]] decltype(::malloc) malloc;
[[deprecated("use os::exit")]] decltype(::exit) exit;


In theory this should bypass the need for that complex noreturn and dllexport workarounds needed here for clang and VC, since decltype probably absorbs all those attributes and redeclares them in the second declaration. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24608#issuecomment-2801731613

From duke at openjdk.org  Mon Apr 14 14:32:52 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 14 Apr 2025 14:32:52 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v2]
In-Reply-To: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
Message-ID: <b8RfKKITfqf4C0T2WOhryaOpetn884M3AO5GAzVYX7o=.c72a77be-54f4-475c-8655-273bbc1d5c4e@github.com>

> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.

Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:

  Test reads after last array element in JVMCI.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24200/files
  - new: https://git.openjdk.org/jdk/pull/24200/files/1bfeb512..7475f468

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24200&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24200&range=00-01

  Stats: 28 lines in 1 file changed: 22 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24200.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24200/head:pull/24200

PR: https://git.openjdk.org/jdk/pull/24200

From dnsimon at openjdk.org  Mon Apr 14 14:43:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 14 Apr 2025 14:43:04 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v2]
In-Reply-To: <b8RfKKITfqf4C0T2WOhryaOpetn884M3AO5GAzVYX7o=.c72a77be-54f4-475c-8655-273bbc1d5c4e@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
 <b8RfKKITfqf4C0T2WOhryaOpetn884M3AO5GAzVYX7o=.c72a77be-54f4-475c-8655-273bbc1d5c4e@github.com>
Message-ID: <lwleT-G9ZUrhAFxOvuy8b7w4IWc0gyqbwsVUJOA6c2k=.269430b7-b182-47d6-835e-aaf8e8dc1b5b@github.com>

On Mon, 14 Apr 2025 14:32:52 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

>> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.
>
> Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test reads after last array element in JVMCI.

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java line 148:

> 146:             if (cv.boxed != null && cv.boxed.getClass().isArray()) {
> 147:                 JavaKind kind = metaAccess.lookupJavaType(cv.value).getComponentType().getJavaKind();
> 148:                 long offset = metaAccess.getArrayBaseOffset(kind) + (long) metaAccess.getArrayIndexScale(kind) * Array.getLength(cv.boxed);

If I understand correctly, this tests a read of an element one past the end of the array.
Can you please also add a test for a read that is partially out-of-bounds:

long offset = 1 + metaAccess.getArrayBaseOffset(kind) + (long) metaAccess.getArrayIndexScale(kind) * (Array.getLength(cv.boxed) - 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24200#discussion_r2042298538

From duke at openjdk.org  Mon Apr 14 15:34:21 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 14 Apr 2025 15:34:21 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v9]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <FLCpaUGz_nRBFUrGLubAQqwpJ21dTMXHms2KU4OwP2I=.2c0d8d18-cedf-4030-92b8-21223754af2d@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Uncommented an accidentakky commented line in ML_KEM.java + changed 1 more comment as suggested by Andrew Dinn.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/d7f7fc8e..5901547f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=07-08

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

PR: https://git.openjdk.org/jdk/pull/23663

From duke at openjdk.org  Mon Apr 14 16:33:07 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 14 Apr 2025 16:33:07 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v3]
In-Reply-To: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
Message-ID: <nQIK5OsHkGebtF9SOfmRjaZ4hgEAuy6bAco6vXJuK4o=.7f089585-1056-48f3-a446-6e6773649a77@github.com>

> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.

Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:

  Test array reads that are partially out of bounds.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24200/files
  - new: https://git.openjdk.org/jdk/pull/24200/files/7475f468..3661b212

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24200&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24200&range=01-02

  Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24200.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24200/head:pull/24200

PR: https://git.openjdk.org/jdk/pull/24200

From duke at openjdk.org  Mon Apr 14 16:37:43 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 14 Apr 2025 16:37:43 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v2]
In-Reply-To: <lwleT-G9ZUrhAFxOvuy8b7w4IWc0gyqbwsVUJOA6c2k=.269430b7-b182-47d6-835e-aaf8e8dc1b5b@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
 <b8RfKKITfqf4C0T2WOhryaOpetn884M3AO5GAzVYX7o=.c72a77be-54f4-475c-8655-273bbc1d5c4e@github.com>
 <lwleT-G9ZUrhAFxOvuy8b7w4IWc0gyqbwsVUJOA6c2k=.269430b7-b182-47d6-835e-aaf8e8dc1b5b@github.com>
Message-ID: <4p7s9KQLUxBWfHroigJ58xbtbGVwyMEVUOX0lEjvgGk=.24971263-8748-4d6e-ac6f-805dd1612be1@github.com>

On Mon, 14 Apr 2025 14:39:35 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test reads after last array element in JVMCI.
>
> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java line 148:
> 
>> 146:             if (cv.boxed != null && cv.boxed.getClass().isArray()) {
>> 147:                 JavaKind kind = metaAccess.lookupJavaType(cv.value).getComponentType().getJavaKind();
>> 148:                 long offset = metaAccess.getArrayBaseOffset(kind) + (long) metaAccess.getArrayIndexScale(kind) * Array.getLength(cv.boxed);
> 
> If I understand correctly, this tests a read of an element one past the end of the array.
> Can you please also add a test for a read that is partially out-of-bounds:
> 
> long offset = 1 + metaAccess.getArrayBaseOffset(kind) + (long) metaAccess.getArrayIndexScale(kind) * (Array.getLength(cv.boxed) - 1);

I added a test for a `long` read from `array[array.index - 1]` because adding `+ 1` would make the read unaligned (which is also not allowed).  Please check it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24200#discussion_r2042506762

From dnsimon at openjdk.org  Mon Apr 14 16:41:44 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 14 Apr 2025 16:41:44 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v3]
In-Reply-To: <nQIK5OsHkGebtF9SOfmRjaZ4hgEAuy6bAco6vXJuK4o=.7f089585-1056-48f3-a446-6e6773649a77@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
 <nQIK5OsHkGebtF9SOfmRjaZ4hgEAuy6bAco6vXJuK4o=.7f089585-1056-48f3-a446-6e6773649a77@github.com>
Message-ID: <6dfjF8s-i_CdERHJjGXUHGaMhI_LKgxFxULtPzc3Ufc=.30e51f39-1d5e-4499-968c-aca28094d220@github.com>

On Mon, 14 Apr 2025 16:33:07 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

>> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.
>
> Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test array reads that are partially out of bounds.

Thanks for the new tests.

-------------

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24200#pullrequestreview-2764946450

From duke at openjdk.org  Mon Apr 14 16:47:43 2025
From: duke at openjdk.org (duke)
Date: Mon, 14 Apr 2025 16:47:43 GMT
Subject: RFR: 8352724: Verify bounds for primitive array reads in JVMCI
 [v3]
In-Reply-To: <nQIK5OsHkGebtF9SOfmRjaZ4hgEAuy6bAco6vXJuK4o=.7f089585-1056-48f3-a446-6e6773649a77@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
 <nQIK5OsHkGebtF9SOfmRjaZ4hgEAuy6bAco6vXJuK4o=.7f089585-1056-48f3-a446-6e6773649a77@github.com>
Message-ID: <03LwU0TS57dra3K3ZINSSqMY5Sx0biflR9g18IIKFDk=.c528c0f8-0d26-4e43-94d2-ebab19d18eef@github.com>

On Mon, 14 Apr 2025 16:33:07 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

>> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.
>
> Andrej Pe?im?th has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test array reads that are partially out of bounds.

@pecimuth 
Your change (at version 3661b212f01d2e1708add26fb964c41a9c2d087f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24200#issuecomment-2802293068

From kbarrett at openjdk.org  Mon Apr 14 17:11:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 17:11:50 GMT
Subject: RFR: 8347719: [REDO] Portable implementation of FORBID_C_FUNCTION
 and ALLOW_C_FUNCTION
In-Reply-To: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
References: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
Message-ID: <cHiggAISPxrzGxMimxv-fBwnMmwWI35tWOTQw2aiS1c=.290b414a-a787-4236-9604-7ebbdcf7f9ef@github.com>

On Sat, 12 Apr 2025 13:48:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this second attempt.  It's mostly similar to the original
> attempt:
> https://bugs.openjdk.org/browse/JDK-8313396
> https://github.com/openjdk/jdk/pull/22890
> but improves the workarounds for one clang issue, and adds a workaround for
> another clang issue
> https://bugs.openjdk.org/browse/JDK-8347649
> 
> See globalDefinitions_gcc.hpp for more details about those issues and the
> workarounds.
> 
> Additions to the testing done for the earlier attempt (see below)
> 
> mach5 tier4-5. There is an Oracle-internal build configuration in tier5 that
> failed with the earlier attempt.
> 
> Local manual build and tier1 test on linux with clang.  
> For testing on linux with clang, be aware of these issues:
> https://bugs.openjdk.org/browse/JDK-8354316
> https://bugs.openjdk.org/browse/JDK-8354467
> 
> Below is a repeat of the PR summary for the earlier attempt.  
> 
> ----------
> 
> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances. Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc. (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years. MSVC
> doesn't provide a similar mechanism.) It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated. This relies on deprecation warnings being
> enabled, which they already are in our build configuration. All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed. Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis. That's better for
> our purposes here. (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers. We hide t...

> Just a thought, what if we used decltype instead?
> 
> ```c++
> [[deprecated("use os::malloc")]] decltype(::malloc) malloc;
> [[deprecated("use os::exit")]] decltype(::exit) exit;
> ```

First, that requires the corresponding header be included first, to provide
decltype with something to work with.  (That's part of the current clang
workaround, but not needed for other platforms.  It's not currently a huge
deal, as the set of functions we're poisoning is currently pretty small.  But
I'm not sure that's a forever plan.)

Second, `[[noreturn]]` doesn't affect the type. Though
`__attribute__((noreturn))` does affect the type. (I don't know about
`__declspec((noreturn))`.) See
https://github.com/llvm/llvm-project/issues/113511
(I think it's a mistake in the standard that `[[noreturn]]` doesn't affect the
type, just as it was a mistake that `noexcept` didn't until fixed in C++17.)

Third, I have no idea whether `__declspec((import))` affects the type, and
haven't bothered experimenting because of the above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24608#issuecomment-2802358064

From duke at openjdk.org  Mon Apr 14 18:34:52 2025
From: duke at openjdk.org (Andrej =?UTF-8?B?UGXEjWltw7p0aA==?=)
Date: Mon, 14 Apr 2025 18:34:52 GMT
Subject: Integrated: 8352724: Verify bounds for primitive array reads in JVMCI
In-Reply-To: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
References: <gaAR7VMgwxxGGxPlKpirJyNQOLf9wG4k6Sugn8DxPU8=.d1f4c2b6-8492-4998-898e-ffc7880b56b3@github.com>
Message-ID: <Zxu1hpbtSSbOzFUtJkUi7Azqpxm6-zLpdwsJCP_126o=.f2b8da06-df47-4c5d-97fc-2237121384e8@github.com>

On Mon, 24 Mar 2025 14:31:54 GMT, Andrej Pe?im?th <duke at openjdk.org> wrote:

> This PR adds a bounds check for primitive array reads in JVMCI. When a JVMCI compiler attempts to read after the last array element (from the padding of the allocated object), JVMCI should throw an exception instead of returning a garbage value. The check added in this PR handles both primitive and object reads.

This pull request has now been integrated.

Changeset: de0e6488
Author:    Andrej Pecimuth <andrej.pecimuth at oracle.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de0e6488449303bd15d4590480a2e47b8026a9b1
Stats:     57 lines in 2 files changed: 48 ins; 7 del; 2 mod

8352724: Verify bounds for primitive array reads in JVMCI

Reviewed-by: dnsimon

-------------

PR: https://git.openjdk.org/jdk/pull/24200

From cslucas at openjdk.org  Mon Apr 14 19:09:56 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 14 Apr 2025 19:09:56 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2"
Message-ID: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>

Please, review this trivial PR to set more meaningful names for `get_vm_result*`.

I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.

-------------

Commit messages:
 - Rename get_vm_result and get_vm_result_2 to more meaningfult names.

Changes: https://git.openjdk.org/jdk/pull/24632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354543
  Stats: 216 lines in 49 files changed: 0 ins; 0 del; 216 mod
  Patch: https://git.openjdk.org/jdk/pull/24632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24632/head:pull/24632

PR: https://git.openjdk.org/jdk/pull/24632

From cslucas at openjdk.org  Mon Apr 14 20:10:33 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 14 Apr 2025 20:10:33 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v2]
In-Reply-To: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
Message-ID: <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>

> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
> 
> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Fix merge conflicts
 - Rename get_vm_result and get_vm_result_2 to more meaningfult names.

-------------

Changes: https://git.openjdk.org/jdk/pull/24632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24632&range=01
  Stats: 217 lines in 49 files changed: 0 ins; 1 del; 216 mod
  Patch: https://git.openjdk.org/jdk/pull/24632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24632/head:pull/24632

PR: https://git.openjdk.org/jdk/pull/24632

From coleenp at openjdk.org  Tue Apr 15 11:59:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Apr 2025 11:59:43 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v2]
In-Reply-To: <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
Message-ID: <Q_lM1whrYMbm9o1Lwb26zbzn3E0BpWv9os5n2YytHB0=.c3a19168-1e36-41f3-854a-5f0301a63861@github.com>

On Mon, 14 Apr 2025 20:10:33 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
>> 
>> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
>> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Fix merge conflicts
>  - Rename get_vm_result and get_vm_result_2 to more meaningfult names.

I like this change. vm_result_2 for metadata result was never a good name.

src/hotspot/share/runtime/vmStructs.cpp line 610:

> 608:   nonstatic_field(JavaThread,                  _anchor,                                       JavaFrameAnchor)                       \
> 609:   nonstatic_field(JavaThread,                  _vm_result_oop,                                oop)                                   \
> 610:   nonstatic_field(JavaThread,                  _vm_result_metadata,                           Metadata*)                             \

Delete these two lines.  They're not used by the Serviceability Agent.  And shouldn't be used.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24632#pullrequestreview-2767963168
PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2044352921

From shade at openjdk.org  Tue Apr 15 13:44:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Apr 2025 13:44:45 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v2]
In-Reply-To: <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
Message-ID: <4LbjX1sZxJ2d3kA19M_3jSL-WHH9CbNKm2mlTEsp9Ew=.9dcc9e8b-6606-4d7e-978c-c7f91ac0b6b5@github.com>

On Mon, 14 Apr 2025 20:10:33 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
>> 
>> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
>> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Fix merge conflicts
>  - Rename get_vm_result and get_vm_result_2 to more meaningfult names.

I like this. Some stylistic nits:

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3781:

> 3779:   call_VM(r0, CAST_FROM_FN_PTR(address, InterpreterRuntime::quicken_io_cc));
> 3780:   // vm_result_2 has metadata result
> 3781:   __ get_vm_result_metadata(r0, rthread);

Stale comment just above this line. Grep around for `vm_result_2` to look for other cases?

src/hotspot/share/runtime/javaThread.hpp line 149:

> 147:   // Used to pass back results to the interpreter or generated code running Java code.
> 148:   oop           _vm_result_oop;    // oop result is GC-preserved
> 149:   Metadata*     _vm_result_metadata;  // non-oop result

Suggestion:

  oop           _vm_result_oop;      // oop result is GC-preserved
  Metadata*     _vm_result_metadata; // non-oop result

src/hotspot/share/runtime/javaThread.hpp line 788:

> 786:   // Oop results of vm runtime calls
> 787:   oop  vm_result_oop() const                     { return _vm_result_oop; }
> 788:   void set_vm_result_oop(oop x)                  { _vm_result_oop   = x; }

Suggestion:

  void set_vm_result_oop(oop x)                  { _vm_result_oop = x; }

src/hotspot/share/runtime/javaThread.hpp line 790:

> 788:   void set_vm_result_oop(oop x)                  { _vm_result_oop   = x; }
> 789: 
> 790:   void set_vm_result_metadata(Metadata* x)       { _vm_result_metadata   = x; }

Suggestion:

  void set_vm_result_metadata(Metadata* x)       { _vm_result_metadata = x; }

-------------

PR Review: https://git.openjdk.org/jdk/pull/24632#pullrequestreview-2768307025
PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2044561913
PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2044576179
PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2044574537
PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2044574898

From adinn at openjdk.org  Tue Apr 15 14:18:54 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 14:18:54 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <nrkvZcOEzEhuJLg80zW2a2lfCGYpbrvxaeeBQut4ms8=.e14d6e73-8383-4f42-b418-ab29720e7ce2@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5665:

> 5663:     vs_ld2_post(vs_back(vs1), __ T8H, nttb);
> 5664:     vs_ld2_post(vs_front(vs4), __ T8H, ntta);
> 5665:     vs_ld2_post(vs_back(vs4), __ T8H, nttb);

Suggestion:

    vs_ld2_post(vs_front(vs1), __ T8H, ntta); // <a0, a1> x 8H
    vs_ld2_post(vs_back(vs1), __ T8H, nttb);  // <b0, b1> x 8H
    vs_ld2_post(vs_front(vs4), __ T8H, ntta); // <a2, a3> x 8H
    vs_ld2_post(vs_back(vs4), __ T8H, nttb);  // <b2, b3> x 8H

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5668:

> 5666:     // montmul the first and second pair of values loaded into vs1
> 5667:     // in order and then with one pair reversed storing the  two
> 5668:     // results in vs3

Suggestion:

    // compute 4 montmul cross-products for pairs (a0,a1) and (b0,b1)
    // i.e. montmul the first and second halves of vs1 in order and
    // then with one sequence reversed storing the two results in vs3
    //
    // vs3[0] <- montmul(a0, b0)
    // vs3[1] <- montmul(a1, b1)
    // vs3[2] <- montmul(a0, b1)
    // vs3[3] <- montmul(a1, b0)

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5674:

> 5672:     // montmul the first and second pair of values loaded into vs4
> 5673:     // in order and then with one pair reversed storing the two
> 5674:     // results in vs1

Suggestion:

    // compute 4 montmul cross-products for pairs (a2,a3) and (b2,b3)
    // i.e. montmul the first and second halves of vs4 in order and
    // then with one sequence reversed storing the two results in vs1
    //
    // vs1[0] <- montmul(a2, b2)
    // vs1[1] <- montmul(a3, b3)
    // vs1[2] <- montmul(a2, b3)
    // vs1[3] <- montmul(a3, b2)

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5680:

> 5678:     // for each pair of results pick the second value in the first
> 5679:     // pair to create a sequence that we montmul by the zetas
> 5680:     // i.e. we want sequence <vs3[1], vs1[1]>

Suggestion:

    // montmul result 2 of each cross-product i.e. (a1*b1, a3*b3) by a zeta.
    // We can schedule two montmuls at a time if we use a suitable vector
    // sequence <vs3[1], vs1[1]>.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5683:

> 5681:     int delta = vs1[1]->encoding() - vs3[1]->encoding();
> 5682:     VSeq<2> vs5(vs3[1], delta);
> 5683:     kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq);

Suggestion:

    // vs3[1] <- montmul(montmul(a1, b1), z0)
    // vs1[1] <- montmul(montmul(a3, b3), z1)
    kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044679089
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044682671
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044684696
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044689607
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044691632

From adinn at openjdk.org  Tue Apr 15 14:28:11 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 14:28:11 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <rch4ek3zrBbPY9ms6seAGGvOL6kVkVWTPMzl6VRYn2s=.58b91140-849f-4de2-9eba-cafeec20e51f@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5684:

> 5682:     VSeq<2> vs5(vs3[1], delta);
> 5683:     kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq);
> 5684:     // add results in pairs storing in vs3

Suggestion:

    // add results in pairs storing in vs3
    // vs3[0] <- montmul(a0, b0) + montmul(montmul(a1, b1), z0);
    // vs3[1] <- montmul(a0, b1) + montmul(a1, b0);

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5686:

> 5684:     // add results in pairs storing in vs3
> 5685:     vs_addv(vs_front(vs3), __ T8H, vs_even(vs3), vs_odd(vs3));
> 5686:     vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1));

Suggestion:

    // vs3[2] <- montmul(a2, b2) + montmul(montmul(a3, b3), z1);
    // vs3[3] <- montmul(a2, b3) + montmul(a3, b2);
    vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1));

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5687:

> 5685:     vs_addv(vs_front(vs3), __ T8H, vs_even(vs3), vs_odd(vs3));
> 5686:     vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1));
> 5687:     // montmul result by constant vc and store result in vs1

Suggestion:

    // vs1 <- montmul(vs3, montRSquareModQ)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044712516
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044714830
PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044726778

From adinn at openjdk.org  Tue Apr 15 14:31:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 14:31:53 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
Message-ID: <T2mjqca8jnZBIxkd1mXeugrxgfWv58c2wNOTowOybeQ=.88b40bc5-4f78-415a-a496-631d8e6cc2e2@github.com>

On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Code rearrange, some renaming, fixing comments
>  - Changes suggested by Andrew Dinn.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5690:

> 5688:     kyber_montmul32(vs1, vs3, vc, vs2, vq);
> 5689:     // store the four results as two interleaved pairs of
> 5690:     // quadwords

Suggestion:

    // store back the two pairs of result vectors de-interleaved as 8H elements
    // i.e. storing each pairs of shorts striped across a register pair adjacent
    // in memory

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044745249

From adinn at openjdk.org  Tue Apr 15 14:35:51 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 14:35:51 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
 <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
Message-ID: <6HyHF-GcjuyiiFmcu5uJcbwsg7nxqBrErYc25coOqFk=.d5976962-156e-499c-8b5e-9ef775077016@github.com>

On Mon, 14 Apr 2025 12:26:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate.
>> 
>> I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time).
>> 
>> Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now.
>> 
>> Thanks again for your help in improving this code.
>
> @adinn Hi, Andrew,
>  I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review!

@ferakocz

Hi Ferenc,

Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2805488504

From duke at openjdk.org  Tue Apr 15 15:12:47 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Apr 2025 15:12:47 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v10]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <Q_LqjidmzRE7I2QvL0MPfZsFpbJ8OvuAv6Zys1yweUA=.314cb9a2-68ab-44fd-a81a-925ed0ea925d@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Accepted more comment changes from Andrew Dinn.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/5901547f..b6b3155e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=08-09

  Stats: 43 lines in 1 file changed: 27 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

PR: https://git.openjdk.org/jdk/pull/23663

From duke at openjdk.org  Tue Apr 15 15:12:47 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Apr 2025 15:12:47 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
 <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
Message-ID: <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>

On Mon, 14 Apr 2025 12:26:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate.
>> 
>> I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time).
>> 
>> Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now.
>> 
>> Thanks again for your help in improving this code.
>
> @adinn Hi, Andrew,
>  I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review!

> @ferakocz
> 
> Hi Ferenc,
> 
> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR.

No problem , it was easy to make the changes. Thanks again!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2805981351

From adinn at openjdk.org  Tue Apr 15 16:06:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 16:06:47 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
 <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
 <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>
Message-ID: <jfHg0W8j6x0__SDPcEGiuWwNipMTYd0wCB-MqRQmh74=.9436f0c6-cb11-4efc-b964-5ff436d964c4@github.com>

On Tue, 15 Apr 2025 15:09:16 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> @adinn Hi, Andrew,
>>  I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review!
>
>> @ferakocz
>> 
>> Hi Ferenc,
>> 
>> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR.
> 
> No problem , it was easy to make the changes. Thanks again!

@ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion:


>> ML-KEM-512 encapsulation
1 STDERR:
java.lang.AssertionError
	at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371)
	at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408)
	at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337)
	at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712)
	at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555)
	at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134)
	at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124)
	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265)
	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225)
	at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98)
	at ML_KEM_Test.run(ML_KEM_Test.java:41)
	at Launcher.run(Launcher.java:160)
	at Launcher.main(Launcher.java:122)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1447)

JavaTest Message: Test threw exception: java.lang.AssertionError
JavaTest Message: shutting down test


The offending code is this:

    private void twelve2Sixteen(byte[] condensed, int index,
                                short[] parsed, int parsedLength) {
        int i = parsedLength / 64;
        int remainder = parsedLength - i * 64;
        if (remainder != 0) {
            i++;
        }
        assert (((remainder != 0) && (remainder != 48)) || <== assert here
            index + i * 96 > condensed.length);

I believe the logic is reversed here i.e. it should be:

        assert ((remainder == 0) || (remainder == 48)) &&
            index + i * 96 <= condensed.length);

Does that sound right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2806628550

From duke at openjdk.org  Tue Apr 15 18:18:36 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Apr 2025 18:18:36 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed asserts.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/b6b3155e..3c3bca61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

PR: https://git.openjdk.org/jdk/pull/23663

From duke at openjdk.org  Tue Apr 15 18:23:51 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Apr 2025 18:23:51 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
 <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
 <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>
Message-ID: <qX4b7YPeP2v8yqjOVlmrNAwkygXi37-FWP_peK5FkY8=.23842585-a0e9-425f-b04e-553771370ab9@github.com>

On Tue, 15 Apr 2025 15:09:16 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> @adinn Hi, Andrew,
>>  I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review!
>
>> @ferakocz
>> 
>> Hi Ferenc,
>> 
>> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR.
> 
> No problem , it was easy to make the changes. Thanks again!

> @ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion:
> 
> ```
> >> ML-KEM-512 encapsulation
> 1 STDERR:
> java.lang.AssertionError
> 	at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371)
> 	at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408)
> 	at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337)
> 	at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712)
> 	at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555)
> 	at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134)
> 	at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124)
> 	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265)
> 	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225)
> 	at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98)
> 	at ML_KEM_Test.run(ML_KEM_Test.java:41)
> 	at Launcher.run(Launcher.java:160)
> 	at Launcher.main(Launcher.java:122)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> JavaTest Message: Test threw exception: java.lang.AssertionError
> JavaTest Message: shutting down test
> ```
> 
> The offending code is this:
> 
> ```
> private void twelve2Sixteen(byte[] condensed, int index,
>                             short[] parsed, int parsedLength) {
>     int i = parsedLength / 64;
>     int remainder = parsedLength - i * 64;
>     if (remainder != 0) {
>         i++;
>     }
>     assert (((remainder != 0) && (remainder != 48)) || <== assert here
>         index + i * 96 > condensed.length);
> ```
> 
> I believe the logic is reversed here i.e. it should be:
> 
> ```
>     assert ((remainder == 0) || (remainder == 48)) &&
>         index + i * 96 <= condensed.length);
> ```
> 
> Does that sound right?

Aarrrrgh, yes. I forgot to negate that condition when I went from throwing an exception to assert, and I also thought, incorrectly, that -ea would enable my assertions when I tested  :-( .
Thanks a lot for catching it!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2807096779

From jsjolen at openjdk.org  Wed Apr 16 06:50:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Apr 2025 06:50:40 GMT
Subject: RFR: 8347719: [REDO] Portable implementation of FORBID_C_FUNCTION
 and ALLOW_C_FUNCTION
In-Reply-To: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
References: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
Message-ID: <NceVTPXvbeXQnwcM5csfn0o3Bo8lDYZPANKaqhdFRgw=.288403a9-493d-4777-94b2-2582e1b84356@github.com>

On Sat, 12 Apr 2025 13:48:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this second attempt.  It's mostly similar to the original
> attempt:
> https://bugs.openjdk.org/browse/JDK-8313396
> https://github.com/openjdk/jdk/pull/22890
> but improves the workarounds for one clang issue, and adds a workaround for
> another clang issue
> https://bugs.openjdk.org/browse/JDK-8347649
> 
> See globalDefinitions_gcc.hpp for more details about those issues and the
> workarounds.
> 
> Additions to the testing done for the earlier attempt (see below)
> 
> mach5 tier4-5. There is an Oracle-internal build configuration in tier5 that
> failed with the earlier attempt.
> 
> Local manual build and tier1 test on linux with clang.  
> For testing on linux with clang, be aware of these issues:
> https://bugs.openjdk.org/browse/JDK-8354316
> https://bugs.openjdk.org/browse/JDK-8354467
> 
> Below is a repeat of the PR summary for the earlier attempt.  
> 
> ----------
> 
> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances. Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc. (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years. MSVC
> doesn't provide a similar mechanism.) It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated. This relies on deprecation warnings being
> enabled, which they already are in our build configuration. All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed. Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis. That's better for
> our purposes here. (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers. We hide t...

LGTM, I hope we don't have to back this one out :-).

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24608#pullrequestreview-2771340823

From xgong at openjdk.org  Wed Apr 16 09:03:43 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Apr 2025 09:03:43 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
Message-ID: <SXVc5_8Mb-GDTjTqXtjdW-ExD53sOkak8akAUofbPHo=.984b210d-1440-4414-af79-52dd493420e9@github.com>

### Summary:
[JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.

### Background:
Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).

The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.

Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:

1. `MaxVectorSize = 16, byte_vector_size = 16`:
   - Can load 4 indices per vector register
   - So can finish 4 bytes per gather-load operation
   - Requires 4 times of gather-loads and final merge
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
   int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   4 gather-load:
   idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
   idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
   idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
   idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
   merge: v = [jlkp bhga cfhf becd]
   ```

2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
   - Can load 8 indices per vector register
   - So can finish 8 bytes per gather-load operation
   - Requires 2 times of gather-loads and merge
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   2 gather-load:
   idx_v1 = [2 5 7 5 1 4 2 3]
   idx_v2 = [9 11 10 15 1 7 6 0]
   gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
   gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
   merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
   - Can load 16 indices per vector register
   - So can finish 16 bytes per gather-load operation
   - No splitting required
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   1 gather-load:
   idx_v = [9 11 10 15 1 7 6 0 2 5 7 5 1 4 2 3]
   v = [... 0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

4. `MaxVectorSize > 64, byte_vector_size < MaxVectorSize / 4`:
   - Can load 32+ indices per vector register
   - So can finish 16 bytes per gather-load operation
   - Requires masking to allow loading 16 active elements to keep safe
     memory access.
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   1 gather-load:
   idx_v = [... 0 0 0 0 0 0 0 0 9 11 10 15 1 7 6 0 2 5 7 5 1 4 2 3]
   v = [... 0000 0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

### Main changes:
1. Java-side API refactoring:
   - Potential multiple index vectors have been generated for index checking in java-side. This patch passes all the generated index vectors to hotspot to eliminate the duplicate index vectors used for the vector gather load operations on architectures like AArch64. Existing IGVN cannot work due to the different control flow of the index vectors generated in java-side and compiler intrinsifying.
2. C2 compiler IR refactoring:
   - Generate different IR patterns for different architectures like AArch64 and X86, based on the different index requirements.
   - Added two new IRs in C2 compiler to help implement each part of vector gather operation and merge the results at last.
   - Refactored the `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types. This patch removes the memory offset input and add it to the memory base `addr` in IR level for architectures that need the index array like X86. This not only simplifies the backend implementation, but also saves some add operations. Additionally, it unifies the IR for all types.
3. Backend changes:
   - Added SVE match rules for subword gather load operations and the new added IRs.
   - Refined the X86 implementation of subword gather since the offset input has been removed from the IR level.
4. Test:
   - Added IR tests for verification.

### Testing:
- Passed hotspot::tier1/2/3, jdk::tier1/2/3 tests
- Passed vector api tests with all `UseAVX
` flags on X86 and `UseSVE` flags on AArch64
- No regressions found

### Performance:
The performance of corresponding JMH benchmarks improve 3-11x on an NVIDIA GRACE CPU, which is a 128-bit SVE2 architecture. Following is the performance data:


Benchmark                                                (SIZE)   Mode Cnt  Units    Before     After    Gain
GatherOperationsBenchmark.microByteGather128                 64  thrpt  30  ops/ms  13447.414 43184.611  3.21
GatherOperationsBenchmark.microByteGather128                256  thrpt  30  ops/ms   3361.944 11165.006  3.32
GatherOperationsBenchmark.microByteGather128               1024  thrpt  30  ops/ms    843.501  2830.108  3.35
GatherOperationsBenchmark.microByteGather128               4096  thrpt  30  ops/ms    211.096   712.958  3.37
GatherOperationsBenchmark.microByteGather128_MASK            64  thrpt  30  ops/ms  10627.297 42818.402  4.02
GatherOperationsBenchmark.microByteGather128_MASK           256  thrpt  30  ops/ms   2675.144 11055.874  4.13
GatherOperationsBenchmark.microByteGather128_MASK          1024  thrpt  30  ops/ms    677.742  2783.920  4.10
GatherOperationsBenchmark.microByteGather128_MASK          4096  thrpt  30  ops/ms    169.416   686.783  4.05
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF     64  thrpt  30  ops/ms  10592.545 42282.802  3.99
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF    256  thrpt  30  ops/ms   2680.060 11039.563  4.11
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   1024  thrpt  30  ops/ms    678.941  2790.252  4.10
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   4096  thrpt  30  ops/ms    169.985   691.157  4.06
GatherOperationsBenchmark.microByteGather128_NZ_OFF          64  thrpt  30  ops/ms  13538.308 42954.988  3.17
GatherOperationsBenchmark.microByteGather128_NZ_OFF         256  thrpt  30  ops/ms   3414.237 11227.333  3.28
GatherOperationsBenchmark.microByteGather128_NZ_OFF        1024  thrpt  30  ops/ms    850.098  2821.821  3.31
GatherOperationsBenchmark.microByteGather128_NZ_OFF        4096  thrpt  30  ops/ms    213.295   705.015  3.30
GatherOperationsBenchmark.microByteGather64                  64  thrpt  30  ops/ms   8705.935 44213.982  5.07
GatherOperationsBenchmark.microByteGather64                 256  thrpt  30  ops/ms   2186.620 11407.364  5.21
GatherOperationsBenchmark.microByteGather64                1024  thrpt  30  ops/ms    545.364  2845.370  5.21
GatherOperationsBenchmark.microByteGather64                4096  thrpt  30  ops/ms    136.376   718.532  5.26
GatherOperationsBenchmark.microByteGather64_MASK             64  thrpt  30  ops/ms   6530.636 42053.044  6.43
GatherOperationsBenchmark.microByteGather64_MASK            256  thrpt  30  ops/ms   1644.069 11323.223  6.88
GatherOperationsBenchmark.microByteGather64_MASK           1024  thrpt  30  ops/ms    416.093  2844.712  6.83
GatherOperationsBenchmark.microByteGather64_MASK           4096  thrpt  30  ops/ms    105.777   716.685  6.77
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF      64  thrpt  30  ops/ms   6619.260 42204.919  6.37
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF     256  thrpt  30  ops/ms   1668.304 11318.298  6.78
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    1024  thrpt  30  ops/ms    422.085  2844.398  6.73
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    4096  thrpt  30  ops/ms    105.722   716.543  6.77
GatherOperationsBenchmark.microByteGather64_NZ_OFF           64  thrpt  30  ops/ms   8754.073 44232.985  5.05
GatherOperationsBenchmark.microByteGather64_NZ_OFF          256  thrpt  30  ops/ms   2195.009 11408.702  5.19
GatherOperationsBenchmark.microByteGather64_NZ_OFF         1024  thrpt  30  ops/ms    546.530  2845.369  5.20
GatherOperationsBenchmark.microByteGather64_NZ_OFF         4096  thrpt  30  ops/ms    137.713   718.391  5.21
GatherOperationsBenchmark.microShortGather128                64  thrpt  30  ops/ms   8695.558 33438.398  3.84
GatherOperationsBenchmark.microShortGather128               256  thrpt  30  ops/ms   2189.766  8533.643  3.89
GatherOperationsBenchmark.microShortGather128              1024  thrpt  30  ops/ms    546.322  2145.239  3.92
GatherOperationsBenchmark.microShortGather128              4096  thrpt  30  ops/ms    136.503   537.493  3.93
GatherOperationsBenchmark.microShortGather128_MASK           64  thrpt  30  ops/ms   6656.883 33571.619  5.04
GatherOperationsBenchmark.microShortGather128_MASK          256  thrpt  30  ops/ms   1649.233  8533.728  5.17
GatherOperationsBenchmark.microShortGather128_MASK         1024  thrpt  30  ops/ms    421.687  2135.280  5.06
GatherOperationsBenchmark.microShortGather128_MASK         4096  thrpt  30  ops/ms    105.355   537.418  5.10
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF    64  thrpt  30  ops/ms   6675.782 33441.402  5.00
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF   256  thrpt  30  ops/ms   1681.000  8532.770  5.07
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  1024  thrpt  30  ops/ms    424.024  2135.485  5.03
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  4096  thrpt  30  ops/ms    106.507   537.674  5.04
GatherOperationsBenchmark.microShortGather128_NZ_OFF         64  thrpt  30  ops/ms   8796.279 33441.738  3.80
GatherOperationsBenchmark.microShortGather128_NZ_OFF        256  thrpt  30  ops/ms   2198.774  8562.333  3.89
GatherOperationsBenchmark.microShortGather128_NZ_OFF       1024  thrpt  30  ops/ms    546.991  2133.496  3.90
GatherOperationsBenchmark.microShortGather128_NZ_OFF       4096  thrpt  30  ops/ms    137.191   537.390  3.91
GatherOperationsBenchmark.microShortGather64                 64  thrpt  30  ops/ms   5286.569 38042.434  7.19
GatherOperationsBenchmark.microShortGather64                256  thrpt  30  ops/ms   1312.778  9755.474  7.43
GatherOperationsBenchmark.microShortGather64               1024  thrpt  30  ops/ms    327.475  2450.755  7.48
GatherOperationsBenchmark.microShortGather64               4096  thrpt  30  ops/ms     82.490   613.481  7.43
GatherOperationsBenchmark.microShortGather64_MASK            64  thrpt  30  ops/ms   3525.102 37622.086  10.67
GatherOperationsBenchmark.microShortGather64_MASK           256  thrpt  30  ops/ms    877.877  9740.673  11.09
GatherOperationsBenchmark.microShortGather64_MASK          1024  thrpt  30  ops/ms    219.688  2446.063  11.13
GatherOperationsBenchmark.microShortGather64_MASK          4096  thrpt  30  ops/ms     54.935   613.137  11.16
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF     64  thrpt  30  ops/ms   3509.264 35147.895  10.01
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF    256  thrpt  30  ops/ms    880.523  9733.536  11.05
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   1024  thrpt  30  ops/ms    220.578  2465.951  11.17
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   4096  thrpt  30  ops/ms     55.790   620.465  11.12
GatherOperationsBenchmark.microShortGather64_NZ_OFF          64  thrpt  30  ops/ms   5271.218 35543.510  6.74
GatherOperationsBenchmark.microShortGather64_NZ_OFF         256  thrpt  30  ops/ms   1318.470  9735.321  7.38
GatherOperationsBenchmark.microShortGather64_NZ_OFF        1024  thrpt  30  ops/ms    328.695  2466.311  7.50
GatherOperationsBenchmark.microShortGather64_NZ_OFF        4096  thrpt  30  ops/ms     81.959   621.065  7.57



And here is the performance data on a X86 avx512 system, which shows the performance can improve at most 39%.


Benchmark                                                (SIZE)   Mode Cnt  Units    Before      After    Gain
GatherOperationsBenchmark.microByteGather128                 64  thrpt  30  ops/ms  44205.252  46829.437  1.05
GatherOperationsBenchmark.microByteGather128                256  thrpt  30  ops/ms  11243.202  12256.211  1.09
GatherOperationsBenchmark.microByteGather128               1024  thrpt  30  ops/ms   2824.094   3096.282  1.09
GatherOperationsBenchmark.microByteGather128               4096  thrpt  30  ops/ms    706.040    776.444  1.09
GatherOperationsBenchmark.microByteGather128_MASK            64  thrpt  30  ops/ms  46911.410  46321.310  0.98
GatherOperationsBenchmark.microByteGather128_MASK           256  thrpt  30  ops/ms  12850.712  12898.541  1.00
GatherOperationsBenchmark.microByteGather128_MASK          1024  thrpt  30  ops/ms   3099.038   3240.863  1.04
GatherOperationsBenchmark.microByteGather128_MASK          4096  thrpt  30  ops/ms    795.265    832.990  1.04
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF     64  thrpt  30  ops/ms  43065.930  47164.936  1.09
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF    256  thrpt  30  ops/ms  11537.805  13190.759  1.14
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   1024  thrpt  30  ops/ms   2763.036   3304.582  1.19
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   4096  thrpt  30  ops/ms    722.374    843.458  1.16
GatherOperationsBenchmark.microByteGather128_NZ_OFF          64  thrpt  30  ops/ms  44145.297  46845.845  1.06
GatherOperationsBenchmark.microByteGather128_NZ_OFF         256  thrpt  30  ops/ms  12172.421  12241.941  1.00
GatherOperationsBenchmark.microByteGather128_NZ_OFF        1024  thrpt  30  ops/ms   3097.042   3100.228  1.00
GatherOperationsBenchmark.microByteGather128_NZ_OFF        4096  thrpt  30  ops/ms    776.453    775.881  0.99
GatherOperationsBenchmark.microByteGather64                  64  thrpt  30  ops/ms  58541.178  59464.156  1.01
GatherOperationsBenchmark.microByteGather64                 256  thrpt  30  ops/ms  16063.284  17360.858  1.08
GatherOperationsBenchmark.microByteGather64                1024  thrpt  30  ops/ms   4126.798   4471.636  1.08
GatherOperationsBenchmark.microByteGather64                4096  thrpt  30  ops/ms   1045.116   1125.219  1.07
GatherOperationsBenchmark.microByteGather64_MASK             64  thrpt  30  ops/ms  35344.320  49062.831  1.38
GatherOperationsBenchmark.microByteGather64_MASK            256  thrpt  30  ops/ms  11946.622  13550.297  1.13
GatherOperationsBenchmark.microByteGather64_MASK           1024  thrpt  30  ops/ms   3275.053   3359.737  1.02
GatherOperationsBenchmark.microByteGather64_MASK           4096  thrpt  30  ops/ms    844.575    858.487  1.01
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF      64  thrpt  30  ops/ms  43550.522  48875.831  1.12
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF     256  thrpt  30  ops/ms  12216.995  13522.420  1.10
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    1024  thrpt  30  ops/ms   3053.068   3391.067  1.11
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    4096  thrpt  30  ops/ms    753.042    869.774  1.15
GatherOperationsBenchmark.microByteGather64_NZ_OFF           64  thrpt  30  ops/ms  52082.307  58847.230  1.12
GatherOperationsBenchmark.microByteGather64_NZ_OFF          256  thrpt  30  ops/ms  14210.930  17389.898  1.22
GatherOperationsBenchmark.microByteGather64_NZ_OFF         1024  thrpt  30  ops/ms   3697.996   4476.988  1.21
GatherOperationsBenchmark.microByteGather64_NZ_OFF         4096  thrpt  30  ops/ms    921.524   1125.308  1.22
GatherOperationsBenchmark.microShortGather128                64  thrpt  30  ops/ms  44325.212  44843.853  1.01
GatherOperationsBenchmark.microShortGather128               256  thrpt  30  ops/ms  11675.510  12630.103  1.08
GatherOperationsBenchmark.microShortGather128              1024  thrpt  30  ops/ms   1260.004   1373.395  1.09
GatherOperationsBenchmark.microShortGather128              4096  thrpt  30  ops/ms    761.857    814.790  1.06
GatherOperationsBenchmark.microShortGather128_MASK           64  thrpt  30  ops/ms  36339.450  36951.803  1.01
GatherOperationsBenchmark.microShortGather128_MASK          256  thrpt  30  ops/ms   9843.842  10018.754  1.01
GatherOperationsBenchmark.microShortGather128_MASK         1024  thrpt  30  ops/ms   2515.702   2595.312  1.03
GatherOperationsBenchmark.microShortGather128_MASK         4096  thrpt  30  ops/ms    616.450    661.402  1.07
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF    64  thrpt  30  ops/ms  34078.747  33712.577  0.98
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF   256  thrpt  30  ops/ms   9018.316   8515.947  0.94
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  1024  thrpt  30  ops/ms   2250.813   2595.847  1.15
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  4096  thrpt  30  ops/ms    563.182    659.087  1.17
GatherOperationsBenchmark.microShortGather128_NZ_OFF         64  thrpt  30  ops/ms  39909.543  44063.331  1.10
GatherOperationsBenchmark.microShortGather128_NZ_OFF        256  thrpt  30  ops/ms  10690.582  12437.166  1.16
GatherOperationsBenchmark.microShortGather128_NZ_OFF       1024  thrpt  30  ops/ms   2677.219   3151.078  1.17
GatherOperationsBenchmark.microShortGather128_NZ_OFF       4096  thrpt  30  ops/ms    681.705    802.929  1.17
GatherOperationsBenchmark.microShortGather64                 64  thrpt  30  ops/ms  45836.789  50883.505  1.11
GatherOperationsBenchmark.microShortGather64                256  thrpt  30  ops/ms  12269.355  13614.567  1.10
GatherOperationsBenchmark.microShortGather64               1024  thrpt  30  ops/ms   3010.548   3437.973  1.14
GatherOperationsBenchmark.microShortGather64               4096  thrpt  30  ops/ms    734.634    899.070  1.22
GatherOperationsBenchmark.microShortGather64_MASK            64  thrpt  30  ops/ms  39753.487  39319.742  0.98
GatherOperationsBenchmark.microShortGather64_MASK           256  thrpt  30  ops/ms  10615.540  10648.996  1.00
GatherOperationsBenchmark.microShortGather64_MASK          1024  thrpt  30  ops/ms   2653.485   2782.477  1.04
GatherOperationsBenchmark.microShortGather64_MASK          4096  thrpt  30  ops/ms    678.165    686.024  1.01
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF     64  thrpt  30  ops/ms  37742.593  40491.965  1.07
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF    256  thrpt  30  ops/ms  10096.251  11036.785  1.09
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   1024  thrpt  30  ops/ms   2526.374   2812.550  1.11
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   4096  thrpt  30  ops/ms    642.484    656.152  1.02
GatherOperationsBenchmark.microShortGather64_NZ_OFF          64  thrpt  30  ops/ms  40602.930  50921.048  1.25
GatherOperationsBenchmark.microShortGather64_NZ_OFF         256  thrpt  30  ops/ms  10972.083  14151.666  1.28
GatherOperationsBenchmark.microShortGather64_NZ_OFF        1024  thrpt  30  ops/ms   2726.248   3662.293  1.34
GatherOperationsBenchmark.microShortGather64_NZ_OFF        4096  thrpt  30  ops/ms    670.735    933.299  1.39


[1] https://bugs.openjdk.org/browse/JDK-8318650
[2] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1B--scalar-plus-vector---Gather-load-unsigned-bytes-to-vector--vector-index--?lang=en
[3] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1H--scalar-plus-vector---Gather-load-unsigned-halfwords-to-vector--vector-index--?lang=en

-------------

Commit messages:
 - 8351623: VectorAPI: Refactor subword gather load and add SVE implementation

Changes: https://git.openjdk.org/jdk/pull/24679/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351623
  Stats: 1367 lines in 34 files changed: 915 ins; 180 del; 272 mod
  Patch: https://git.openjdk.org/jdk/pull/24679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24679/head:pull/24679

PR: https://git.openjdk.org/jdk/pull/24679

From adinn at openjdk.org  Wed Apr 16 09:55:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 16 Apr 2025 09:55:46 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
Message-ID: <GjT3Hl-xGXxHiwe50Tb_v3GFKoocR2_CRkgzT0v2rdM=.f487ed3b-845c-49fe-a1f1-02eba22e1c2f@github.com>

On Tue, 15 Apr 2025 18:18:36 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed asserts.

@ferakocz I reran the test and the perf test and all appears to be good. Nice work!

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23663#pullrequestreview-2771908852

From duke at openjdk.org  Wed Apr 16 11:40:49 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Apr 2025 11:40:49 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7]
In-Reply-To: <qX4b7YPeP2v8yqjOVlmrNAwkygXi37-FWP_peK5FkY8=.23842585-a0e9-425f-b04e-553771370ab9@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <xP7yJttn_x7e1UtsEDYNbMpQxoOVfSpOHFhGdqKLqsY=.adf95415-5c44-4994-a951-d4c900ac10db@github.com>
 <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com>
 <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com>
 <a39WCGX1zIQM8jBI11jG6SKzT5s3eWsZfb-leJUqlfI=.509c3416-2ac0-4e2a-9c86-f4b4267be32d@github.com>
 <qX4b7YPeP2v8yqjOVlmrNAwkygXi37-FWP_peK5FkY8=.23842585-a0e9-425f-b04e-553771370ab9@github.com>
Message-ID: <Qa6kHkPGHFZJFBF_xctK7u_TTTGzEf7qwbVhgymxK2c=.71090eff-647d-4876-bbe0-41b8a69461db@github.com>

On Tue, 15 Apr 2025 18:21:00 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>>> @ferakocz
>>> 
>>> Hi Ferenc,
>>> 
>>> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR.
>> 
>> No problem , it was easy to make the changes. Thanks again!
>
>> @ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion:
>> 
>> ```
>> >> ML-KEM-512 encapsulation
>> 1 STDERR:
>> java.lang.AssertionError
>> 	at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371)
>> 	at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408)
>> 	at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337)
>> 	at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712)
>> 	at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555)
>> 	at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134)
>> 	at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124)
>> 	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265)
>> 	at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225)
>> 	at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98)
>> 	at ML_KEM_Test.run(ML_KEM_Test.java:41)
>> 	at Launcher.run(Launcher.java:160)
>> 	at Launcher.main(Launcher.java:122)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> JavaTest Message: Test threw exception: java.lang.AssertionError
>> JavaTest Message: shutting down test
>> ```
>> 
>> The offending code is this:
>> 
>> ```
>> private void twelve2Sixteen(byte[] condensed, int index,
>>                             short[] parsed, int parsedLength) {
>>     int i = parsedLength / 64;
>>     int remainder = parsedLength - i * 64;
>>     if (remainder != 0) {
>>         i++;
>>     }
>>     assert (((remainder != 0) && (remainder != 48)) || <== assert here
>>         index + i * 96 > condensed.length);
>> ```
>> 
>> I believe the logic is reversed here i.e. it should be:
>> 
>> ```
>>     assert ((remainder == 0) || (remainder == 48)) &&
>>         index + i * 96 <= condensed.length);
>> ```
>> 
>> Does that sound right?
> 
> Aarrrrgh, yes. I forgot to negate that condition when I went from throwing an exception to assert, and I also thought, incorrectly, that -ea would enable my assertions when I tested  :-( .
> Thanks a lot for catching it!

> @ferakocz I reran the test and the perf test and all appears to be good. Nice work!

@adinn Thanks, Andrew, for all the help, it really looks nicer than it looked before your review! Would you /sponsor the integration?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2809306397

From duke at openjdk.org  Wed Apr 16 12:38:54 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Apr 2025 12:38:54 GMT
Subject: Integrated: 8349721: Add aarch64 intrinsics for ML-KEM
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <wmIfno6gUR9VhUO3qN1Hf5nvcVBBoN197YcRSGnQLUE=.ae3bb551-da7a-4095-82ed-022c3aa0462b@github.com>

On Mon, 17 Feb 2025 13:53:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

This pull request has now been integrated.

Changeset: 465c8e65
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/465c8e658356f658ee04397936f555f6bdffc3c2
Stats:     2569 lines in 20 files changed: 2420 ins; 46 del; 103 mod

8349721: Add aarch64 intrinsics for ML-KEM

Reviewed-by: adinn

-------------

PR: https://git.openjdk.org/jdk/pull/23663

From kbarrett at openjdk.org  Wed Apr 16 13:08:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 16 Apr 2025 13:08:41 GMT
Subject: RFR: 8347719: [REDO] Portable implementation of FORBID_C_FUNCTION
 and ALLOW_C_FUNCTION [v2]
In-Reply-To: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
References: <cJnddZbGcpSeyAmemKWPWFU6NsfEhbdaKrABpFKPTUA=.575edbd2-0f97-4fdf-aea8-e0c48a486532@github.com>
Message-ID: <Ik4J-mNkmr88HOYaWJvsxZH31sOYYdpwuHczTzyBydQ=.51917d7c-7169-4e59-a35e-84fb0147dbdb@github.com>

> Please review this second attempt.  It's mostly similar to the original
> attempt:
> https://bugs.openjdk.org/browse/JDK-8313396
> https://github.com/openjdk/jdk/pull/22890
> but improves the workarounds for one clang issue, and adds a workaround for
> another clang issue
> https://bugs.openjdk.org/browse/JDK-8347649
> 
> See globalDefinitions_gcc.hpp for more details about those issues and the
> workarounds.
> 
> Additions to the testing done for the earlier attempt (see below)
> 
> mach5 tier4-5. There is an Oracle-internal build configuration in tier5 that
> failed with the earlier attempt.
> 
> Local manual build and tier1 test on linux with clang.  
> For testing on linux with clang, be aware of these issues:
> https://bugs.openjdk.org/browse/JDK-8354316
> https://bugs.openjdk.org/browse/JDK-8354467
> 
> Below is a repeat of the PR summary for the earlier attempt.  
> 
> ----------
> 
> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances. Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc. (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years. MSVC
> doesn't provide a similar mechanism.) It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated. This relies on deprecation warnings being
> enabled, which they already are in our build configuration. All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed. Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis. That's better for
> our purposes here. (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers. We hide t...

Kim Barrett 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 four additional commits since the last revision:

 - Merge branch 'master' into redo-poisoning
 - note that clang bug with deprecated attribute has been fixed
 - improve/add clang-specific workarounds
 - apply original change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24608/files
  - new: https://git.openjdk.org/jdk/pull/24608/files/ae4f67f7..ed63515b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24608&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24608&range=00-01

  Stats: 176886 lines in 280 files changed: 8193 ins; 167956 del; 737 mod
  Patch: https://git.openjdk.org/jdk/pull/24608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24608/head:pull/24608

PR: https://git.openjdk.org/jdk/pull/24608

From cslucas at openjdk.org  Wed Apr 16 17:56:28 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 16 Apr 2025 17:56:28 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v3]
In-Reply-To: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
Message-ID: <CgLq_TKHhTwZOfGg0I5AFaf9qkTeHlUisc_MakH4wBE=.02bc3546-04f1-4c6c-bd0b-fe8f45b5d3ca@github.com>

> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
> 
> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Remove stale comments & dead code.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24632/files
  - new: https://git.openjdk.org/jdk/pull/24632/files/ce19dd8d..1333e4a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24632&range=01-02

  Stats: 12 lines in 6 files changed: 0 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24632/head:pull/24632

PR: https://git.openjdk.org/jdk/pull/24632

From shade at openjdk.org  Wed Apr 16 18:26:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Apr 2025 18:26:50 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v3]
In-Reply-To: <CgLq_TKHhTwZOfGg0I5AFaf9qkTeHlUisc_MakH4wBE=.02bc3546-04f1-4c6c-bd0b-fe8f45b5d3ca@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <CgLq_TKHhTwZOfGg0I5AFaf9qkTeHlUisc_MakH4wBE=.02bc3546-04f1-4c6c-bd0b-fe8f45b5d3ca@github.com>
Message-ID: <Zm-s43Pbmq9taLVpNYvIjRAkwSAAl8Z1hJ6-0mBp1JQ=.d4bb77cb-c195-49c5-96eb-499dcff2dc84@github.com>

On Wed, 16 Apr 2025 17:56:28 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
>> 
>> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
>> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stale comments & dead code.

Looks good!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24632#pullrequestreview-2773447605

From coleenp at openjdk.org  Wed Apr 16 18:44:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Apr 2025 18:44:49 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v2]
In-Reply-To: <4LbjX1sZxJ2d3kA19M_3jSL-WHH9CbNKm2mlTEsp9Ew=.9dcc9e8b-6606-4d7e-978c-c7f91ac0b6b5@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
 <4LbjX1sZxJ2d3kA19M_3jSL-WHH9CbNKm2mlTEsp9Ew=.9dcc9e8b-6606-4d7e-978c-c7f91ac0b6b5@github.com>
Message-ID: <UC27aUi82XgoVsi7uzBUEHUWEmzR7X_M-WeU-Z8AoSk=.02cfeeb2-840a-488a-aa61-a0dd8ea8541d@github.com>

On Tue, 15 Apr 2025 13:41:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Fix merge conflicts
>>  - Rename get_vm_result and get_vm_result_2 to more meaningfult names.
>
> src/hotspot/share/runtime/javaThread.hpp line 788:
> 
>> 786:   // Oop results of vm runtime calls
>> 787:   oop  vm_result_oop() const                     { return _vm_result_oop; }
>> 788:   void set_vm_result_oop(oop x)                  { _vm_result_oop   = x; }
> 
> Suggestion:
> 
>   void set_vm_result_oop(oop x)                  { _vm_result_oop = x; }

I don't think John fixed the space here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2047509566

From shade at openjdk.org  Wed Apr 16 18:53:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Apr 2025 18:53:52 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v2]
In-Reply-To: <UC27aUi82XgoVsi7uzBUEHUWEmzR7X_M-WeU-Z8AoSk=.02cfeeb2-840a-488a-aa61-a0dd8ea8541d@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <U2BIJkV46A4LYffxYAEtUlU8luBNRLkS3yVfI1ell-8=.706c911d-a328-4e47-87bf-6b3555311e7c@github.com>
 <4LbjX1sZxJ2d3kA19M_3jSL-WHH9CbNKm2mlTEsp9Ew=.9dcc9e8b-6606-4d7e-978c-c7f91ac0b6b5@github.com>
 <UC27aUi82XgoVsi7uzBUEHUWEmzR7X_M-WeU-Z8AoSk=.02cfeeb2-840a-488a-aa61-a0dd8ea8541d@github.com>
Message-ID: <zHHld796EeIC6u39fAjF0-We5oBfci-liJqU7NmTmIY=.65545209-fccd-4a24-87c3-02c216612b7f@github.com>

On Wed, 16 Apr 2025 18:41:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 788:
>> 
>>> 786:   // Oop results of vm runtime calls
>>> 787:   oop  vm_result_oop() const                     { return _vm_result_oop; }
>>> 788:   void set_vm_result_oop(oop x)                  { _vm_result_oop   = x; }
>> 
>> Suggestion:
>> 
>>   void set_vm_result_oop(oop x)                  { _vm_result_oop = x; }
>
> I don't think John fixed the space here.

Right. But whatever, I won't quibble. @JohnTortugo -- fix it if you can.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24632#discussion_r2047538430

From vlivanov at openjdk.org  Wed Apr 16 19:26:00 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 19:26:00 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
Message-ID: <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>

On Tue, 15 Apr 2025 18:18:36 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed asserts.

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717:

> 715:   desc_len = (int)strlen(_cpu_desc);
> 716:   snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string);
> 717:   fprintf(stderr, "_features_string = \"%s\"", _features_string);

Was this line added by mistake? Looks like a leftover.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2047606222

From duke at openjdk.org  Wed Apr 16 22:22:42 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 22:22:42 GMT
Subject: RFR: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2" [v3]
In-Reply-To: <CgLq_TKHhTwZOfGg0I5AFaf9qkTeHlUisc_MakH4wBE=.02bc3546-04f1-4c6c-bd0b-fe8f45b5d3ca@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
 <CgLq_TKHhTwZOfGg0I5AFaf9qkTeHlUisc_MakH4wBE=.02bc3546-04f1-4c6c-bd0b-fe8f45b5d3ca@github.com>
Message-ID: <9EmszL4FRj8g-NPXZyLgm118UMLDBy9zLGeU8FsIxiY=.5d1acfef-a0dd-4b7c-a008-2e0c2eeb7c2b@github.com>

On Wed, 16 Apr 2025 17:56:28 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
>> 
>> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
>> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stale comments & dead code.

@JohnTortugo 
Your change (at version 1333e4a0d84f337e652b246b39e956fd897c2655) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24632#issuecomment-2810943921

From cslucas at openjdk.org  Thu Apr 17 06:11:52 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 17 Apr 2025 06:11:52 GMT
Subject: Integrated: 8354543: Set more meaningful names for "get_vm_result" and
 "get_vm_result_2"
In-Reply-To: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
References: <yX5TiXbUvcJg01fYygZl0OPz7Jo1A_947lWYOmOvAOs=.63b5af89-f40d-49e0-8146-f98d8e2c1a14@github.com>
Message-ID: <GHCBs85gxzISX9mdDZOL1D4y4IDsB4rAqZDHgckRhUY=.04df66aa-4d2e-4c42-a1fe-b0778ca1b4f3@github.com>

On Mon, 14 Apr 2025 18:54:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this trivial PR to set more meaningful names for `get_vm_result*`.
> 
> I tested the best I could on OSX AArch64 & Linux amd64 with JTREG tier1-3.
> The other platforms I tested by cross-compiling. If you can run some tests on those platform I'd appreciate.

This pull request has now been integrated.

Changeset: 055b750d
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/055b750d999e52569094bffa7dc0364a50771853
Stats:     225 lines in 49 files changed: 0 ins; 10 del; 215 mod

8354543: Set more meaningful names for "get_vm_result" and "get_vm_result_2"

Reviewed-by: shade, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/24632

From duke at openjdk.org  Thu Apr 17 09:43:03 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 17 Apr 2025 09:43:03 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
 <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>
Message-ID: <JLHB5d-WJCmaB-TBbZezMeat4BWcpndCN6MqoUoSw_A=.6280b1a9-1cd3-4694-a732-ca2521742f0d@github.com>

On Wed, 16 Apr 2025 19:22:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed asserts.
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717:
> 
>> 715:   desc_len = (int)strlen(_cpu_desc);
>> 716:   snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string);
>> 717:   fprintf(stderr, "_features_string = \"%s\"", _features_string);
> 
> Was this line added by mistake? Looks like a leftover.

@iwanowww  Oooops, yes. Addressed in [https://github.com/openjdk/jdk/pull/24717](url)  together with another forgotten (though not strictly necessary) change. Thanks for catching it!
Could you review that (really short) PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048605624

From adinn at openjdk.org  Thu Apr 17 09:51:04 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 17 Apr 2025 09:51:04 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <JLHB5d-WJCmaB-TBbZezMeat4BWcpndCN6MqoUoSw_A=.6280b1a9-1cd3-4694-a732-ca2521742f0d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
 <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>
 <JLHB5d-WJCmaB-TBbZezMeat4BWcpndCN6MqoUoSw_A=.6280b1a9-1cd3-4694-a732-ca2521742f0d@github.com>
Message-ID: <31MkMkCnISHqrdr-puFzzw2MQB2ka-fIqnDM0ryDqhs=.fd660382-e126-45f1-a007-2b3b4b37a69f@github.com>

On Thu, 17 Apr 2025 09:40:02 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717:
>> 
>>> 715:   desc_len = (int)strlen(_cpu_desc);
>>> 716:   snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string);
>>> 717:   fprintf(stderr, "_features_string = \"%s\"", _features_string);
>> 
>> Was this line added by mistake? Looks like a leftover.
>
> @iwanowww  Oooops, yes. Addressed in [https://github.com/openjdk/jdk/pull/24717](https://github.com/openjdk/jdk/pull/24717) together with another forgotten (though not strictly necessary) change. Thanks for catching it!
> Could you review that (really short) PR?

@ferakocz That link has the right label but leads to the wrong place. It should point [here](https://github.com/openjdk/jdk/pull/24717).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048618862

From adinn at openjdk.org  Thu Apr 17 09:55:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 17 Apr 2025 09:55:59 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11]
In-Reply-To: <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com>
 <c_FTSTF1bcfQIz_lM7QjCoXnJj8BCpxlJE-NYCgg7Qw=.4ca568e8-3af8-40f5-ada2-8244efd8232c@github.com>
Message-ID: <QY6c3mXmdziUhw3in5wEtzSjlx_57E921j_WFzV_K5k=.734dca47-904a-4410-9755-2a68566203cb@github.com>

On Wed, 16 Apr 2025 19:22:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed asserts.
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717:
> 
>> 715:   desc_len = (int)strlen(_cpu_desc);
>> 716:   snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string);
>> 717:   fprintf(stderr, "_features_string = \"%s\"", _features_string);
> 
> Was this line added by mistake? Looks like a leftover.

@iwanowww Thanks for the heads up!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048625305

From tschatzl at openjdk.org  Fri Apr 18 09:33:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Apr 2025 09:33:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v34]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/068d2a37..a3b2386d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=32-33

  Stats: 41 lines in 11 files changed: 1 ins; 11 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Fri Apr 18 10:08:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Apr 2025 10:08:52 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v34]
In-Reply-To: <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@github.com>
Message-ID: <rU1p1eNg-KrtiQPQBBHLvV5IEHQ1GDTEWrPh1FVSPog=.2862e4e2-4fe5-46ff-9e31-46d6d16c04c1@github.com>

On Fri, 18 Apr 2025 09:33:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)

The current use of all filters in the barrier is intentional: there is additional work going on investigating that, and I did not want to anticipate it in this change.

When implementing the current `gen_write_ref_array_post` code measurements showed that the current version is slightly better than your suggestion for most arrays (everything larger than a few elements). I may still decide to use your version for now and re-measure later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2815125500

From dnsimon at openjdk.org  Fri Apr 18 15:26:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 18 Apr 2025 15:26:41 GMT
Subject: RFR: 8355034: [JVMCI] assert(static_cast<int>(_jvmci_data_size) ==
 align_up(compiler->is_jvmci() ? jvmci_data->size() : 0,
 oopSize)) failed: failed: 104 != 16777320
In-Reply-To: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>
References: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>
Message-ID: <BpGtELxlF22Hvq3P8u75Z715AxjuGOkcizqh9QwTNII=.0b9f6b1f-a909-4fd7-a8cf-c2db8547f6b4@github.com>

On Fri, 18 Apr 2025 13:27:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> After [JDK-8343789](https://bugs.openjdk.org/browse/JDK-8343789), the size of a `JVMCINMethodData` object is limited to `uint16_t`. That object embeds the value of `InstalledCode.name` so effectively imposes a limit on the name length. This PR establishes a lower limit on the name value as this name should only be for informative purposes when inspecting compiled code.
> 
> While debugging the problem that exposed the limit, it was confusing that `-XX:+PrintCompilation` did not show the name so this PR builds on [JDK-8336760](https://bugs.openjdk.org/browse/JDK-8336760) to add the name in `PrintCompilation` output for JVMCI "hosted" methods.

src/hotspot/share/code/nmethod.cpp line 115:

> 113: #define CHECKED_CAST(result, T, thing)      \
> 114:   result = static_cast<T>(thing); \
> 115:   guarantee(static_cast<int>(result) == thing, "failed: %d != %d", static_cast<int>(result), thing);

This check is not is a hot path and so afford to be a guarantee. That said, I've no strong objection to leaving it as an assert.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 831:

> 829:             stringStream st;
> 830:             st.print_cr("(hosted JVMCI compilation: %s)", name);
> 831:             CompileTask::print(tty, nm, st.as_string());

@JohnTortugo this may be of interest to you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24753#discussion_r2050763430
PR Review Comment: https://git.openjdk.org/jdk/pull/24753#discussion_r2050766285

From dnsimon at openjdk.org  Fri Apr 18 15:26:40 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 18 Apr 2025 15:26:40 GMT
Subject: RFR: 8355034: [JVMCI] assert(static_cast<int>(_jvmci_data_size) ==
 align_up(compiler->is_jvmci() ? jvmci_data->size() : 0,
 oopSize)) failed: failed: 104 != 16777320
Message-ID: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>

After [JDK-8343789](https://bugs.openjdk.org/browse/JDK-8343789), the size of a `JVMCINMethodData` object is limited to `uint16_t`. That object embeds the value of `InstalledCode.name` so effectively imposes a limit on the name length. This PR establishes a lower limit on the name value as this name should only be for informative purposes when inspecting compiled code.

While debugging the problem that exposed the limit, it was confusing that `-XX:+PrintCompilation` did not show the name so this PR builds on [JDK-8336760](https://bugs.openjdk.org/browse/JDK-8336760) to add the name in `PrintCompilation` output for JVMCI "hosted" methods.

-------------

Commit messages:
 - impose a length limit on InstalledCode.name
 - convert assert to guarantee
 - include the name if non-null when printing "hosted" JVMCI compilations

Changes: https://git.openjdk.org/jdk/pull/24753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24753&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355034
  Stats: 76 lines in 4 files changed: 73 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24753/head:pull/24753

PR: https://git.openjdk.org/jdk/pull/24753

From dnsimon at openjdk.org  Fri Apr 18 15:35:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 18 Apr 2025 15:35:41 GMT
Subject: RFR: 8355034: [JVMCI] assert(static_cast<int>(_jvmci_data_size) ==
 align_up(compiler->is_jvmci() ? jvmci_data->size() : 0,
 oopSize)) failed: failed: 104 != 16777320 [v2]
In-Reply-To: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>
References: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>
Message-ID: <l19ujiGEqxLkD0SCFp8DQKJjmAXNMnI-znO20g6psQM=.5b3833e3-86e1-462d-938c-9b757509b688@github.com>

> After [JDK-8343789](https://bugs.openjdk.org/browse/JDK-8343789), the size of a `JVMCINMethodData` object is limited to `uint16_t`. That object embeds the value of `InstalledCode.name` so effectively imposes a limit on the name length. This PR establishes a lower limit on the name value as this name should only be for informative purposes when inspecting compiled code.
> 
> While debugging the problem that exposed the limit, it was confusing that `-XX:+PrintCompilation` did not show the name so this PR builds on [JDK-8336760](https://bugs.openjdk.org/browse/JDK-8336760) to add the name in `PrintCompilation` output for JVMCI "hosted" methods.

Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  impose a length limit on InstalledCode.name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24753/files
  - new: https://git.openjdk.org/jdk/pull/24753/files/03c10e9c..be003f35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24753&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24753&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24753/head:pull/24753

PR: https://git.openjdk.org/jdk/pull/24753

From never at openjdk.org  Fri Apr 18 16:58:54 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 18 Apr 2025 16:58:54 GMT
Subject: RFR: 8355034: [JVMCI] assert(static_cast<int>(_jvmci_data_size) ==
 align_up(compiler->is_jvmci() ? jvmci_data->size() : 0,
 oopSize)) failed: failed: 104 != 16777320 [v2]
In-Reply-To: <l19ujiGEqxLkD0SCFp8DQKJjmAXNMnI-znO20g6psQM=.5b3833e3-86e1-462d-938c-9b757509b688@github.com>
References: <efmF2JYomiuk177tp1MMIgptmV9ngnkdH_zOIu8wA7w=.e5e6947b-1c40-4867-9ae0-70d8a84a23db@github.com>
 <l19ujiGEqxLkD0SCFp8DQKJjmAXNMnI-znO20g6psQM=.5b3833e3-86e1-462d-938c-9b757509b688@github.com>
Message-ID: <1sdKHhrvskbtNgGENIhGFoHPFCThgnyyAdJXMhnr-3s=.285d63a5-e834-4fee-ae8a-ff1af8039be6@github.com>

On Fri, 18 Apr 2025 15:35:41 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> After [JDK-8343789](https://bugs.openjdk.org/browse/JDK-8343789), the size of a `JVMCINMethodData` object is limited to `uint16_t`. That object embeds the value of `InstalledCode.name` so effectively imposes a limit on the name length. This PR establishes a lower limit on the name value as this name should only be for informative purposes when inspecting compiled code.
>> 
>> While debugging the problem that exposed the limit, it was confusing that `-XX:+PrintCompilation` did not show the name so this PR builds on [JDK-8336760](https://bugs.openjdk.org/browse/JDK-8336760) to add the name in `PrintCompilation` output for JVMCI "hosted" methods.
>
> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   impose a length limit on InstalledCode.name

Looks good to me.

-------------

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24753#pullrequestreview-2779016276