From sspitsyn at openjdk.org  Wed Oct  1 00:01:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Oct 2025 00:01:25 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <pW9wtSPU8bQGqssN648DfvlwFj3yuTZhhYX8oJHHqDs=.05987cbc-8373-4284-bfef-f964999313d9@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <pW9wtSPU8bQGqssN648DfvlwFj3yuTZhhYX8oJHHqDs=.05987cbc-8373-4284-bfef-f964999313d9@github.com>
Message-ID: <kvidccWQsJPicTUkwwOlKJsG9E6FY2Y183M5Ix0sAWA=.79ff5f67-9c36-4044-8013-8eedbc06a12f@github.com>

On Mon, 29 Sep 2025 08:45:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
>> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
>> 
>> However, current implementation changes state and only after this start disabling events.  
>> 
>> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
>> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
>> 
>> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
>> 
>> After this fix the VMDeath callback also can't generate any events. 
>> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
>> 
>> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
>> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
>> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.
>
> Hi Leonid,
> 
> We currently have a shutdown issue where the GC is shut down before the last JVMTI events are sent from the same thread. The problem is that the JVMTI code allocates Java objects, which is problematic given that we've just shut down the GC threads.
> 
> Because of this extra allocation we have added a stop-gap solution that is not what we want long-term, but it fixes some reoccuring issue that was reported. The real solution involves switching the order between shutting down the GC threads and sending the last JVMTI event.
> 
> Take a look at before_exit in java.cpp:
> 
>   // Run before exit and then stop concurrent GC threads
>   Universe::before_exit();
> 
> ... // some unrelated code ...
> 
>   if (JvmtiExport::should_post_thread_life()) {
>     JvmtiExport::post_thread_end(thread);
>   }
> 
>   // Always call even when there are not JVMTI environments yet, since environments
>   // may be attached late and JVMTI must track phases of VM execution
>   JvmtiExport::post_vm_death();
>   JvmtiAgentList::unload_agents();
> 
> 
> The GC team thinks that the thread that shuts down the GC threads should not call code that allocates, so we would like to hoist the JVMTI code to before the code that stops the GC threads
> 
> ... // some unrelated code ...
> 
>   if (JvmtiExport::should_post_thread_life()) {
>     JvmtiExport::post_thread_end(thread);
>   }
> 
>   // Always call even when there are not JVMTI environments yet, since environments
>   // may be attached late and JVMTI must track phases of VM execution
>   JvmtiExport::post_vm_death();
>   JvmtiAgentList::unload_agents();
> 
>   // Run before exit and then stop concurrent GC threads
>   Universe::before_exit();
> 
> 
> There's a JBS entry created for the issue described above:
> https://bugs.openjdk.org/browse/JDK-8367902
> 
> Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR?

@stefank :
> Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR?

@lmesnik :
> The VM Death call back is still valid point to call any java code. So the GC should be active at this point. I quickly check that 'Universe::before_exit()' doesn't post any jvmti events, so it makes sense to call it after vm death.

Stefan, I agree with Leonid that your reordering suggestion is reasonable.

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3354166387

From sspitsyn at openjdk.org  Wed Oct  1 00:15:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Oct 2025 00:15:29 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <gyuymB0UMTeh2hQghiKBZehWkvMCsS60CcHlhynjqUM=.43e86c2a-bf5e-475d-8751-43b7b9abdb45@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
> 
> After this fix the VMDeath callback also can't generate any events. 
> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
> 
> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

It is a nice move to a right direction in fixing this long standing issue, so thank you for attacking it now! It should fix all WRONG_PHASE failures we are constantly observing with our mach5 test runs. We had and fixed a similar issue in the JDWP agent a long time ago, so a similar approach can be used here. Disabling all JVMTI events (except the VM_DEATH) is one part of the solution. Another part is that we should wait for all agent callbacks in progress to complete their work at the VM_DEATH point before the VM_DEATH event is posted. I see it has been already discussed in the PR comments. I'd suggest to consider to handle it here.

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

PR Review: https://git.openjdk.org/jdk/pull/27504#pullrequestreview-3287099388

From fyang at openjdk.org  Wed Oct  1 00:22:33 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 1 Oct 2025 00:22:33 GMT
Subject: RFR: 8367601: Remove held_monitor_count
In-Reply-To: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
Message-ID: <rLDTRfgzK-pnn_QCo9Ijw1cZ2qbwvS6GiLwqXNQLIRY=.85f3cc15-bf03-4cce-9eb1-855de8b3a7fa@github.com>

On Tue, 30 Sep 2025 09:43:51 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
> - `_held_monitor_count`
> - `_parent_held_monitor_count`
> - `_jni_monitor_count`
> 
> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
> They are not present in other platforms.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> `PowerPC` and `RISC-V` has been sanity checked using QEMU.

RISC-V part of the change seems fine to me. My local hs:tier1-hs:tier3 passed with fastdebug build.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3287111055

From iklam at openjdk.org  Wed Oct  1 04:34:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 1 Oct 2025 04:34:49 GMT
Subject: RFR: 8368727: CDS custom loader support causes asserts during
 class unloading
In-Reply-To: <JwyuifKW635et6-qO06h2egWFmpix91ZIlG4ii1s0Hk=.b6e3b656-15dc-48c2-bf23-53b0ad8d1c90@github.com>
References: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
 <XokGbpZnhUhrmpChD9FRSz-nSS8T5DifuzrW53yQIs0=.a3b27bde-9194-4178-8c9e-08238e1c3d47@github.com>
 <JwyuifKW635et6-qO06h2egWFmpix91ZIlG4ii1s0Hk=.b6e3b656-15dc-48c2-bf23-53b0ad8d1c90@github.com>
Message-ID: <ai_JwDkh6Cqj6mKajF8SlY1geCafBgk-pcBk8JoLPfk=.2abff3ee-5c54-409d-b2a4-aada5989fe4c@github.com>

On Mon, 29 Sep 2025 02:26:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionaryShared.cpp line 177:
>> 
>>> 175:   // No longer holding SharedDictionary_lock
>>> 176:   // No need to lock, as <ik> can be held only by a single thread.
>>> 177:   loader_data->add_class(ik);
>> 
>> Are the comments pertaining to the `add_class` call?
>
> Why not just move this to after the successful `load_shared_class` below? It is very hard to see the complete call sequence to when `restore_unshareable_info` gets called, to know that moving it there makes sense.

The comment is about all that could happen to `ik` after the current thread have gotten exclusive ownership of `ik`.  I.e., no other thread will modify the contents of `ik` or store `ik` into a `ClassLoaderData`.

The `loader_data->add_class(ik)` for all other shared classes are done inside `restore_unshareable_info()`, so we should do the same thing in this case. This means the same sequence of actions will happen (e.g.,  `loader_data->add_class(ik)` happens before the the Java mirror is created.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27511#discussion_r2393426301

From stefank at openjdk.org  Wed Oct  1 07:36:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 1 Oct 2025 07:36:49 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
Message-ID: <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>

On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
> 
> Passes tier1 and tier2 (fastdebug).

src/hotspot/share/utilities/growableArray.hpp line 715:

> 713: template <typename E>
> 714: class GrowableArray : public GrowableArrayWithAllocator<E, GrowableArray<E>> {
> 715:   friend class VMStructs;

I was a bit surprised to see that you added a friend declaration. Was this done because you removed the one in the parent class?

I see that vmStructs.cpp has GrowableArray listed:

  nonstatic_field(GrowableArrayBase,           _len,                                          int)                                   \
  nonstatic_field(GrowableArrayBase,           _capacity,                                     int)                                   \
  nonstatic_field(GrowableArray<int>,          _data,                                         int*) 


So, I guess it makes sense to move it here. OTOH, the exposed `_data` field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead?

I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2393707385

From fyang at openjdk.org  Wed Oct  1 07:40:48 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 1 Oct 2025 07:40:48 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v2]
In-Reply-To: <BLJqua7MeNXzfDKk9-rV6FsI8EpsSGKfbc4FtNIqDCE=.3bc7f1a4-fef4-47e1-b17f-148dfc9d6e69@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <Sw_0zS9Hkrz5DwFok9DUxZUvwWJ-_by-DFRGMC_wSYc=.574b7768-e326-4c11-99b3-939c606a1d50@github.com>
 <BLJqua7MeNXzfDKk9-rV6FsI8EpsSGKfbc4FtNIqDCE=.3bc7f1a4-fef4-47e1-b17f-148dfc9d6e69@github.com>
Message-ID: <slWV8thhfFSPk1IoJC0ECJTYc6MnvoNKEwrxu_8uulo=.69c28b08-d95c-4ee0-92fc-3253697998aa@github.com>

On Tue, 30 Sep 2025 09:39:35 GMT, Hamlin Li <mli at openjdk.org> wrote:

> I'm also considering if we should remove the column ext_xx in RV_EXT_FEATURE_FLAGS, and the similar column in RV_NON_EXT_FEATURE_FLAGS in this pr, as it should be able to be generated from the pretty string. How do you think about it?
> 
> The different opinions could be:
> 
> * for RV_EXT_FEATURE_FLAGS, should we take for example `i` or `I` as pretty string?

The current `_features_string` on linux-riscv64 looks like:

rv64 rvi rvm rva rvf rvd rvc rvv zicboz zba zbb zbs zfa zfh zfhmin zvfh zicond


We append a `rv` prefix for `i`, `m`, `a`, `f`, `d`, `c` and `v`.

> * for RV_NON_EXT_FEATURE_FLAGS, should we use `mvendorid` or `VendorId` as pretty string?
>   let me know how do you think about it.

Seems not necessary to have a pretty string for non-extension flags. Is it used anywhere?

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3355129759

From mli at openjdk.org  Wed Oct  1 08:25:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 08:25:03 GMT
Subject: RFR: 8368893: RISC-V: crash after JDK-8352673 on fastdebug version
In-Reply-To: <b6LK4Y-sR1qHO8UeYT4jXGLi3h6Fe3pMQN_hpFOWF2o=.b11afdbd-7bc0-4ba6-88f8-e1950c55df56@github.com>
References: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com>
 <b6LK4Y-sR1qHO8UeYT4jXGLi3h6Fe3pMQN_hpFOWF2o=.b11afdbd-7bc0-4ba6-88f8-e1950c55df56@github.com>
Message-ID: <upadEGLWFEvDn_HsjOh7hs6DGQUCArHa5KkIUkHpYeI=.6791a6cb-e19e-4582-8fdd-31e1451a10a6@github.com>

On Tue, 30 Sep 2025 02:21:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi,
>> Can you review this patch?
>> 
>> check https://github.com/openjdk/jdk/pull/24182.
>> 
>> This patch 
>> * fix the crash, 
>> * do some simple code cleanup, I don't think this piece of code is necessary:
>> 
>>     if (!ext_V.enabled() && FLAG_IS_DEFAULT(UseRVV)) {
>>       warning("RVV is not supported on this CPU");
>>       FLAG_SET_DEFAULT(UseRVV, false);
>> 
>> 
>> ## Crash
>> crash when linux version < 6.8.5, with following command:
>> *  $ java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version
>> 
>> stack:
>> 
>> Stack: [0x00007f5d4d05a000,0x00007f5d4d25a000], sp=0x00007f5d4d255e80, free space=2031k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V [libjvm.so+0x1661202] VM_Version::cpu_vector_length()+0x42 (vm_version_linux_riscv.cpp:103)
>> V [libjvm.so+0x1662b1c] VM_Version::common_initialize()+0x25a (vm_version_riscv.cpp:202)
>> V [libjvm.so+0x1662e0a] VM_Version::initialize()+0xc (vm_version_riscv.cpp:61)
>> V [libjvm.so+0x1660cca] VM_Version_init()+0x46 (vm_version.cpp:31)
>> V [libjvm.so+0xb6c538] init_globals()+0x68 (init.cpp:127)
>> V [libjvm.so+0x158daea] Threads::create_vm(JavaVMInitArgs*, bool*)+0x370 (threads.cpp:576)
>> V [libjvm.so+0xcd087c] JNI_CreateJavaVM+0x6e (jni.cpp:3587)
>> C [libjli.so+0x612c] JavaMain+0x7a (java.c:1499)
>> C [libjli.so+0x8eee] ThreadJavaMain+0xc (java_md.c:649)
>> C [libc.so.6+0x67552]
>> C [libc.so.6+0xb3b86]
>> 
>> 
>> ## Test
>> 
>> 
>> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep -e UseRVV -e MaxVectorSize
>>      intx MaxVectorSize                            = 0                                      {C2 product} {default}
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> 
>> 
>> 
>> 
>> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep -e UseRVV -e MaxVectorSize
>>      intx MaxVectorSize                            = 0                                      {C2 product} {default}
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> 
>> 
>> 
>> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep -e UseRVV -e MaxVectorSize
>>      intx MaxVectorSize                            = 32                                     {C2 product} {default}
>>      bool UseRVV                                   = true                              {ARCH diagnostic} {command lin...
>
> Thanks!

Thank you @RealFYang @DingliZhang for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/27557#issuecomment-3355257774

From mli at openjdk.org  Wed Oct  1 08:25:04 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 08:25:04 GMT
Subject: Integrated: 8368893: RISC-V: crash after JDK-8352673 on fastdebug
 version
In-Reply-To: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com>
References: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com>
Message-ID: <8MtbC37BsrudhbWw8-ErnRuKsRgC-T5ZhWDIRI3zot4=.1a4c8670-fee6-415d-b544-602f878fb304@github.com>

On Mon, 29 Sep 2025 20:24:25 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch?
> 
> check https://github.com/openjdk/jdk/pull/24182.
> 
> This patch 
> * fix the crash, 
> * do some simple code cleanup, I don't think this piece of code is necessary:
> 
>     if (!ext_V.enabled() && FLAG_IS_DEFAULT(UseRVV)) {
>       warning("RVV is not supported on this CPU");
>       FLAG_SET_DEFAULT(UseRVV, false);
> 
> 
> ## Crash
> crash when linux version < 6.8.5, with following command:
> *  $ java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version
> 
> stack:
> 
> Stack: [0x00007f5d4d05a000,0x00007f5d4d25a000], sp=0x00007f5d4d255e80, free space=2031k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x1661202] VM_Version::cpu_vector_length()+0x42 (vm_version_linux_riscv.cpp:103)
> V [libjvm.so+0x1662b1c] VM_Version::common_initialize()+0x25a (vm_version_riscv.cpp:202)
> V [libjvm.so+0x1662e0a] VM_Version::initialize()+0xc (vm_version_riscv.cpp:61)
> V [libjvm.so+0x1660cca] VM_Version_init()+0x46 (vm_version.cpp:31)
> V [libjvm.so+0xb6c538] init_globals()+0x68 (init.cpp:127)
> V [libjvm.so+0x158daea] Threads::create_vm(JavaVMInitArgs*, bool*)+0x370 (threads.cpp:576)
> V [libjvm.so+0xcd087c] JNI_CreateJavaVM+0x6e (jni.cpp:3587)
> C [libjli.so+0x612c] JavaMain+0x7a (java.c:1499)
> C [libjli.so+0x8eee] ThreadJavaMain+0xc (java_md.c:649)
> C [libc.so.6+0x67552]
> C [libc.so.6+0xb3b86]
> 
> 
> ## Test
> 
> 
> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep -e UseRVV -e MaxVectorSize
>      intx MaxVectorSize                            = 0                                      {C2 product} {default}
>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
> 
> 
> 
> 
> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep -e UseRVV -e MaxVectorSize
>      intx MaxVectorSize                            = 0                                      {C2 product} {default}
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> 
> 
> 
> java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep -e UseRVV -e MaxVectorSize
>      intx MaxVectorSize                            = 32                                     {C2 product} {default}
>      bool UseRVV                                   = true                              {ARCH diagnostic} {command line}
> 
> 
> 
> Thanks

This pull request has now been integrated.

Changeset: f49849a5
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f49849a5ed4e9383e39e69ce76bb8ea74fb443f9
Stats:     8 lines in 2 files changed: 0 ins; 6 del; 2 mod

8368893: RISC-V: crash after JDK-8352673 on fastdebug version

Reviewed-by: fyang, dzhang

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

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

From bmaillard at openjdk.org  Wed Oct  1 08:25:10 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 1 Oct 2025 08:25:10 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
Message-ID: <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>

> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
> 
> ## Usage
> 
> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
> that we compile `square` with C2.
> 
> class Square {
>     static int square(int a) {
>         return a * a;
>     }
> 
>     public static void main(String[] args) {
>         square(9);
>     }
> }
> 
> 
> We would like to inspect the node that contains the value returned in this method.
> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
> 
> ```c++
> void Compile::return_values(JVMState* jvms) {
>   GraphKit kit(jvms);
>   Node* ret = new ReturnNode(TypeFunc::Parms,
>                              kit.control(),
>                              kit.i_o(),
>                              kit.reset_memory(),
>                              kit.frameptr(),
>                              kit.returnadr());
>   // Add zero or 1 return values
>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
> 
>   
>   Node* return_value;
>   if (ret_size > 0) {
>     kit.inc_sp(-ret_size);  // pop the return value(s)
>     kit.sync_jvms();
>     return_value = kit.argument(0);
>     ret->add_req(return_value);
> 
>     // <-------------------- Simply insert this
>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>   }
>   
>   // bind it to root
>   root()->add_req(ret);
>   record_for_igvn(ret);
>   initial_gvn()->transform(ret);
> }
> 
> 
> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
> and we get the following output:
> 
> 
> return:
> int 81
> 
> 
> This case is of course trivial, but more useful examples are shown later.
> 
> ## Implementation
> 
> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
> 
> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor.
> 
> The first argument to the runtime printing method is the printing message, a static string encoded as a `...

Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/compile.cpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26475/files
  - new: https://git.openjdk.org/jdk/pull/26475/files/6fd07ada..a4c3821f

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

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

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

From bmaillard at openjdk.org  Wed Oct  1 08:25:12 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 1 Oct 2025 08:25:12 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v11]
In-Reply-To: <JbF8B5-8zuJA_PuGTbX6ae0Iu3nFu9e8bjj_dMVixdc=.16090783-d328-4177-8cf5-e3802fae2e49@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <YHXfwqAq7lsyDgiR0q4_EgbnaHwoew4EBxpmxhVXbf0=.20e86af3-3021-45be-bae4-1d9f1073e0b1@github.com>
 <JbF8B5-8zuJA_PuGTbX6ae0Iu3nFu9e8bjj_dMVixdc=.16090783-d328-4177-8cf5-e3802fae2e49@github.com>
Message-ID: <wWX9NlzeeBxz_9JQxhrUnDdSDXb0h6yic7ZAMBR3Xnw=.eb3b90bd-55de-4d79-ab57-7f8a27d7a293@github.com>

On Tue, 30 Sep 2025 07:45:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove implicit null check
>
> src/hotspot/share/opto/compile.cpp line 5444:
> 
>> 5442:   Node* str_node = gvn->transform(new ConPNode(TypeRawPtr::make(((address) str))));
>> 5443:   const TypeFunc* type = OptoRuntime::debug_print_Type(parm0, parm1, parm2, parm3, parm4, parm5, parm6);
>> 5444:   Node *call = new CallLeafNode(type, call_addr, "debug_print", TypeRawPtr::BOTTOM);
> 
> Suggestion:
> 
>   Node* call = new CallLeafNode(type, call_addr, "debug_print", TypeRawPtr::BOTTOM);

Good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2393810107

From mli at openjdk.org  Wed Oct  1 08:35:11 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 08:35:11 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v2]
In-Reply-To: <slWV8thhfFSPk1IoJC0ECJTYc6MnvoNKEwrxu_8uulo=.69c28b08-d95c-4ee0-92fc-3253697998aa@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <Sw_0zS9Hkrz5DwFok9DUxZUvwWJ-_by-DFRGMC_wSYc=.574b7768-e326-4c11-99b3-939c606a1d50@github.com>
 <BLJqua7MeNXzfDKk9-rV6FsI8EpsSGKfbc4FtNIqDCE=.3bc7f1a4-fef4-47e1-b17f-148dfc9d6e69@github.com>
 <slWV8thhfFSPk1IoJC0ECJTYc6MnvoNKEwrxu_8uulo=.69c28b08-d95c-4ee0-92fc-3253697998aa@github.com>
Message-ID: <xjArEiOwLCoLi8wLeJk3z2v2yDVkG5cGibuMXlsfzTY=.768baaca-8691-46d3-8c07-c567fa69b162@github.com>

On Wed, 1 Oct 2025 07:37:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

> > * for RV_EXT_FEATURE_FLAGS, should we take for example `i` or `I` as pretty string?
> 
> The current `_features_string` on linux-riscv64 looks like:
> 
> ```
> rv64 rvi rvm rva rvf rvd rvc rvv zicboz zba zbb zbs zfa zfh zfhmin zvfh zicond
> ```
> 
> We append a `rv` prefix for `i`, `m`, `a`, `f`, `d`, `c` and `v`.

OK, I'll keep the pretty string as lower cases.

> 
> > * for RV_NON_EXT_FEATURE_FLAGS, should we use `mvendorid` or `VendorId` as pretty string?
> >   let me know how do you think about it.
> 
> Seems not necessary to have a pretty string for non-extension flags. Is it used anywhere?

Yes, it's printed out by `log_debug(os, cpu)`, e.g.

[0.070s][debug][os,cpu] Enabled RV64 feature "VendorId" (1743)
[0.070s][debug][os,cpu] Enabled RV64 feature "ArchId" (0)
[0.070s][debug][os,cpu] Enabled RV64 feature "ImpId" (0)
[0.070s][debug][os,cpu] Enabled RV64 feature "SATP" (48)
[0.070s][debug][os,cpu] Enabled RV64 feature "UnalignedScalar" (3)
[0.070s][debug][os,cpu] Enabled RV64 feature "ZicbozBlockSize" (64)

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3355294857

From jsjolen at openjdk.org  Wed Oct  1 08:58:17 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 1 Oct 2025 08:58:17 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v10]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/operands-again' into operands-again
 - Use int to avoid cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/5a42b0df..55f6d5bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=08-09

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From mli at openjdk.org  Wed Oct  1 10:26:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 10:26:54 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v3]
In-Reply-To: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
Message-ID: <Htfw-eEmIr12EOsmihmHSdNHh6auZuXeLkL5Pl5XXRY=.774a5b4d-7c58-408b-a382-068c6e4a56c2@github.com>

> Hi,
> Can you help to review the patch?
> 
> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
> 
> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
> 
> Thanks!

Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - merge master
 - Merge branch 'openjdk:master' into master
 - remove NAME
 - merge master
 - Merge branch 'openjdk:master' into master
 - initial commit
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5a2700f2...f0701a7d

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

Changes: https://git.openjdk.org/jdk/pull/27562/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27562&range=02
  Stats: 193 lines in 6 files changed: 42 ins; 46 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/27562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27562/head:pull/27562

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

From mli at openjdk.org  Wed Oct  1 10:34:28 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 10:34:28 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
Message-ID: <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>

> Hi,
> Can you help to review the patch?
> 
> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
> 
> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
> 
> Thanks!

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  order RV_NON_EXT_FEATURE_FLAGS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27562/files
  - new: https://git.openjdk.org/jdk/pull/27562/files/f0701a7d..92d1bb5e

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

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

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

From mli at openjdk.org  Wed Oct  1 10:34:29 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 1 Oct 2025 10:34:29 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v2]
In-Reply-To: <slWV8thhfFSPk1IoJC0ECJTYc6MnvoNKEwrxu_8uulo=.69c28b08-d95c-4ee0-92fc-3253697998aa@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <Sw_0zS9Hkrz5DwFok9DUxZUvwWJ-_by-DFRGMC_wSYc=.574b7768-e326-4c11-99b3-939c606a1d50@github.com>
 <BLJqua7MeNXzfDKk9-rV6FsI8EpsSGKfbc4FtNIqDCE=.3bc7f1a4-fef4-47e1-b17f-148dfc9d6e69@github.com>
 <slWV8thhfFSPk1IoJC0ECJTYc6MnvoNKEwrxu_8uulo=.69c28b08-d95c-4ee0-92fc-3253697998aa@github.com>
Message-ID: <FRHoZkCkVPmrZoIOLIoVLx8mIfl0hyeMMsVryrmGG9A=.8db5c0d0-c0bd-48ab-a7e1-0bec82ef4c76@github.com>

On Wed, 1 Oct 2025 07:37:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I'm also considering if we should remove the column ext_xx in RV_EXT_FEATURE_FLAGS, and the similar column in RV_NON_EXT_FEATURE_FLAGS in this pr, as it should be able to be generated from the pretty string. How do you think about it?
>> 
>> The different opinions could be:
>> * for RV_EXT_FEATURE_FLAGS, should we take for example `i` or `I` as pretty string?
>> * for RV_NON_EXT_FEATURE_FLAGS, should we use `mvendorid` or `VendorId` as pretty string?
>> let me know how do you think about it.
>
>> I'm also considering if we should remove the column ext_xx in RV_EXT_FEATURE_FLAGS, and the similar column in RV_NON_EXT_FEATURE_FLAGS in this pr, as it should be able to be generated from the pretty string. How do you think about it?
>> 
>> The different opinions could be:
>> 
>> * for RV_EXT_FEATURE_FLAGS, should we take for example `i` or `I` as pretty string?
> 
> The current `_features_string` on linux-riscv64 looks like:
> 
> rv64 rvi rvm rva rvf rvd rvc rvv zicboz zba zbb zbs zfa zfh zfhmin zvfh zicond
> 
> 
> We append a `rv` prefix for `i`, `m`, `a`, `f`, `d`, `c` and `v`.
> 
>> * for RV_NON_EXT_FEATURE_FLAGS, should we use `mvendorid` or `VendorId` as pretty string?
>>   let me know how do you think about it.
> 
> Seems not necessary to have a pretty string for non-extension flags. Is it used anywhere?

@RealFYang Take your time, no hurry. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3355709993

From dholmes at openjdk.org  Wed Oct  1 11:23:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 11:23:00 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
 <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
Message-ID: <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>

On Tue, 30 Sep 2025 15:38:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Right now I am not sure if CSR is needed. The new behaviour doesn't require specification changes.

Significant behavioural changes also require a CSR request - not just changes to specifications.

>> src/hotspot/share/prims/jvmtiEventController.cpp line 1060:
>> 
>>> 1058: void
>>> 1059: JvmtiEventControllerPrivate::vm_death() {
>>> 1060:   _execution_finished = true;
>> 
>> Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic<T>`). You are still racing with others threads but this would at least attempt to minimise the window.
>
> I forgot to put this in description and  mentioned the first comment. 
> The access to variable is protected with JvmtiThreadState_lock. 
> Am I understand correctly, that it is enough to correctly synchronize it?

Yes - if all accesses are done under the lock that is fine. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3355863717
PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2394227874

From alanb at openjdk.org  Wed Oct  1 12:39:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Oct 2025 12:39:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
Message-ID: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>

On Tue, 30 Sep 2025 11:23:13 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?

I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 

> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?

"genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.

I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.

One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3356108097

From fbredberg at openjdk.org  Wed Oct  1 13:35:52 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 1 Oct 2025 13:35:52 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
Message-ID: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>

> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
> - `_held_monitor_count`
> - `_parent_held_monitor_count`
> - `_jni_monitor_count`
> 
> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
> They are not present in other platforms.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> `PowerPC` and `RISC-V` has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27570/files
  - new: https://git.openjdk.org/jdk/pull/27570/files/f05981b1..a3f09e85

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

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

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

From fbredberg at openjdk.org  Wed Oct  1 13:39:56 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 1 Oct 2025 13:39:56 GMT
Subject: RFR: 8367601: Remove held_monitor_count
In-Reply-To: <kCR8a_Su7gfjqmdjNFOn_9UmgeGSgBfJ7vtX5zyMBug=.25335d05-e67c-41d9-b5cd-6d16f84f210f@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <kCR8a_Su7gfjqmdjNFOn_9UmgeGSgBfJ7vtX5zyMBug=.25335d05-e67c-41d9-b5cd-6d16f84f210f@github.com>
Message-ID: <TlJjhErtgSvR-K1FOz4P1N2MtUsU4E-BlBLs1qcY3hA=.362e8d50-dc4e-400c-a434-c9e27bd403ea@github.com>

On Tue, 30 Sep 2025 13:32:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
>> - `_held_monitor_count`
>> - `_parent_held_monitor_count`
>> - `_jni_monitor_count`
>> 
>> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
>> They are not present in other platforms.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> `PowerPC` and `RISC-V` has been sanity checked using QEMU.
>
> Looks correct (PPC64 and shared code changes) and tier1 has passed. Would be nice to clean up unused temp registers
> 
> diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
> index 0bcc24a23bf..9fe7e1f22ff 100644
> --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
> +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
> @@ -1639,7 +1639,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj,
>    assert_different_registers(reg_cont_obj, reg_flags);
>    Register zero = R8_ARG6;
>    Register tmp2 = R9_ARG7;
> -  Register tmp3 = R10_ARG8;
>  
>    DEBUG_ONLY(__ block_comment("fill {"));
>  #ifdef ASSERT
> @@ -1678,7 +1677,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj,
>  static void continuation_enter_cleanup(MacroAssembler* masm) {
>    Register tmp1 = R8_ARG6;
>    Register tmp2 = R9_ARG7;
> -  Register tmp3 = R10_ARG8;
>  
>  #ifdef ASSERT
>    __ block_comment("clean {");
> @@ -1689,8 +1687,8 @@ static void continuation_enter_cleanup(MacroAssembler* masm) {
>  
>    __ ld_ptr(tmp1, ContinuationEntry::parent_cont_fastpath_offset(), R1_SP);
>    __ st_ptr(tmp1, JavaThread::cont_fastpath_offset(), R16_thread);
> -  __ ld_ptr(tmp3, ContinuationEntry::parent_offset(), R1_SP);
> -  __ st_ptr(tmp3, JavaThread::cont_entry_offset(), R16_thread);
> +  __ ld_ptr(tmp2, ContinuationEntry::parent_offset(), R1_SP);
> +  __ st_ptr(tmp2, JavaThread::cont_entry_offset(), R16_thread);
>    DEBUG_ONLY(__ block_comment("} clean"));
>  }
>  
> 
> Thanks for doing it for all platforms!

@TheRealMDoerr
> Would be nice to clean up unused temp registers

Fixed those.

> Thanks for doing it for all platforms!

The same ways as eating different types of food enriches your life, so does programming for different CPUs. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356372605

From fbredberg at openjdk.org  Wed Oct  1 13:40:00 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 1 Oct 2025 13:40:00 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <AWHRLHnr8XKdHE_IIUgSaVT1LQDc_zyNWDobFFC8eU8=.a29b86a8-3b19-4644-9b9a-db127c54e4d5@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <AWHRLHnr8XKdHE_IIUgSaVT1LQDc_zyNWDobFFC8eU8=.a29b86a8-3b19-4644-9b9a-db127c54e4d5@github.com>
Message-ID: <nHGpswdjvwytY1Sqpdj2q_gzZgIej_PJ4mRpCe47UDs=.f133d44b-6946-428c-a407-0ab68a86629d@github.com>

On Tue, 30 Sep 2025 15:51:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1742:
> 
>> 1740:     log_develop_debug(continuations)("PINNED due to critical section");
>> 1741:     verify_continuation(cont.continuation());
>> 1742:     freeze_result res = entry->is_pinned() ? freeze_pinned_cs : freeze_pinned_monitor;
> 
> We can remove this and always return freeze_pinned_cs. We should remove freeze_pinned_monitor (there is a matching definition in Continuation.java).

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27570#discussion_r2394622676

From fbredberg at openjdk.org  Wed Oct  1 14:13:35 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 1 Oct 2025 14:13:35 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
 <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
Message-ID: <FGvD0ybOROd2Nnb-0ZrZcsDNDDj0NJtFlqtYWkcnhwc=.c4d2b4de-327d-423f-9ef6-2247a0787447@github.com>

On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> I guess you want to update the Copyright headers eventually.

@TheRealMDoerr
> I guess you want to update the Copyright headers eventually.

Think I updated all the years to 2025.
`grep -i 'copyright' $(git diff --name-only master) | grep -i oracle`

Did you see something I missed?

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

PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356537891

From mdoerr at openjdk.org  Wed Oct  1 14:04:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Oct 2025 14:04:52 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
>> - `_held_monitor_count`
>> - `_parent_held_monitor_count`
>> - `_jni_monitor_count`
>> 
>> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
>> They are not present in other platforms.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> `PowerPC` and `RISC-V` has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

PPC64 and shared code changes look good. Thanks!

I guess you want to update the Copyright headers eventually.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3289324176
PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356501843

From mdoerr at openjdk.org  Wed Oct  1 14:20:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Oct 2025 14:20:13 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
 <U26BubDrKfAsBpEEZb_q9udsU5_IhZjPBcZSIMzxbeY=.709687ee-40b1-4c32-883e-20aba2bca325@github.com>
Message-ID: <2HZuTvrbG5DED7c-r-MBu-itrFiIzJiy4B2WCjXxdiw=.cb10434a-3390-4c48-b27f-ad0ac7e6092f@github.com>

On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> I guess you want to update the Copyright headers eventually.

> @TheRealMDoerr
> 
> > I guess you want to update the Copyright headers eventually.
> 
> Think I updated all the years to 2025. `grep -i 'copyright' $(git diff --name-only master) | grep -i oracle`
> 
> Did you see something I missed?

I thought I had seen 2024 somewhere. But, I can't find it again. I guess I had looked at the wrong file. Your Copyright updates look fine. Sorry.

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

PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356572661

From fandreuzzi at openjdk.org  Wed Oct  1 14:26:12 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 1 Oct 2025 14:26:12 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
 <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>
Message-ID: <i2i6V5rA8u4u-lE1V4apbc2Qccjb9rBIhFXKLH_ObZ0=.ba72940b-10d4-4106-af3c-a4c40277b3d6@github.com>

On Wed, 1 Oct 2025 07:34:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Was this done because you removed the one in the parent class?

Yeah that's the reasoning.

> the exposed _data field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead?

Actually I'm a bit confused. What you suggest _should not_ work, but it compiles happily. Friendship is not inherited, so we should not be able to access `GrowableArray::_data` if we move `friend class VMStructs` to `GrowableArrayView`.

I thought maybe that was a quirk of `offsetof`, but that does not seem to be the case:

#include <cstddef>

class X {
 protected:
  int field;
};

class Y : public X {};

class Z {
  friend X;

  void doStuff() {
    Y y;
    // both these are illegal
    // int foo = y.field;
    // int foo = offsetof(Y, field);
  }
};

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2394806258

From fandreuzzi at openjdk.org  Wed Oct  1 14:45:57 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 1 Oct 2025 14:45:57 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
 <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>
Message-ID: <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com>

On Wed, 1 Oct 2025 07:34:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Was this done because you removed the one in the parent class?

Yeah that's the reasoning.

> I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray.

Given that `friend` _should not be_ inherited, I'd expect the `friend` declaration on the exact class which we use in `vmStructs*.cpp`. However, I'm curious about why what you suggest compiles. Moving `friend class VMStructs` from `GrowableArray` to `GrowableArrayView` should not allow us to access `_data` via `GrowableArray<int>`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2394868333

From lmesnik at openjdk.org  Wed Oct  1 15:55:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 1 Oct 2025 15:55:04 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
 <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
 <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>
Message-ID: <SaNt2rD-HOwBDv-Mow5b45a2FmQwXvGQSgBHYLk4EXk=.48adb83b-056e-4b41-805d-a82f65120d64@github.com>

On Wed, 1 Oct 2025 11:20:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Right now I am not sure if CSR is needed. The new behaviour doesn't require specification changes.
> 
> Significant behavioural changes also require a CSR request - not just changes to specifications.

@sspitsyn, @dholmes-ora Thank you for feedback.
Let me implement completed solution that post the VMDeath as a last event and wait for completion of current events before changing phase to dead. 

In this case the code inside any callback can never seen phase dead. The VMDeath is the last posted event. The events happened while VM Death is processed are not posted. No events can be executed concurrently with VMDeath event. 

And I'll prepare CSR for this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3357058759

From pchilanomate at openjdk.org  Wed Oct  1 16:10:30 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 1 Oct 2025 16:10:30 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <xVyb8ebr75-EzPC2-3XwG2xDfZiT5Z8MB6eQFNI6MMg=.1df36ad6-bc31-4263-af05-d69e30fcb38b@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
>> - `_held_monitor_count`
>> - `_parent_held_monitor_count`
>> - `_jni_monitor_count`
>> 
>> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
>> They are not present in other platforms.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> `PowerPC` and `RISC-V` has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

Looks good to me, thanks!

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3289970713

From aph at openjdk.org  Wed Oct  1 16:18:15 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 1 Oct 2025 16:18:15 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v13]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <Hv5WFOMU3WtdZrbLBnPDWI2TrVdDuQneE7Ig23U5YCM=.4b28c9d6-d8c5-40da-87a7-784a47207bf2@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Refactor, fix a couple of bugs introduced during review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/20855d98..6a7faf21

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

  Stats: 20 lines in 3 files changed: 13 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

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

From kvn at openjdk.org  Wed Oct  1 18:53:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Oct 2025 18:53:42 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
Message-ID: <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>

On Wed, 1 Oct 2025 08:25:10 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
>> 
>> ## Usage
>> 
>> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
>> that we compile `square` with C2.
>> 
>> class Square {
>>     static int square(int a) {
>>         return a * a;
>>     }
>> 
>>     public static void main(String[] args) {
>>         square(9);
>>     }
>> }
>> 
>> 
>> We would like to inspect the node that contains the value returned in this method.
>> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
>> 
>> ```c++
>> void Compile::return_values(JVMState* jvms) {
>>   GraphKit kit(jvms);
>>   Node* ret = new ReturnNode(TypeFunc::Parms,
>>                              kit.control(),
>>                              kit.i_o(),
>>                              kit.reset_memory(),
>>                              kit.frameptr(),
>>                              kit.returnadr());
>>   // Add zero or 1 return values
>>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
>> 
>>   
>>   Node* return_value;
>>   if (ret_size > 0) {
>>     kit.inc_sp(-ret_size);  // pop the return value(s)
>>     kit.sync_jvms();
>>     return_value = kit.argument(0);
>>     ret->add_req(return_value);
>> 
>>     // <-------------------- Simply insert this
>>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>>   }
>>   
>>   // bind it to root
>>   root()->add_req(ret);
>>   record_for_igvn(ret);
>>   initial_gvn()->transform(ret);
>> }
>> 
>> 
>> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
>> and we get the following output:
>> 
>> 
>> return:
>> int 81
>> 
>> 
>> This case is of course trivial, but more useful examples are shown later.
>> 
>> ## Implementation
>> 
>> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
>> 
>> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ...
>
> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/opto/compile.cpp
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

One comment

src/hotspot/share/opto/compile.cpp line 5387:

> 5385:       if (in->is_CFG()) {
> 5386:         if (in->is_Multi()) {
> 5387:           candidates.push(in->as_Multi()->proj_out(TypeFunc::Control));

Why you collect only one control output edge? IfNode has two. May be add comment if it is intentional.

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

PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3138451321
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2395524182

From kvn at openjdk.org  Wed Oct  1 18:53:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Oct 2025 18:53:44 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v3]
In-Reply-To: <TGWMZt_BSwp-bAUDw2SFnkD2UGEmSSBb8VJxHIe8M38=.9989877c-4e1f-4f79-acec-6f6a8441e6b2@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <0nft1dMAUi46bZtswXOlPxi_pt6v_GFq7HrcuHE4_UU=.c9532a17-3be8-42a3-801c-19ce3825747b@github.com>
 <G0BuBtDQ3V4vue9zmCEAZEQhRwVYh26WewNPZo3dfh0=.862ffb30-de5d-4cad-8d01-e8f33199584a@github.com>
 <TGWMZt_BSwp-bAUDw2SFnkD2UGEmSSBb8VJxHIe8M38=.9989877c-4e1f-4f79-acec-6f6a8441e6b2@github.com>
Message-ID: <eFtfmt7Hqgx93AVDAEhIZj8zSnnTXnwnAxAXLhRdYaY=.ed479350-1af7-4f57-bdbc-c666c0f2db40@github.com>

On Wed, 20 Aug 2025 21:24:46 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 5411:
>> 
>>> 5409: }
>>> 5410: 
>>> 5411: Node* Compile::make_debug_print_call(const char* str, address call_addr, PhaseGVN* gvn,
>> 
>> I think it should be in graphKit.cpp similar to `GraphKit::make_runtime_call()`
>
> This was the case in the first iteration of the implementation, but this meant that it could only be used during parsing, and not in subsequent phases. It was actually requested to be moved out of `GraphKit`, and a large chunk of the logic is about doing the wiring of the call node without depending on the `SafePointNode` available in `GraphKit`.
> 
> The three examples in the _More Examples_ section highlight use cases where `GraphKit` is not available. Maybe I should have started with one of these instead of the `return_values` example.

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2395530119

From iveresov at openjdk.org  Wed Oct  1 19:10:39 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 1 Oct 2025 19:10:39 GMT
Subject: RFR: 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java
 assert(can_add()) failed: Cannot add TrainingData objects
Message-ID: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>

That's a bit of a bug trail from [JDK-8366948](https://bugs.openjdk.org/browse/JDK-8366948). We need to check if the TD snapshot has happened before attempting to modify the data.

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

Commit messages:
 - Check for snapshot

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

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

From kvn at openjdk.org  Wed Oct  1 19:30:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Oct 2025 19:30:00 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
Message-ID: <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>

On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974  the fill intrinsics used by default.
>> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711
>> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859
>> while for 'bad' case these metrics are
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785
>> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659
>> 
>> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic.
>> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled
>> -- | -- | -- | -- | --
>> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03
>> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41
>> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09
>> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29
>> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10
>> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30
>> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32
>> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03
>> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20
>> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58
>> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07
>> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88
>> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91
>> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92
>> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98
>> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98
>> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00
>> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00
>> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00
>> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00
>> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00
>> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00
>> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00
>> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00
>> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75
>> ArraysFill.testShortFill | 31 | 1...
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5920:

> 5918:         if (EnableX86ECoreOpts) {
> 5919:             // align 'big' arrays to cache lines to minimize split_stores
> 5920:             cmpptr(count, 96 << shift);

What is `96?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:

> 6012:   BIND(L_fill_4_bytes);
> 6013:   subptr(count, 1 << shift);
> 6014:   jccb(Assembler::greaterEqual, L_fill_4_bytes_loop);

I don't think it works correctly because you can come here from lines 5998-5999 where ` count` become negative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395614277
PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395657100

From heidinga at openjdk.org  Wed Oct  1 19:44:40 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 1 Oct 2025 19:44:40 GMT
Subject: RFR: 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java
 assert(can_add()) failed: Cannot add TrainingData objects
In-Reply-To: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
References: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
Message-ID: <r6IOrgIRxYvhrOREYyY12eP4nc-PyDDOq0Mi3GIA3Qc=.40d52eef-b158-4c44-ad01-e73e7d86712c@github.com>

On Wed, 1 Oct 2025 19:04:37 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> That's a bit of a bug trail from [JDK-8366948](https://bugs.openjdk.org/browse/JDK-8366948). We need to check if the TD snapshot has happened before attempting to modify the data.

lgtm

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/jdk/pull/27593#pullrequestreview-3290826341

From vaivanov at openjdk.org  Wed Oct  1 19:47:34 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 1 Oct 2025 19:47:34 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
Message-ID: <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>

On Wed, 1 Oct 2025 19:12:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5920:
> 
>> 5918:         if (EnableX86ECoreOpts) {
>> 5919:             // align 'big' arrays to cache lines to minimize split_stores
>> 5920:             cmpptr(count, 96 << shift);
> 
> What is `96?

Two trends identified for buffer filling:
 - filling up to cache line size by 4 bytes reduce performance;
 - operate by cache line size improve performance.
According to experiments on Xeon 6740E the 96 is good compromise. For small arrays it is better to ignore split_store and do filling by bigger elements.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:
> 
>> 6012:   BIND(L_fill_4_bytes);
>> 6013:   subptr(count, 1 << shift);
>> 6014:   jccb(Assembler::greaterEqual, L_fill_4_bytes_loop);
> 
> I don't think it works correctly because you can come here from lines 5998-5999 where ` count` become negative.

testing for tier1, tier2 and tier3 were OK. Will review this part one more time.
Do you have test scenario that may reproduce this issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395693046
PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395701015

From iklam at openjdk.org  Wed Oct  1 20:09:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 1 Oct 2025 20:09:04 GMT
Subject: RFR: 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java
 assert(can_add()) failed: Cannot add TrainingData objects
In-Reply-To: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
References: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
Message-ID: <jP4VemGQ_CBE1v1ZHs8AupG1uUJUeeTDel_TlOYBKg4=.554925d8-9e48-4b6e-ac89-0c4890a9d176@github.com>

On Wed, 1 Oct 2025 19:04:37 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> That's a bit of a bug trail from [JDK-8366948](https://bugs.openjdk.org/browse/JDK-8366948). We need to check if the TD snapshot has happened before attempting to modify the data.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27593#pullrequestreview-3290908319

From jkratochvil at openjdk.org  Wed Oct  1 20:28:13 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Oct 2025 20:28:13 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
Message-ID: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>

https://bugs.openjdk.org/browse/JDK-8369021

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

Commit messages:
 - 8369021: A crash in ConstantPool::klass_at_impl

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

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

From kvn at openjdk.org  Wed Oct  1 20:46:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Oct 2025 20:46:02 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
 <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
Message-ID: <pIcahwWtuil4cfFCgF3_eg2S29yHO5Z0HsoP5KQFUM0=.3299c8f2-ae31-45d2-a9f4-50f5e6705719@github.com>

On Wed, 1 Oct 2025 19:41:41 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5920:
>> 
>>> 5918:         if (EnableX86ECoreOpts) {
>>> 5919:             // align 'big' arrays to cache lines to minimize split_stores
>>> 5920:             cmpptr(count, 96 << shift);
>> 
>> What is `96?
>
> Two trends identified for buffer filling:
>  - filling up to cache line size by 4 bytes reduce performance;
>  - operate by cache line size improve performance.
> According to experiments on Xeon 6740E the 96 is good compromise. For small arrays it is better to ignore split_store and do filling by bigger elements.

What is cache line size for Xeon 6740E? That is what I am asking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395856078

From vaivanov at openjdk.org  Wed Oct  1 21:01:56 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 1 Oct 2025 21:01:56 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <pIcahwWtuil4cfFCgF3_eg2S29yHO5Z0HsoP5KQFUM0=.3299c8f2-ae31-45d2-a9f4-50f5e6705719@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
 <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
 <pIcahwWtuil4cfFCgF3_eg2S29yHO5Z0HsoP5KQFUM0=.3299c8f2-ae31-45d2-a9f4-50f5e6705719@github.com>
Message-ID: <fJeOi_SVP4jf6R_UBYCf5Xx3Q7RzxjTBSc3DZ0X7ZgU=.5a80f3d9-1390-4f7d-a5ea-d7f1dcf1f124@github.com>

On Wed, 1 Oct 2025 20:43:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Two trends identified for buffer filling:
>>  - filling up to cache line size by 4 bytes reduce performance;
>>  - operate by cache line size improve performance.
>> According to experiments on Xeon 6740E the 96 is good compromise. For small arrays it is better to ignore split_store and do filling by bigger elements.
>
> What is cache line size for Xeon 6740E? That is what I am asking.

64 bytes. same as for most x86 CPUs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395886432

From liach at openjdk.org  Wed Oct  1 21:04:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 1 Oct 2025 21:04:46 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
Message-ID: <Mh1MUSVHSLjPcHhlxJljSlUvect2q0-vTxf7CNXizTY=.9e56aecc-baf8-47d8-9e41-47bd9abfe86a@github.com>

On Wed, 1 Oct 2025 20:21:45 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369021

Can a test case be crafted with `jdk.test.lib.ByteCodeLoader`? I remember a class returned by `ByteCodeLoader.load` static method is loaded but not linked.

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

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3358122481

From dholmes at openjdk.org  Wed Oct  1 21:27:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 21:27:28 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v9]
In-Reply-To: <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
Message-ID: <ZGShcyp4QEyuOSXn5iu4MCN2mMg1sICQTLIwIz26eqE=.b09ba240-62bb-4da4-8692-526d3939070c@github.com>

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build issue

The non-test changes only affect the WhiteBox API which in turn is only for testing, so that all seems fine to me.

Approved.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3291185668

From dholmes at openjdk.org  Wed Oct  1 21:34:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 21:34:44 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
Message-ID: <4_gnj0x3vEpXpPFWSDvkJFhP1c811v39xba6WlWMOGI=.3bf00adc-29f2-4704-b8aa-48d01df0ab60@github.com>

On Wed, 1 Oct 2025 20:21:45 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369021

@jankratochvil  neither the PR description nor the JBS issue actually describe the problem and the solution. Linking the class may fix the problem but I'd like to understand where/how the unlinked class was being used as the right fix may be to make some other piece code aware of, and tolerant of, an unlinked class. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3358208799

From kvn at openjdk.org  Wed Oct  1 21:42:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Oct 2025 21:42:49 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
 <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
Message-ID: <m4nLqLrKuxzVltrM2q_a-O8palGg-FGb_V38xj4vnzA=.7816823a-95c6-4988-b71a-d89d05b43fd8@github.com>

On Wed, 1 Oct 2025 19:44:34 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:
>> 
>>> 6012:   BIND(L_fill_4_bytes);
>>> 6013:   subptr(count, 1 << shift);
>>> 6014:   jccb(Assembler::greaterEqual, L_fill_4_bytes_loop);
>> 
>> I don't think it works correctly because you can come here from lines 5998-5999 where ` count` become negative.
>
> testing for tier1, tier2 and tier3 were OK. Will review this part one more time.
> Do you have test scenario that may reproduce this issue?

Testing does not guarantee this path is tested. You need to disable AVX512 to use it otherwise `generate_fill_avx3()` will be used. I was thinking about `byte[63] array` with `-XX:UseAVX=2 -XX:-UseUnalignedLoadStores` flags to hit this path. I did small experiment but unfortunately it seems `arrayof_jbyte_fill` stub is not called with AVX2 so the path is not executed.

I will let you do further investigations to force this path be executed. Here is my small test:

$ java -XX:-TieredCompilation -Xbatch -XX:CompileOnly=TestFillArray::fill -XX:UseAVX=2 -XX:-UseUnalignedLoadStores TestFillArray

$ cat TestFillArray.java 
public class TestFillArray {
    private static byte[] ba;

    static void fill() {
        for (int i = 0; i < ba.length; i++) {
            ba[i] = (byte) 123;
        }
    }

    public static void main(String[] str) {
        ba = new byte[63];
        for (int i = 0; i < 10000; i++) {
            fill();
        }
        ba = new byte[63];
        fill();
        for (int i = 0; i < ba.length; i++) {
            if (ba[i] != (byte) 123) {
                System.out.println("ba[" + i + "] (" + ba[i] + ") != 123");
            }
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2395973509

From dlong at openjdk.org  Wed Oct  1 21:57:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 1 Oct 2025 21:57:46 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
Message-ID: <kA4XiN40meLCLoSCtqng2pLjs6M-6c4J5eRxRx6tHNg=.0d277940-4a67-45d3-a7d0-a07ae62ce81c@github.com>

On Wed, 1 Oct 2025 20:21:45 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369021

Doesn't this change mean that APIs like Class.isMemberClass() can now throw LinkageError?  Can't we compute the enclosing class without linking?

src/hotspot/share/prims/jvm.cpp line 1335:

> 1333: 
> 1334:   bool inner_is_member = false;
> 1335:   Klass* outer_klass = k->compute_enclosing_class(&inner_is_member, CHECK_NULL);

Why not put this change in compute_enclosing_class() instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3358300734
PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2395997028

From iveresov at openjdk.org  Wed Oct  1 23:19:58 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 1 Oct 2025 23:19:58 GMT
Subject: Integrated: 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java
 assert(can_add()) failed: Cannot add TrainingData objects
In-Reply-To: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
References: <xeOUJ68yRS19ysmTQVjGkhMu8WIRoQNHIdJ5SZBLrnk=.1d807a08-1c06-4bde-8ba9-82c76bb8af57@github.com>
Message-ID: <amjhfO_J42Ofd4LXLOYHhdb6mVQKA-c7fBHtaL_ylO0=.451411b7-70db-4587-99b7-e38dafa11db4@github.com>

On Wed, 1 Oct 2025 19:04:37 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> That's a bit of a bug trail from [JDK-8366948](https://bugs.openjdk.org/browse/JDK-8366948). We need to check if the TD snapshot has happened before attempting to modify the data.

This pull request has now been integrated.

Changeset: 4df41d2a
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4df41d2a751e2942c2188ed01313d78e681835bc
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8368698: runtime/cds/appcds/aotCache/OldClassSupport.java assert(can_add()) failed: Cannot add TrainingData objects

Reviewed-by: heidinga, iklam

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

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

From dlong at openjdk.org  Thu Oct  2 00:36:55 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 00:36:55 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v13]
In-Reply-To: <Hv5WFOMU3WtdZrbLBnPDWI2TrVdDuQneE7Ig23U5YCM=.4b28c9d6-d8c5-40da-87a7-784a47207bf2@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <Hv5WFOMU3WtdZrbLBnPDWI2TrVdDuQneE7Ig23U5YCM=.4b28c9d6-d8c5-40da-87a7-784a47207bf2@github.com>
Message-ID: <_XutmY9l6_NfR0YlhMxKBYtlOB_T8doQF7qKX0u5Y28=.54a45409-2b78-439c-af64-49d893b6e7ea@github.com>

On Wed, 1 Oct 2025 16:18:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
>> 
>> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
>> 
>> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
>> 
>> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
>> 
>> We mark all sites that we know will write to code memory with
>> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
>> 
>> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
>> 
>> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
>> 
>> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor, fix a couple of bugs introduced during review.

Still good.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26562#pullrequestreview-3291723784

From dlong at openjdk.org  Thu Oct  2 00:54:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 00:54:54 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v4]
In-Reply-To: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
Message-ID: <WQD2pKsicEd0OZ7NR_p16ruAhNHwrrjnGYc7h9QGJNk=.a0664e54-6a0e-4900-a1f6-41645c08fae6@github.com>

On Tue, 2 Sep 2025 21:09:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Dean Long 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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into 8366461-mh-invoke
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>>  - arm32 build
>>  - Merge branch 'openjdk:master' into 8366461-mh-invoke
>>  - first pass
>
> Nice cleanup! Looks good.

@iwanowww , I think I need you to re-review the final version.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3358642300

From ysuenaga at openjdk.org  Thu Oct  2 04:17:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 04:17:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <RJwCMGN-7dnD8yKTtoX-U1mpv4v2DhtpIoykz3WbS48=.d7a344fc-faec-4005-8664-8c18729b7e5a@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

Can someone review this PR? I think I have to got reviewers both HotSpot and JFR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3358971095

From iveresov at openjdk.org  Thu Oct  2 04:21:22 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 2 Oct 2025 04:21:22 GMT
Subject: RFR: 8369033: Remove dead code in training data
Message-ID: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>

Remove dead code

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

Commit messages:
 - Remove dead code

Changes: https://git.openjdk.org/jdk/pull/27600/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369033
  Stats: 23 lines in 2 files changed: 0 ins; 14 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27600/head:pull/27600

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

From dholmes at openjdk.org  Thu Oct  2 04:40:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 04:40:47 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v10]
In-Reply-To: <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>
Message-ID: <L8dy3dMFkQPnEKkvdQ9T45IsQ5on3IfKZEjQuSWvrjU=.4eb80f72-89ae-4243-ab78-a7f9e063d808@github.com>

On Wed, 1 Oct 2025 08:58:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Use int to avoid cast

Nothing further from me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3292231646

From dholmes at openjdk.org  Thu Oct  2 05:16:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 05:16:54 GMT
Subject: RFR: 8368727: CDS custom loader support causes asserts during
 class unloading
In-Reply-To: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
References: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
Message-ID: <jgXLq7lMR1Yzj77OmOjBRxmF8TlfNuzThmacfEQmj7g=.2a7bddfe-7056-4b43-a1a7-d1e0663a6b2a@github.com>

On Fri, 26 Sep 2025 06:11:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading:
> 
> 
> # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8
> V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870)
> V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441
> 
> 
> The fix is to move the  `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders.
> 
> This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case.

Okay.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27511#pullrequestreview-3292396228

From dholmes at openjdk.org  Thu Oct  2 05:26:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 05:26:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
Message-ID: <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>

On Thu, 4 Sep 2025 11:29:14 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Yasumasa Suenaga 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jfr-on-hy-cpu
>>  - Use jmc_undefined_long if runs on hybrid CPU
>>  - Revert "Update condition"
>>    
>>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>>  - Update condition
>>  - Add fallback code if logical_cpus == 0
>>  - 8365633: JFR reports incorrect number of cores on hybrid CPU
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2581:
> 
>> 2579:     // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
>> 2580:     threads_per_package = threads_per_core() * cores_per_cpu();
>> 2581:   }
> 
> Check `thread_per_package` from `CPUID` to avoid SIGFPE (div by zero).
> 
> `CPUID` leaf 0Bh with ECX (subleaf) = 1 seems to return `0` as number of logical processors in spite of leaf 0Bh is supported in some older processors. It's strange, but I saw it on AMD EPYC 7763 on GitHub Actions runner. The problem appears as following.
> 
> I haven't faced this problem on AMD Ryzen 3 3300X.
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007f19e11ffeed, pid=11344, tid=11345
> #
> # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420)
> # Java VM: OpenJDK 64-Bit Server VM (26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x11ffeed]  VM_Version::initialize_cpu_information()+0x2d
> #
> # CreateCoredumpOnCrash turned off, no core file dumped
> #
> # JFR recording file will be written. Location: /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/scratch/1/hs_err_pid11344.jfr
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> ---------------  S U M M A R Y ------------
> 
> Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Xlog:jfr=trace -XX:StartFlightRecording:filename=./dumped.jfr,dumponexit=true,settings=profile jdk.jfr.startupargs.TestDumpOnExit$TestMain
> 
> Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.5 LTS
> Time: Thu Sep  4 07:17:02 2025 UTC elapsed time: 0.570221 seconds (0d 0h 0m 0s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x00007f19d802ad20):  JavaThread "main"             [_thread_in_vm, id=11345, stack(0x00007f19dff00000,0x00007f19e0000000) (1024K)]
> 
> Stack: [0x00007f19dff00000,0x00007f19e0000000],  sp=0x00007f19dfffbd40,  free space=1007k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x11ffeed]  VM_Version::initialize_cp...

Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2396968555

From rcastanedalo at openjdk.org  Thu Oct  2 05:46:45 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 2 Oct 2025 05:46:45 GMT
Subject: RFR: 8369033: Remove dead code in training data
In-Reply-To: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
References: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
Message-ID: <TeOrHJN-jmhZul4qhU7WSkU0BiZuKQL2Uad4Tzcudyk=.6af0932f-e02a-49b1-962a-af1669a904b4@github.com>

On Thu, 2 Oct 2025 04:13:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove dead code

Marked as reviewed by rcastanedalo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27600#pullrequestreview-3292504311

From ysuenaga at openjdk.org  Thu Oct  2 06:12:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 06:12:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
Message-ID: <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>

On Thu, 2 Oct 2025 05:24:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 2581:
>> 
>>> 2579:     // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
>>> 2580:     threads_per_package = threads_per_core() * cores_per_cpu();
>>> 2581:   }
>> 
>> Check `thread_per_package` from `CPUID` to avoid SIGFPE (div by zero).
>> 
>> `CPUID` leaf 0Bh with ECX (subleaf) = 1 seems to return `0` as number of logical processors in spite of leaf 0Bh is supported in some older processors. It's strange, but I saw it on AMD EPYC 7763 on GitHub Actions runner. The problem appears as following.
>> 
>> I haven't faced this problem on AMD Ryzen 3 3300X.
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGFPE (0x8) at pc=0x00007f19e11ffeed, pid=11344, tid=11345
>> #
>> # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420)
>> # Java VM: OpenJDK 64-Bit Server VM (26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x11ffeed]  VM_Version::initialize_cpu_information()+0x2d
>> #
>> # CreateCoredumpOnCrash turned off, no core file dumped
>> #
>> # JFR recording file will be written. Location: /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/scratch/1/hs_err_pid11344.jfr
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> ---------------  S U M M A R Y ------------
>> 
>> Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Xlog:jfr=trace -XX:StartFlightRecording:filename=./dumped.jfr,dumponexit=true,settings=profile jdk.jfr.startupargs.TestDumpOnExit$TestMain
>> 
>> Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.5 LTS
>> Time: Thu Sep  4 07:17:02 2025 UTC elapsed time: 0.570221 seconds (0d 0h 0m 0s)
>> 
>> ---------------  T H R E A D  ---------------
>> 
>> Current thread (0x00007f19d802ad20):  JavaThread "main"             [_thread_in_vm, id=11345, stack(0x00007f19dff00000,0x00007f19e0000000) (1024K)]
>> 
>> Stack: [0x00007f19dff00000,0x00007f19e0000000],  sp=0x00007f19dfffbd40,  free space=1007k
>> Native frames: (J=compiled Java code, j=interp...
>
> Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??

I want to use number of logical processors from `CPUID` instruction directly because we can't believe `threads_per_core()` on hybrid CPU. Some of cores (e.g. E cores) might not have hyper threading even though `CPUID` reports HT flag.
Thus I think we have to check the value here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2397133449

From egahlin at openjdk.org  Thu Oct  2 06:39:47 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 06:39:47 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <8iCd3iDn3FS3lVx_cXyKBUFpWy40a_9sfH4tJ848FNM=.69c598c7-3f0b-48bb-8ce4-24c036fcb469@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

I'm not sure promoting the value to a long is a good idea anymore, but I'm not completely against it either. Maybe it's sufficient to update the description of the cores field and say the value may be incorrect if there is hybrid cores? Maybe there should be a field indicating hybrid cores, or maybe we should do something else.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359374252

From ysuenaga at openjdk.org  Thu Oct  2 07:16:00 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 07:16:00 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

I saw similar behavior in `VM.info` dcmd, and I modified the output for CPU information in #26808 - removed thread-related information, and added "hybrid" flag.

But I think we cannot apply similar method in JFR because we have to treat number of cores even if "hybrid" flag would be added in event definition, and also we might change all of viewer (JMC, jfr command, and more) to hide number of cores if hybrid flag is set. It is impractical I think.

So I think it is the most reasonable to set `min_jlong` which already means "N/A".

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359516888

From stefank at openjdk.org  Thu Oct  2 07:59:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 2 Oct 2025 07:59:46 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
Message-ID: <kpTuH1PmqEyeCuTaiAiTJtMqOZc-Wa6DNz-ax_v5UcU=.8f270a03-c4af-4fd3-b784-34dfb7b2f33c@github.com>

On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27583#pullrequestreview-3293095646

From stefank at openjdk.org  Thu Oct  2 07:59:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 2 Oct 2025 07:59:48 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
 <bq3M12BFzALDvPLgwytFGUTWyiQyqKXrUIUwgltjmeU=.9de96623-f3ea-4278-b3de-9bfa4b415c74@github.com>
 <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com>
Message-ID: <8hpnnfueQUsV2r1a1h1N99OMdd0p8EpYdRx83blcgOw=.6a3fbad7-3f79-48fe-be00-a6ee68c9de38@github.com>

On Wed, 1 Oct 2025 14:42:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> src/hotspot/share/utilities/growableArray.hpp line 715:
>> 
>>> 713: template <typename E>
>>> 714: class GrowableArray : public GrowableArrayWithAllocator<E, GrowableArray<E>> {
>>> 715:   friend class VMStructs;
>> 
>> I was a bit surprised to see that you added a friend declaration. Was this done because you removed the one in the parent class?
>> 
>> I see that vmStructs.cpp has GrowableArray listed:
>> 
>>   nonstatic_field(GrowableArrayBase,           _len,                                          int)                                   \
>>   nonstatic_field(GrowableArrayBase,           _capacity,                                     int)                                   \
>>   nonstatic_field(GrowableArray<int>,          _data,                                         int*) 
>> 
>> 
>> So, I guess it makes sense to move it here. OTOH, the exposed `_data` field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead?
>> 
>> I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray.
>
>> Was this done because you removed the one in the parent class?
> 
> Yeah that was my reasoning.
> 
>> I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray.
> 
> To me it looks less confusing to have the `friend` declaration for the type which is referenced in `vmStructs`. But both are legal, do you think moving the `friend` declaration to the type which declares the referenced field would be more appropriate? If yes, I'll track other similar patterns too.

I don't think such churn is important for VMStructs. Let's keep your change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2397576465

From egahlin at openjdk.org  Thu Oct  2 08:00:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 08:00:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
Message-ID: <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>

On Thu, 2 Oct 2025 07:12:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> So I think it is the most reasonable to set `min_jlong` which already means "N/A".

I don't think using the min_jlong value is the problem, we do that for other event values, but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359711876

From fandreuzzi at openjdk.org  Thu Oct  2 08:18:46 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 08:18:46 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <kpTuH1PmqEyeCuTaiAiTJtMqOZc-Wa6DNz-ax_v5UcU=.8f270a03-c4af-4fd3-b784-34dfb7b2f33c@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
 <kpTuH1PmqEyeCuTaiAiTJtMqOZc-Wa6DNz-ax_v5UcU=.8f270a03-c4af-4fd3-b784-34dfb7b2f33c@github.com>
Message-ID: <RSKLycOKtoiEohcHZdr4P6aadcTeFNWoeQJ6h4jssDI=.9cdc64eb-922c-49b6-9573-afb87ec331f8@github.com>

On Thu, 2 Oct 2025 07:56:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Marked as reviewed by stefank (Reviewer).

Thanks for the review @stefank.

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

PR Comment: https://git.openjdk.org/jdk/pull/27583#issuecomment-3359780526

From duke at openjdk.org  Thu Oct  2 08:18:48 2025
From: duke at openjdk.org (duke)
Date: Thu, 2 Oct 2025 08:18:48 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
Message-ID: <M-g4RxAT_pNhY3_Jh-agHFifmuPOjVxHuVgIWo3aSLU=.4cac441b-5b93-4a80-af40-7ac4c5555678@github.com>

On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
> 
> Passes tier1 and tier2 (fastdebug).

@fandreuz 
Your change (at version 1f873d0d1e693d0d73772376041cc6171bf13be2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27583#issuecomment-3359787966

From ysuenaga at openjdk.org  Thu Oct  2 08:44:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 08:44:06 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
 <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>
Message-ID: <NYxoilKPVtD-_Rzdvrf-rHeCy2qs9LseRYY3gBpKNbA=.57cd391f-37f2-4f76-98b4-02a4cec299aa@github.com>

On Thu, 2 Oct 2025 07:58:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically.

If the data size is important than showing "N/A", I think we can set "0" for number of cores as I proposed [at first](https://openjdk.github.io/cr/?repo=jdk&pr=27080&range=00). But you said before that it should not be a problem to change to type long: https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207

Which is better? I think it is better not to change data size rather than showing "N/A" for compatibility. I think it is whether it feels natural for JFR that "0" means "N/A".

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359903487

From ayang at openjdk.org  Thu Oct  2 08:47:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 08:47:52 GMT
Subject: RFR: 8368966: Remove spurious VMStructs friends
In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
Message-ID: <8njjGUUpbw5NKV_Rh8MUw4lJ6dqiSUWeSuXC6Thqh1o=.d8b2297d-f3d9-450b-850a-23decdc11320@github.com>

On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27583#pullrequestreview-3293343742

From aboldtch at openjdk.org  Thu Oct  2 08:50:54 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 2 Oct 2025 08:50:54 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <oHkWT0OnLXku6g8FOe6V7eKTdjgdjJ-1f6FmJabHv8Q=.16d5035f-2d58-4f8e-972e-d77786e2eb5e@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

The implementation looks correct now and the extra asserts when calling `try_reserve_range` are a good improvement.

I am still unsure what this flag is supposed to mean. If it is just a hint we allow the user to give or if it is a requirement. And is it for all heaps, or only heaps with +UseCompressedOops as it is currently being used. (Depending on the answers here, we have bugs)

Then there is the whole constraining a JVM advance option process. See my comment in the code. But I would like this PR to also be approved by someone with a better understanding of this process.

src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 292:

> 290:                         "Sum of HeapBaseMinAddress (%zu) and MaxHeapSize (%zu) results in an overflow (%zu)\n",
> 291:                         value , MaxHeapSize, value + MaxHeapSize);
> 292:     return JVMFlag::VIOLATES_CONSTRAINT;

I do not feel like I understand enough of our process when it comes to constraining the JVMs advance options. Even when constraining the nonsensical inputs.

The reasons I am hesitant is that I do not understand this flag at all given that we have this code which ignores the value completely. 
https://github.com/afshin-zafari/jdk/blob/3dfa9765b1d6dcd27152bbd2d242209c7748c964/src/hotspot/share/memory/memoryReserver.cpp#L639-L644

So if we did not have the overflow bug in the code, using a too large value would reach that point and put the heap at arbitrary address which is lower than HeapBaseMinAddress.

Also HeapBaseMinAddress is only used for CompressedOops, so I am not sure if we should constrain the value when CompressedOops are not in use. However this goes back to the whole point of how we treat changing constraints on VM options. Should there always be a CSR?

Example of observed change in behaviour:
## Before

[ linux-x64-debug]$ ./images/jdk/bin/java -XX:HeapBaseMinAddress=18446708889337462784 -Xmx64T --version
java 26-internal 2026-03-17
Java(TM) SE Runtime Environment (fastdebug build 26-internal-2025-09-26-0639506...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 26-internal-2025-09-26-0639506..., mixed mode, sharing)

## After

[ linux-x64-debug]$ ./images/jdk/bin/java -XX:HeapBaseMinAddress=18446708889337462784 -Xmx64T --version
Sum of HeapBaseMinAddress (18446708889337462784) and MaxHeapSize (70368744177664) results in an overflow (35184372088832)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3293345884
PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2397792042

From fandreuzzi at openjdk.org  Thu Oct  2 09:02:00 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 09:02:00 GMT
Subject: Integrated: 8368966: Remove spurious VMStructs friends
In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com>
Message-ID: <K9rfyK2LHGwczSRHHUNneCjq-S2yZUrwJM1U98q_lkU=.e00e5f5b-9ea9-445c-815a-d4b94a9e4378@github.com>

On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: dfd38322
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfd383224dbc2e41c9f44b1acd09ffb179cc38f3
Stats:     80 lines in 47 files changed: 1 ins; 78 del; 1 mod

8368966: Remove spurious VMStructs friends

Reviewed-by: stefank, ayang

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

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

From roland at openjdk.org  Thu Oct  2 09:08:06 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 2 Oct 2025 09:08:06 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v3]
In-Reply-To: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
Message-ID: <Sx03b2OK68wEn2h4EZz3UMjXeon_YLuARChej8OzyEk=.b1236536-633f-4091-956f-1f17c170dd1c@github.com>

> This is a variant of 8332827. In 8332827, an array access becomes
> dependent on a range check `CastII` for another array access. When,
> after loop opts are over, that RC `CastII` was removed, the array
> access could float and an out of bound access happened. With the fix
> for 8332827, RC `CastII`s are no longer removed.
> 
> With this one what happens is that some transformations applied after
> loop opts are over widen the type of the RC `CastII`. As a result, the
> type of the RC `CastII` is no longer narrower than that of its input,
> the `CastII` is removed and the dependency is lost.
> 
> There are 2 transformations that cause this to happen:
> 
> - after loop opts are over, the type of the `CastII` nodes are widen
>   so nodes that have the same inputs but a slightly different type can
>   common.
>   
> - When pushing a `CastII` through an `Add`, if of the type both inputs
>   of the `Add`s are non constant, then we end up widening the type
>   (the resulting `Add` has a type that's wider than that of the
>   initial `CastII`).
>   
> There are already 3 types of `Cast` nodes depending on the
> optimizations that are allowed. Either the `Cast` is floating
> (`depends_only_test()` returns `true`) or pinned. Either the `Cast`
> can be removed if it no longer narrows the type of its input or
> not. We already have variants of the `CastII`:
> 
> - if the Cast can float and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and be removed when it doesn't narrow the type
> of its input.
> 
> - if the Cast is pinned and can't be removed when it doesn't narrow
> the type of its input.
> 
> What we need here, I think, is the 4th combination:
> 
> - if the Cast can float and can't be removed when it doesn't narrow
> the type of its input.
> 
> Anyway, things are becoming confusing with all these different
> variants named in ways that don't always help figure out what
> constraints one of them operate under. So I refactored this and that's
> the biggest part of this change. The fix consists in marking `Cast`
> nodes when their type is widen in a way that prevents them from being
> optimized out.
> 
> Tobias ran performance testing with a slightly different version of
> this change and there was no regression.

Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision:

 - review
 - infinite loop in gvn fix
 - renaming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24575/files
  - new: https://git.openjdk.org/jdk/pull/24575/files/c509ef56..aff5894b

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

  Stats: 61 lines in 10 files changed: 11 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/24575.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24575/head:pull/24575

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

From roland at openjdk.org  Thu Oct  2 09:08:08 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 2 Oct 2025 09:08:08 GMT
Subject: RFR: 8354282: C2: more crashes in compiled code because of
 dependency on removed range check CastIIs [v3]
In-Reply-To: <7Y1VflHDgnEChBAv9bwWH5ayU-K9ngRa3BfPjgzzHP0=.61111d18-a22e-4cb5-9492-e50f5524ac08@github.com>
References: <qos-VYvgreqGsB7ke35RmM3L9uHnnM6nUsm2QONKXc4=.9c902d61-5f45-41f5-8276-ac28830c2bf5@github.com>
 <7Y1VflHDgnEChBAv9bwWH5ayU-K9ngRa3BfPjgzzHP0=.61111d18-a22e-4cb5-9492-e50f5524ac08@github.com>
Message-ID: <nc5DdCxFHlZmevIomZkmQbB7xrBEetNQywV-Ams_NQ8=.1b925836-cb27-455d-bb23-9e410ef64e92@github.com>

On Wed, 23 Apr 2025 10:56:51 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - review
>>  - infinite loop in gvn fix
>>  - renaming
>
> @rwestrel thanks for looking into this one!
> 
> I have not yet deeply studied the PR, but am feeling some confusion about the naming.
> 
> I think the `DependencyType` is really a good step into the right direction, it helps clean things up.
> 
> I'm wondering if we should pick either `depends_only_on_test` or `pinned`, and use it everywhere consistently. Having both around as near synonymes (antonymes?) is a bit confusing for me.
> 
> I'll look into the code more later.

I pushed an update with the renaming suggested by @eme64 and an extra comment with example use cases

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

PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3360011105

From egahlin at openjdk.org  Thu Oct  2 09:34:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 09:34:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <d7VOExVqYIvQxdu7NX5kzUWq1pZd_F6ymrTiKXeRQn8=.cf87afd1-b931-4bc9-803e-494938ef99e0@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

>  But you said before that it should not be a problem to change to type long: [#27080 (comment)](https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207)

I looked at it from a file format perspective (varint encoding), but from an API perspective, as you showed, both getInt("cores") and getValue("cores") may throw an exception. This could impact users who have no problem with hybrid cores today. Also, their code may work on a development or test machine but then break on production hardware.

jcmd is meant for humans to read, so a change there has less impact.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3360138311

From jsikstro at openjdk.org  Thu Oct  2 09:39:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 09:39:03 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
Message-ID: <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>

On Thu, 25 Sep 2025 11:14:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

Reviewing this is taking some time, so this is not a full review yet, but so far I have some comments:

Why do we need the dance with Parallel being able to set a specific `desired_page_size` in `Universe::reserve_heap()`? Maybe I'm wrong, but would it not work to disable UseLargePages early and not have specific logic for Parallel?

src/hotspot/share/gc/parallel/mutableSpace.hpp line 65:

> 63: 
> 64: protected:
> 65:   size_t page_size() const                           { return _page_size;         }

We should vertically align this with the other blocks.

src/hotspot/share/gc/parallel/parallelArguments.cpp line 131:

> 129:   if (page_sz == os::vm_page_size()) {
> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
> 131:     return;

Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.

src/hotspot/share/gc/parallel/parallelArguments.cpp line 137:

> 135:   assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
> 136:   // Space is largepage-aligned.
> 137:   size_t new_alignment = page_sz;

To me it looks like new_alignment will always be different from SpaceAlignment here. We could simplify this to the following:


  SpaceAlignment = page_sz;
    
  // Redo everything from the start
  initialize_heap_flags_and_sizes_one_pass();

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3252288423
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397598451
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397910679
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2397931660

From jsikstro at openjdk.org  Thu Oct  2 09:39:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 09:39:08 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v5]
In-Reply-To: <efj4I-AQCWeV4pf8PLDh9jYE3BAmdjx6lCfGXfKoDpc=.81f5b311-55a0-438d-a1b5-3fc6cc0e2590@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <efj4I-AQCWeV4pf8PLDh9jYE3BAmdjx6lCfGXfKoDpc=.81f5b311-55a0-438d-a1b5-3fc6cc0e2590@github.com>
Message-ID: <FwVMXkjuVAm0j6zFYNoe2M8BZeWNlaAukeKtHnH-C7k=.35ff0a5d-306d-452a-8721-e23be451e728@github.com>

On Mon, 15 Sep 2025 13:26:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

src/hotspot/share/gc/parallel/psVirtualspace.hpp line 44:

> 42:   const size_t _alignment;
> 43: 
> 44:   // OS page size used. If using transparent large pages, it's the desired large page-size.

I'd change this to say Transparent Huge Pages instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2367988953

From ayang at openjdk.org  Thu Oct  2 10:10:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:27 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v7]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <phwjjF8LGJJKOZiAIjDWwGRTKGaNCS2xliut1mhS09U=.573f1aad-835f-43d1-a108-5a297527c1b1@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang 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 nine additional commits since the last revision:

 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - page-size
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - pgc-largepage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/5c02c752..2ccd0dd6

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

  Stats: 11612 lines in 377 files changed: 6346 ins; 3098 del; 2168 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From ayang at openjdk.org  Thu Oct  2 10:10:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:30 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
Message-ID: <JBMtIjzwgyLJjtmogyRqb0E3_k-_Nn-fXHrJy2PYbQY=.acaa8d43-9add-410e-8e54-55de9ad6dac4@github.com>

On Thu, 25 Sep 2025 11:14:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - page-size
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - pgc-largepage

> Why do we need the dance with Parallel being able to set a specific desired_page_size in Universe::reserve_heap()?

Because heap contains subspaces (eden,from,to,old) which needs to be larger than a OS-page in Parallel. Maybe this doesn't have to be this way, but that's what Parallel NUMA relies on currently. It would be much more invasive to change that.

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3293684851

From ayang at openjdk.org  Thu Oct  2 10:10:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Oct 2025 10:10:32 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
 <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
Message-ID: <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>

On Thu, 2 Oct 2025 09:11:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Albert Mingkun Yang 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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - page-size
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - Merge branch 'master' into pgc-largepage
>>  - pgc-largepage
>
> src/hotspot/share/gc/parallel/parallelArguments.cpp line 131:
> 
>> 129:   if (page_sz == os::vm_page_size()) {
>> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
>> 131:     return;
> 
> Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.

There are non-heap uses of `UseLargePages` as well. Here we concluded heap can't use large-page, but other systems still can.

> To me it looks like new_alignment will always be different from SpaceAlignment here. 

Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2398090623
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2398130690

From alanb at openjdk.org  Thu Oct  2 10:43:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Oct 2025 10:43:26 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v6]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <Vw8wZcOqmkIFPJJXz9Yl_hNdtMd47x5If5-7-ivUS-Y=.b38400f5-2377-4377-b8e4-184b9265957a@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into JDK-8353835
 - Improve CommandLineTest.testWarn
 - More test cleanup
 - Merge branch 'master' into JDK-8353835
 - Expand jni/JNIAttachMutatorTest to final fields in named modules
 - Merge branch 'master' into JDK-8353835
 - Test updates based on reviewer feedback
 - RemoveFields(duration) and filter internal frames
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - ... and 21 more: https://git.openjdk.org/jdk/compare/5251405c...234bc924

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=05
  Stats: 4816 lines in 66 files changed: 4639 ins; 54 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From ysuenaga at openjdk.org  Thu Oct  2 11:15:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 11:15:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <6yCL5Daetce0mtR_jN3O2y-qvJ5hSGPODW0-7HhO9SE=.b1eef5ad-ef9f-4472-baed-69538e836ea9@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

So should I revert the change to original? I think it is better not to change data type. Compatibility should prefer than user friendly message ("N/A") in this case.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3360629462

From jsikstro at openjdk.org  Thu Oct  2 13:30:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 13:30:02 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag.
> 
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Namings and comment
 - 8367413: Refactor types in Arguments::set_heap_size()
 - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
 - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
   
   This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
 - Revert "size_t casts for 32-bit part of test_arguments.cpp"
   
   This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
 - size_t casts for 32-bit part of test_arguments.cpp
 - 8367413: Use size_t instead of julong in runtime/arguments.cpp

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

Changes: https://git.openjdk.org/jdk/pull/27224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=02
  Stats: 92 lines in 4 files changed: 20 ins; 23 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

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

From jsikstro at openjdk.org  Thu Oct  2 13:33:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 2 Oct 2025 13:33:00 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v3]
In-Reply-To: <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <Hx886IwksKMtID6gtJqRVTzzuLNLSnihCbsTII7ydME=.a5477861-fad8-402f-9bb0-b71c1277ad4d@github.com>
Message-ID: <T-WDJDkKpQBfMmdSRz-JckuqtnlSsgxY5HuwhvObQfk=.314f34e3-cc18-498f-868d-8a40b27150a8@github.com>

On Thu, 2 Oct 2025 13:30:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> When looking at this I tried to get my head around the default value of the MaxRAM flag. Since this flag is closely coupled with setting the heap size, I've also gone ahead and removed some of the 32-bit (x86, Windows) code in relation to this flag.
>> 
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Namings and comment
>  - 8367413: Refactor types in Arguments::set_heap_size()
>  - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
>  - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
>    
>    This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
>  - Revert "size_t casts for 32-bit part of test_arguments.cpp"
>    
>    This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
>  - size_t casts for 32-bit part of test_arguments.cpp
>  - 8367413: Use size_t instead of julong in runtime/arguments.cpp

[JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485) is now integrated. I've changed the direction of this issue a bit. I now focus on makus sure the transition from uint64_t to size_t is handled robustly along with adding comments to make things easier to understand in `Arguments::set_heap_size()`.

Setting `MaxRAM` to `MIN2(MaxRAM, (uint64_t) ms.ullTotalVirtual)` on Windows was only needed on 32-bit, which is no longer supported. So I've gone ahead and removed it. The virtual address space will practically always be extremely large on Windows 64-bit. See the following resources for more information:
https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases
https://learn.microsoft.com/en-us/windows-server/get-started/locks-limits?tabs=full-comparison&pivots=windows-server-2025

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

PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3361236605

From bmaillard at openjdk.org  Thu Oct  2 14:46:58 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Thu, 2 Oct 2025 14:46:58 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v13]
In-Reply-To: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
Message-ID: <gGMm1BieapmgvfRcvB5X9aVa7hJPAmFYl8zowRNg0PI=.892541d6-c38b-4fec-8899-b7b82b297e17@github.com>

> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
> 
> ## Usage
> 
> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
> that we compile `square` with C2.
> 
> class Square {
>     static int square(int a) {
>         return a * a;
>     }
> 
>     public static void main(String[] args) {
>         square(9);
>     }
> }
> 
> 
> We would like to inspect the node that contains the value returned in this method.
> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
> 
> ```c++
> void Compile::return_values(JVMState* jvms) {
>   GraphKit kit(jvms);
>   Node* ret = new ReturnNode(TypeFunc::Parms,
>                              kit.control(),
>                              kit.i_o(),
>                              kit.reset_memory(),
>                              kit.frameptr(),
>                              kit.returnadr());
>   // Add zero or 1 return values
>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
> 
>   
>   Node* return_value;
>   if (ret_size > 0) {
>     kit.inc_sp(-ret_size);  // pop the return value(s)
>     kit.sync_jvms();
>     return_value = kit.argument(0);
>     ret->add_req(return_value);
> 
>     // <-------------------- Simply insert this
>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>   }
>   
>   // bind it to root
>   root()->add_req(ret);
>   record_for_igvn(ret);
>   initial_gvn()->transform(ret);
> }
> 
> 
> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
> and we get the following output:
> 
> 
> return:
> int 81
> 
> 
> This case is of course trivial, but more useful examples are shown later.
> 
> ## Implementation
> 
> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
> 
> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor.
> 
> The first argument to the runtime printing method is the printing message, a static string encoded as a `...

Beno?t Maillard has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8360389' of github.com:benoitmaillard/jdk into JDK-8360389
 - Add missing hash delete/insert when IGVN is not yet available
 - Print node should be wired to fall through proj of catch when printing return value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26475/files
  - new: https://git.openjdk.org/jdk/pull/26475/files/a4c3821f..f41b23fe

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

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

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

From bmaillard at openjdk.org  Thu Oct  2 14:51:33 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Thu, 2 Oct 2025 14:51:33 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
 <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
Message-ID: <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>

On Wed, 1 Oct 2025 18:45:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/opto/compile.cpp
>>   
>>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>
> src/hotspot/share/opto/compile.cpp line 5387:
> 
>> 5385:       if (in->is_CFG()) {
>> 5386:         if (in->is_Multi()) {
>> 5387:           candidates.push(in->as_Multi()->proj_out(TypeFunc::Control));
> 
> Why you collect only one control output edge? IfNode has two. May be add comment if it is intentional.

This should not happen because we got here by following data inputs, so typically it cannot be an `IfNode` (I have added a comment). However @TobiHartmann pointed out that if we are trying to print the return value of a java call we should use the fall through projection of the `CatchNode` after the call. I have made the necessary changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2399089041

From kvn at openjdk.org  Thu Oct  2 15:25:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 2 Oct 2025 15:25:08 GMT
Subject: RFR: 8369033: Remove dead code in training data
In-Reply-To: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
References: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
Message-ID: <dWkCJMrHx29xh_DLXJpx0xsPrCzwpt4fSrCyzunBdTw=.f4cd6eac-18f1-4a39-9b1e-2f19a4c92f87@github.com>

On Thu, 2 Oct 2025 04:13:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove dead code

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27600#pullrequestreview-3295176182

From kvn at openjdk.org  Thu Oct  2 15:32:07 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 2 Oct 2025 15:32:07 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
 <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
 <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>
Message-ID: <6fuddGArO-vzDhPQ0IHlovlo3xqNDWiSZIzgw7ABT4c=.9c607eec-b4f0-45e1-9745-631282164704@github.com>

On Thu, 2 Oct 2025 14:46:39 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 5387:
>> 
>>> 5385:       if (in->is_CFG()) {
>>> 5386:         if (in->is_Multi()) {
>>> 5387:           candidates.push(in->as_Multi()->proj_out(TypeFunc::Control));
>> 
>> Why you collect only one control output edge? IfNode has two. May be add comment if it is intentional.
>
> This should not happen because we got here by following data inputs, so typically it cannot be an `IfNode` (I have added a comment). However @TobiHartmann pointed out that if we are trying to print the return value of a java call we should use the fall through projection of the `CatchNode` after the call. I have made the necessary changes.

Then which CFG/Multi nodes you expect here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2399226614

From iveresov at openjdk.org  Thu Oct  2 15:42:05 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 2 Oct 2025 15:42:05 GMT
Subject: RFR: 8369033: Remove dead code in training data
In-Reply-To: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
References: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
Message-ID: <88jaTJQKnv5mzjD03_BG2qvFCvX_6FTzB8GjMJB6-ao=.4ae0ff33-aa46-4469-8172-258c5c607f9e@github.com>

On Thu, 2 Oct 2025 04:13:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove dead code

Thanks guys!

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

PR Comment: https://git.openjdk.org/jdk/pull/27600#issuecomment-3361908025

From iveresov at openjdk.org  Thu Oct  2 15:42:05 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 2 Oct 2025 15:42:05 GMT
Subject: Integrated: 8369033: Remove dead code in training data
In-Reply-To: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
References: <X5eF7nLSNWINduyQvqF1EwEluM3xCbOZOw96ChofEd4=.759bf726-5d6c-43ef-b0ed-e9c076d682f8@github.com>
Message-ID: <BhCLvI9CY00Tjdk6O3SsPxlIU7Hu5qjtgmT1pQ7YGg8=.0ac9e2c9-0746-4fb2-ad35-9db93b095111@github.com>

On Thu, 2 Oct 2025 04:13:54 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove dead code

This pull request has now been integrated.

Changeset: 1a03a1fb
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a03a1fbb1c7a83469128106341591c59428437a
Stats:     23 lines in 2 files changed: 0 ins; 14 del; 9 mod

8369033: Remove dead code in training data

Reviewed-by: rcastanedalo, kvn

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

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

From jwaters at openjdk.org  Thu Oct  2 16:29:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Oct 2025 16:29:41 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
Message-ID: <6c9c2AO4gs36Po0A6Z4pYOhqv8a3AoYSxxlmMWPYr2E=.939c38bb-965c-4cd2-af9f-38078c7835c7@github.com>

On Fri, 10 Jan 2025 10:42:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> Hi, the workaround 'disable lto in g1ParScanThreadState because of special inlining/flattening used there' is removed , why this works now ?
>> 
>> The issue there was the `-Wattribute-warning` warnings that were being generated.  But this change is suppressing
>> those warnings in the LTO link:
>> https://github.com/openjdk/jdk/blame/9d05cb8eff344fea3c6b9a9686b728ec53963978/make/hotspot/lib/JvmFeatures.gmk#L176C11-L176C11
>> Note that won't work with the new portable forbidding mechanism based on `deprecated` attributes.
>> 
>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans.
>> The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>
>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
> 
> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
> build crashes with a failed assert:
> 
> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
> 
> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).

After trying and failing and trying and failing countless hours and days... I admit I'm nowhere close to solving this problem. I just can't figure out what the slow paths and external methods not local to the g1ParScanThreadState.cpp source file are. Every attempt at using a tool to discern this has failed catastrophically, and the call hierarchy is enormous, meaning manually trying to do this myself is out of the question. @kimbarrett if I could ask, what are the slow paths that should not be inlined, and what are the methods that are not local to the source file in question? If I just knew what to look at, maybe I could begin to start tackling this problem properly.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3362079047

From aph at openjdk.org  Thu Oct  2 17:14:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 2 Oct 2025 17:14:41 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
Message-ID: <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>

> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
> 
> We need this in order to allow progress on JDK-8365147.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Next try

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27432/files
  - new: https://git.openjdk.org/jdk/pull/27432/files/1e891b76..f61f6fce

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

  Stats: 13 lines in 1 file changed: 5 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27432/head:pull/27432

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

From aph at openjdk.org  Thu Oct  2 17:14:43 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 2 Oct 2025 17:14:43 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <KSxG-qm08Q0etxbv_0E8cHFDhokqZjT-Jg40LXFncw4=.6bb9bc14-7936-4a0c-8d58-651cf033ebc7@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <3EIT8mAB0k4dSVjfJzJL2k6B_6rOeQNPExWGWUwXeWc=.6f94a495-ebad-4f88-b37c-86e2fcb8f7fc@github.com>
 <KSxG-qm08Q0etxbv_0E8cHFDhokqZjT-Jg40LXFncw4=.6bb9bc14-7936-4a0c-8d58-651cf033ebc7@github.com>
Message-ID: <bWpU5J-d0CQM-6ZTiLd8RAxGjl1Q_zB7h0ZZ4SJWygg=.c1f3e4e7-d66d-41e8-8a48-f2fb925292e0@github.com>

On Thu, 25 Sep 2025 09:02:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 43:
>> 
>>> 41: // Return true iff an access to bt is single-copy atomic.
>>> 42: static bool access_is_atomic(BasicType bt) {
>>> 43: #ifdef CPU_MULTI_COPY_ATOMIC
>> 
>> Why do you require `CPU_MULTI_COPY_ATOMIC`? Why can't you unconditionally treat all sub-word/word accesses (naturally aligned) as atomic instead?  Isn't that what JVM already guarantees?
>
>> Why do you require `CPU_MULTI_COPY_ATOMIC`? Why can't you unconditionally treat all sub-word/word accesses (naturally aligned) as atomic instead? Isn't that what JVM already guarantees?
> 
> This is about the properties of the hardware rather than the JMM, but yes, every CPU that we support in HotSpot is single-copy atomic. Perhaps I was being excessively cautious, and we can just remove `access_is_atomic()`. I was thinking about some hypothetical processor which didn't have this property.

I tweaked it a bit more.How is it now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27432#discussion_r2399508392

From jkratochvil at openjdk.org  Thu Oct  2 18:21:47 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 2 Oct 2025 18:21:47 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <kA4XiN40meLCLoSCtqng2pLjs6M-6c4J5eRxRx6tHNg=.0d277940-4a67-45d3-a7d0-a07ae62ce81c@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <kA4XiN40meLCLoSCtqng2pLjs6M-6c4J5eRxRx6tHNg=.0d277940-4a67-45d3-a7d0-a07ae62ce81c@github.com>
Message-ID: <xEnFkXv5MtEtTcLBPE5G8h1Jb3lVuclgBsGVgiF5TOg=.adb1d06f-ed2f-49f0-aa33-16938d45fcb6@github.com>

On Wed, 1 Oct 2025 21:53:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8369021
>
> src/hotspot/share/prims/jvm.cpp line 1335:
> 
>> 1333: 
>> 1334:   bool inner_is_member = false;
>> 1335:   Klass* outer_klass = k->compute_enclosing_class(&inner_is_member, CHECK_NULL);
> 
> Why not put this change in compute_enclosing_class() instead?

Various other similar methods such as:
- JVM_GetClassDeclaredFields
- JVM_GetClassDeclaredMethods
- JVM_GetClassDeclaredConstructors

already contain the same code fragment:

  // Ensure class is linked
  k->link_class(CHECK_NULL);

so without some deep thoughts I have added it also to this method where it was missing and causing a crash:
- JVM_GetDeclaringClass

Without any real world proof it looked to me the similar pattern is also in:
- JVM_GetSimpleBinaryName

I can move it to `InstanceKlass::compute_enclosing_class` although first I would like to find a reproducer = test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2399687735

From asmehra at openjdk.org  Thu Oct  2 18:52:10 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 2 Oct 2025 18:52:10 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v4]
In-Reply-To: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
Message-ID: <qr1XEV8KIRZmzNWV55n4tVuNh2CxiYKpAPK4NOeh4_I=.7146240d-2bf9-438b-8adb-f4d1a3ce201b@github.com>

> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
> 
> Testing:
> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
> 
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
> 
> With this patch, such warnings are not seen at all

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Replace overflow check if guarantee statement
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27553/files
  - new: https://git.openjdk.org/jdk/pull/27553/files/84edc05e..46bda6b3

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

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

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

From asmehra at openjdk.org  Thu Oct  2 18:52:14 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 2 Oct 2025 18:52:14 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v3]
In-Reply-To: <otFK-nW5yiIJ8x5kkQi4UUTZNdxlRrVbAyzUiss-Q5E=.e8c0a635-d402-4dd9-81fa-b31aed63d6d9@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <9wddk1obRVfS_B8Kq8KgK8ZYtaVfv1R855dtW5PWHwQ=.ac08aecc-5f27-444a-9ae7-8ad8d17f829f@github.com>
 <otFK-nW5yiIJ8x5kkQi4UUTZNdxlRrVbAyzUiss-Q5E=.e8c0a635-d402-4dd9-81fa-b31aed63d6d9@github.com>
Message-ID: <ft_4MiKOb1akm31slklRjyxJhQUA4dkmBx3_uvOGPQM=.0bd91ec2-5796-4b83-803b-e3d94e78c3c7@github.com>

On Tue, 30 Sep 2025 22:54:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add assert for _id_counter == 0
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2608:
> 
>> 2606:     // id_counter overflow
>> 2607:     return nullptr;
>> 2608:   }
> 
> I think it will cause issue with `ubsan` because we don't check for `nullptr` returned from this method.
> May be use `guarantee(id > 0);` instead ?
> 
> 2^32 -1 is big number. We can't have so much method's signatures combinations.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2399767124

From vlivanov at openjdk.org  Thu Oct  2 18:56:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 2 Oct 2025 18:56:12 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
Message-ID: <Lw17kZ8ujXpbzZSHFM5_loP2g2NssLW-4F98-Ah-HPk=.62955170-c445-4d9e-b28e-9cf06d2845ec@github.com>

On Thu, 2 Oct 2025 17:14:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Next try

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3295989749

From iklam at openjdk.org  Thu Oct  2 19:00:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 2 Oct 2025 19:00:57 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v4]
In-Reply-To: <qr1XEV8KIRZmzNWV55n4tVuNh2CxiYKpAPK4NOeh4_I=.7146240d-2bf9-438b-8adb-f4d1a3ce201b@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <qr1XEV8KIRZmzNWV55n4tVuNh2CxiYKpAPK4NOeh4_I=.7146240d-2bf9-438b-8adb-f4d1a3ce201b@github.com>
Message-ID: <8ENrZCQ-P34W0Yyt6SerSoJOgEZdD6HENA6FRAAi_2I=.d5e838ba-c5e1-4b28-b2a2-5661bf7ce12f@github.com>

On Thu, 2 Oct 2025 18:52:10 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
>> 
>> Testing:
>> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
>> 
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
>> 
>> With this patch, such warnings are not seen at all
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace overflow check if guarantee statement
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Looks good. Just a couple of nits.

src/hotspot/share/runtime/sharedRuntime.cpp line 2605:

> 2603: AdapterHandlerEntry* AdapterHandlerLibrary::new_entry(AdapterFingerPrint* fingerprint) {
> 2604:   uint id = (uint)AtomicAccess::add((int*)&_id_counter, 1);
> 2605:   guarantee(id > 0, "id_counter overflow");

I think we can even change this to an assert. We limit the AOT metaspace size to `UnscaledClassSpaceMax` which is 4GB. 

https://github.com/openjdk/jdk/blob/1d55adee11fc2fdbf2e009e1308b763fd7217dad/src/hotspot/share/cds/aotMetaspace.cpp#L304C24-L304C45

All AOT methods would have to live within the AOT metaspace , so we will have much fewer than 2^32 methods, which means will we have much fewer than 2^32 signatures. So the `id` will never overflow. Maybe change this to:


assert(id > 0, "we can never overflow because AOT cache cannot contain more than 2^32 methods");

src/hotspot/share/runtime/sharedRuntime.hpp line 687:

> 685: 
> 686:  private:
> 687:   uint _id;

This can be moved near `_linked` so it can fit in the existing unused padding.

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

PR Review: https://git.openjdk.org/jdk/pull/27553#pullrequestreview-3295998278
PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2399787944
PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2399795492

From asmehra at openjdk.org  Thu Oct  2 19:40:32 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 2 Oct 2025 19:40:32 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v4]
In-Reply-To: <8ENrZCQ-P34W0Yyt6SerSoJOgEZdD6HENA6FRAAi_2I=.d5e838ba-c5e1-4b28-b2a2-5661bf7ce12f@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <qr1XEV8KIRZmzNWV55n4tVuNh2CxiYKpAPK4NOeh4_I=.7146240d-2bf9-438b-8adb-f4d1a3ce201b@github.com>
 <8ENrZCQ-P34W0Yyt6SerSoJOgEZdD6HENA6FRAAi_2I=.d5e838ba-c5e1-4b28-b2a2-5661bf7ce12f@github.com>
Message-ID: <F7Z5DkgS92Ui8329xSnNe7lj6nXahsdHdT_Kslx_pSk=.2db85b09-5d8d-4844-9ae8-bbd98aca5bb5@github.com>

On Thu, 2 Oct 2025 18:54:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace overflow check if guarantee statement
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2605:
> 
>> 2603: AdapterHandlerEntry* AdapterHandlerLibrary::new_entry(AdapterFingerPrint* fingerprint) {
>> 2604:   uint id = (uint)AtomicAccess::add((int*)&_id_counter, 1);
>> 2605:   guarantee(id > 0, "id_counter overflow");
> 
> I think we can even change this to an assert. We limit the AOT metaspace size to `UnscaledClassSpaceMax` which is 4GB. 
> 
> https://github.com/openjdk/jdk/blob/1d55adee11fc2fdbf2e009e1308b763fd7217dad/src/hotspot/share/cds/aotMetaspace.cpp#L304C24-L304C45
> 
> All AOT methods would have to live within the AOT metaspace , so we will have much fewer than 2^32 methods, which means will we have much fewer than 2^32 signatures. So the `id` will never overflow. Maybe change this to:
> 
> 
> assert(id > 0, "we can never overflow because AOT cache cannot contain more than 2^32 methods");

Changed it to assert as suggested

> src/hotspot/share/runtime/sharedRuntime.hpp line 687:
> 
>> 685: 
>> 686:  private:
>> 687:   uint _id;
> 
> This can be moved near `_linked` so it can fit in the existing unused padding.

Good point. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2399881707
PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2399882092

From asmehra at openjdk.org  Thu Oct  2 19:40:31 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 2 Oct 2025 19:40:31 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v5]
In-Reply-To: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
Message-ID: <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>

> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
> 
> Testing:
> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
> 
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
> 
> With this patch, such warnings are not seen at all

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Address Ioi's comments
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27553/files
  - new: https://git.openjdk.org/jdk/pull/27553/files/46bda6b3..206148f1

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

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

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

From iklam at openjdk.org  Thu Oct  2 20:04:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 2 Oct 2025 20:04:00 GMT
Subject: RFR: 8368727: CDS custom loader support causes asserts during
 class unloading
In-Reply-To: <FSbrTSDWIqRsZ0LibTuhmO7-j4L-LAVTdJ0AZ8Oewqo=.fb8d2334-dd2f-4442-8e12-81d05fe9cf09@github.com>
References: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
 <FSbrTSDWIqRsZ0LibTuhmO7-j4L-LAVTdJ0AZ8Oewqo=.fb8d2334-dd2f-4442-8e12-81d05fe9cf09@github.com>
Message-ID: <FHbE4_37v4A6zsxuVi3h8ibokIOMnBLohC_tKdUzj-o=.6f9aa58a-f954-4dc7-bdeb-4712e743d571@github.com>

On Fri, 26 Sep 2025 17:32:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading:
>> 
>> 
>> # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8
>> V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870)
>> V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441
>> 
>> 
>> The fix is to move the  `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders.
>> 
>> This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case.
>
> Looks good.

Thanks @coleenp @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27511#issuecomment-3362729718

From iklam at openjdk.org  Thu Oct  2 20:04:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 2 Oct 2025 20:04:01 GMT
Subject: Integrated: 8368727: CDS custom loader support causes asserts during
 class unloading
In-Reply-To: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
References: <zRZRzVzTg1JOsT4gdf4JiMDURMszRnx36AUodHkZ1nA=.67bc1ed7-f108-4228-8f43-23576d0e09eb@github.com>
Message-ID: <LPUaArJN2vNWLAEfsK_5riJTMqrOmuwpb2C0NFiOdwI=.01d145b4-4802-4b64-b35b-b99ce778bf37@github.com>

On Fri, 26 Sep 2025 06:11:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading:
> 
> 
> # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8
> V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870)
> V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441
> 
> 
> The fix is to move the  `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders.
> 
> This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case.

This pull request has now been integrated.

Changeset: 3f27a03b
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f27a03bba4760694a276376d08fb1ba97d08f7e
Stats:     66 lines in 5 files changed: 54 ins; 5 del; 7 mod

8368727: CDS custom loader support causes asserts during class unloading

Reviewed-by: coleenp, dholmes

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

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

From kvn at openjdk.org  Thu Oct  2 20:42:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 2 Oct 2025 20:42:49 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v5]
In-Reply-To: <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>
Message-ID: <6xu38-rSBn89obYD5Pl161pwBDqFoJoPeoROu0NfQfk=.8cbb5e7a-7bb6-4a33-91b2-ee16dcacc0cf@github.com>

On Thu, 2 Oct 2025 19:40:31 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
>> 
>> Testing:
>> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
>> 
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
>> 
>> With this patch, such warnings are not seen at all
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Ioi's comments
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27553#pullrequestreview-3296324640

From vlivanov at openjdk.org  Thu Oct  2 20:52:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 2 Oct 2025 20:52:48 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
Message-ID: <q_QBlS7zWYLUATRqIw96jh2OtHRLpQnl3ljR81vt_Wc=.90c55d9b-4723-499f-9680-1e1c928cf9ea@github.com>

On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
>   
>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

Still looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3296355729

From iklam at openjdk.org  Thu Oct  2 20:56:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 2 Oct 2025 20:56:47 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v5]
In-Reply-To: <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>
Message-ID: <f93YLBMS-0UwDgDlZFcMxNK-LmquH4kF_h-tOEuOHIw=.b1a4136d-dc9e-4935-9912-e6fd3d091b7b@github.com>

On Thu, 2 Oct 2025 19:40:31 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
>> 
>> Testing:
>> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
>> 
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
>> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
>> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
>> 
>> With this patch, such warnings are not seen at all
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Ioi's comments
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27553#pullrequestreview-3296364100

From asmehra at openjdk.org  Thu Oct  2 21:08:48 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 2 Oct 2025 21:08:48 GMT
Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache [v5]
In-Reply-To: <f93YLBMS-0UwDgDlZFcMxNK-LmquH4kF_h-tOEuOHIw=.b1a4136d-dc9e-4935-9912-e6fd3d091b7b@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
 <5PUcZcR079KxyhQnU4JBIS1sDE2V4sZFfNxqssuOSaU=.10df624b-afd8-4775-b218-1348c10998e1@github.com>
 <f93YLBMS-0UwDgDlZFcMxNK-LmquH4kF_h-tOEuOHIw=.b1a4136d-dc9e-4935-9912-e6fd3d091b7b@github.com>
Message-ID: <nHhcpJHk_rmu11HhDBzoQHoQcyUU-fWSCCfDhR-yuQ4=.313e6949-17ba-4cb7-a2a9-39f5bc0a51b2@github.com>

On Thu, 2 Oct 2025 20:53:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Ioi's comments
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> LGTM

@iklam @vnkozlov thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3363049783

From vaivanov at openjdk.org  Thu Oct  2 21:55:46 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 2 Oct 2025 21:55:46 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <m4nLqLrKuxzVltrM2q_a-O8palGg-FGb_V38xj4vnzA=.7816823a-95c6-4988-b71a-d89d05b43fd8@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <4uEgovBH6xON1kQh79rMN3-iQUSQ_0BC-T6mRUY6nKs=.04de1882-ef5f-4cc6-90b4-e7dbde8e4a7f@github.com>
 <DnNvyiNsHvVnBCezUI7l3mOipKiAt4mkCR_K1guXc74=.8d126f98-069a-493c-9e08-77a14840e96b@github.com>
 <m4nLqLrKuxzVltrM2q_a-O8palGg-FGb_V38xj4vnzA=.7816823a-95c6-4988-b71a-d89d05b43fd8@github.com>
Message-ID: <yja-EQRYkns6P-J0txhPCbgNQg3x_qyAdncgJhJ4mmA=.2397515b-a85f-4f32-9706-929506bc3335@github.com>

On Wed, 1 Oct 2025 21:39:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> testing for tier1, tier2 and tier3 were OK. Will review this part one more time.
>> Do you have test scenario that may reproduce this issue?
>
> Testing does not guarantee this path is tested. You need to disable AVX512 to use it otherwise `generate_fill_avx3()` will be used. I was thinking about `byte[63] array` with `-XX:UseAVX=2 -XX:-UseUnalignedLoadStores` flags to hit this path. I did small experiment but unfortunately it seems `arrayof_jbyte_fill` stub is not called with AVX2 so the path is not executed.
> 
> I will let you do further investigations to force this path be executed. Here is my small test:
> 
> $ java -XX:-TieredCompilation -Xbatch -XX:CompileOnly=TestFillArray::fill -XX:UseAVX=2 -XX:-UseUnalignedLoadStores TestFillArray
> 
> $ cat TestFillArray.java 
> public class TestFillArray {
>     private static byte[] ba;
> 
>     static void fill() {
>         for (int i = 0; i < ba.length; i++) {
>             ba[i] = (byte) 123;
>         }
>     }
> 
>     public static void main(String[] str) {
>         ba = new byte[63];
>         for (int i = 0; i < 10000; i++) {
>             fill();
>         }
>         ba = new byte[63];
>         fill();
>         for (int i = 0; i < ba.length; i++) {
>             if (ba[i] != (byte) 123) {
>                 System.out.println("ba[" + i + "] (" + ba[i] + ") != 123");
>             }
>         }
>     }
> }

With extra cycle for code in main
`public class TestFillArray {
    private static byte[] ba;

    static void fill() {
        for (int i = 0; i < ba.length; i++) {
            ba[i] = (byte) 123;
        }
    }

    static void iter() {
        ba = new byte[63];
        for (int i = 0; i < 1000000; i++) {
            fill();
        }
        ba = new byte[63];
        fill();
        for (int i = 0; i < ba.length; i++) {
            if (ba[i] != (byte) 123) {
                System.out.println("ba[" + i + "] (" + ba[i] + ") != 123");
            }
        }
    }

    public static void main(String[] str) {
        for (int i = 0; i < 10000; i++) {
            iter();
        }
        System.out.println("Done.");
    }
}
`
and the command line like 'java -XX:-TieredCompilation -Xbatch -XX:CompileOnly=TestFillArray::fill -XX:+OptimizeFill -XX:UseAVX=2 -XX:-UseUnalignedLoadStores TestFillArray' the vtune reports 'arrayof_jbyte_fill_stub' in hot methods:
Function                                        Module                CPU Time  % of CPU Time(%)
----------------------------------------------  --------------------  --------  ----------------
Interpreter                                     [Dynamic code]        244.070s             84.2%
Stub Generator arrayof_jbyte_fill_stub          [Dynamic code]         24.070s              8.3%
TestFillArray::fill                             [Compiled Java code]   12.650s              4.4%

But no issues were reported for runs with AVX0/1/2 on the Xeon 6740E (economy cores) and Xeon 6900P (performance cores) for both UseUnalignedLoadStores values (true/false).
The 'tier1' testing with option '-XX:-UseUnalignedLoadStores' passed on the Xeon 6740E.
Sorry, I failed to find bad execution branch. Could you give more details about found issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2400175313

From dlong at openjdk.org  Thu Oct  2 22:24:02 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 22:24:02 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
Message-ID: <9wbYkH5F7FQqsuagYmsja5H-_YOZSel32FHZA0Ofet0=.e3faece6-0131-43e1-ae22-e9f50d81588f@github.com>

On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
>   
>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

Thanks Vladimir for the re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3363412878

From dlong at openjdk.org  Thu Oct  2 22:24:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 22:24:03 GMT
Subject: Integrated: 8366461: Remove obsolete method handle invoke logic
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <hOAlQx1s_BG3Q2sOvC_SXvaGZ5w68TCaInIuBmFIIQ4=.e99220e3-674c-4a59-9c69-621bfd441464@github.com>

On Tue, 2 Sep 2025 19:21:48 GMT, Dean Long <dlong at openjdk.org> wrote:

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

This pull request has now been integrated.

Changeset: da7121af
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7121aff9eccb046b82a75093034f1cdbd9b9e4
Stats:     899 lines in 76 files changed: 22 ins; 825 del; 52 mod

8366461: Remove obsolete method handle invoke logic

Reviewed-by: vlivanov, mhaessig

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

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

From dlong at openjdk.org  Thu Oct  2 22:26:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 22:26:46 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
Message-ID: <1ka3dGAl0S2Nv5QX9JDun3AGwDdVOFlGXmI3Fc2U8CU=.c7f44432-2f91-4c3c-a9cf-d7f712d4d3af@github.com>

On Thu, 2 Oct 2025 17:14:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Next try

Marked as reviewed by dlong (Reviewer).

src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 45:

> 43: // The JMM requires atomicity for all accesses to fields of primitive
> 44: // types other than double and long. In practice, HotSpot assumes that
> 45: // on all all processors, accesses to memory operands of wordSize and

Suggestion:

// on all processors, accesses to memory operands of wordSize and

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

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3296669072
PR Review Comment: https://git.openjdk.org/jdk/pull/27432#discussion_r2400254515

From kvn at openjdk.org  Thu Oct  2 23:40:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 2 Oct 2025 23:40:49 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <arx8TfHybxZmsQtCUoMaG4q_p5l5C-OlOtLbIjazrl0=.ceec6476-b18f-4162-be65-79473a481365@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
 <arx8TfHybxZmsQtCUoMaG4q_p5l5C-OlOtLbIjazrl0=.ceec6476-b18f-4162-be65-79473a481365@github.com>
Message-ID: <rkB84r06KG99ObcpxLK9VK1L-RbBJfXvDNl3Sw9FXwE=.8fe02fea-f9b2-4a17-ae0b-5371c6183191@github.com>

On Thu, 25 Sep 2025 15:00:58 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays
>
> Thanks for your review!

@IvaVladimir 

Looks like you are right. The code works. I have to go line by line to find what happened to `count`. I was confused by `subptr(count, 1 << shift);` at line 6013 but it does not affect two lowest bits which are checked in the following code.  And after 5998-5999 lines you can get `count` value only in the range [-7 ... 0].

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

PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3363622749

From kvn at openjdk.org  Thu Oct  2 23:43:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 2 Oct 2025 23:43:52 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
Message-ID: <UA630TRZUOdMzvgzKO1K01VDyQEYAbwf_0LGTXr4id8=.1f902d62-cae5-42ce-ae09-9c41a9eb8697@github.com>

On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974  the fill intrinsics used by default.
>> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711
>> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859
>> while for 'bad' case these metrics are
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785
>> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659
>> 
>> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic.
>> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled
>> -- | -- | -- | -- | --
>> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03
>> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41
>> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09
>> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29
>> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10
>> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30
>> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32
>> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03
>> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20
>> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58
>> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07
>> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88
>> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91
>> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92
>> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98
>> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98
>> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00
>> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00
>> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00
>> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00
>> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00
>> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00
>> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00
>> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00
>> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75
>> ArraysFill.testShortFill | 31 | 1...
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays

And my testing passed.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26747#pullrequestreview-3296873702

From vaivanov at openjdk.org  Thu Oct  2 23:59:47 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 2 Oct 2025 23:59:47 GMT
Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE
 for unaligned arrays [v7]
In-Reply-To: <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
 <IPMDZJb_LRuFMctYrEqOSB0v9dOiNpRKw6AR_bt4mxc=.9d5616f3-afff-4122-af6c-b7edac8f9b53@github.com>
Message-ID: <vAMtDLk45GP2Mqz5xrzWZzHzYD5kOwA7F9w8fd3eBmo=.eae8cd45-b514-4b77-89fc-fac2b1607a1a@github.com>

On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974  the fill intrinsics used by default.
>> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711
>> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859
>> while for 'bad' case these metrics are
>> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785
>> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659
>> 
>> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic.
>> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled
>> -- | -- | -- | -- | --
>> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03
>> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41
>> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09
>> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29
>> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10
>> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30
>> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32
>> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03
>> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20
>> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58
>> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07
>> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88
>> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91
>> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92
>> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98
>> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98
>> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00
>> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00
>> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00
>> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00
>> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00
>> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00
>> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00
>> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00
>> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75
>> ArraysFill.testShortFill | 31 | 1...
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3363654119

From asmehra at openjdk.org  Fri Oct  3 02:46:01 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 3 Oct 2025 02:46:01 GMT
Subject: Integrated: 8364929: Assign unique id to each AdapterBlob stored in
 AOTCodeCache
In-Reply-To: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
References: <UVwMsayvWcvjJYvjgjDi5-wUceBFmn0N4mHfMz6ULDg=.f3eee91e-a3bf-4f07-83b7-eaea390a9a03@github.com>
Message-ID: <QbRBGwP878LJhfnGrAW24Mtk9Wers1R1gRjQKM_WWCA=.4ce39ced-13af-4a31-9575-722c19e23723@github.com>

On Mon, 29 Sep 2025 16:22:45 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.
> 
> Testing:
> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run:
> 
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
> [0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache
> 
> With this patch, such warnings are not seen at all

This pull request has now been integrated.

Changeset: f62b9eca
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62b9eca08694bbbe80d9e7d7b704db4f2423830
Stats:     34 lines in 2 files changed: 18 ins; 1 del; 15 mod

8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache

Reviewed-by: kvn, iklam

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

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

From dholmes at openjdk.org  Fri Oct  3 06:58:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 06:58:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
Message-ID: <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>

On Thu, 2 Oct 2025 06:10:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??
>
> I want to use number of logical processors from `CPUID` instruction directly because we can't believe `threads_per_core()` on hybrid CPU. Some of cores (e.g. E cores) might not have hyper threading even though `CPUID` reports HT flag.
> Thus I think we have to check the value here.

Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.

Let me walk through an example to see if I have it right:

We have a hybrid system with two sockets, each of which has 6P and 2E cores. Only the P cores have hyper-threading even though the HT bit is set. So the current code would do:

_no_of_threads = 28  // I hope that is what the OS reports: 2 * (6*2 + 2)
threads_per_core()  = 2   // because of HT bit
cores_per_cpu() = 8
threads_per_package = 2 * 8 = 16
_no_of_sockets = 28 / 16 = 1   // integer division -> gives wrong answer

with new code:

threads_per_package = 14   // direct from CPUID logical processors
_no_of_sockets = 28 / 14 = 12

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2400974344

From dholmes at openjdk.org  Fri Oct  3 06:58:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 06:58:52 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <3EbBfiANbzyez4insW9WqZcbNTged0_EMHnJrbm5h4Y=.9ee9ca3d-087c-4430-b4c4-f037127e09fa@github.com>

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jfr-on-hy-cpu
>  - Use jmc_undefined_long if runs on hybrid CPU
>  - Revert "Update condition"
>    
>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>  - Update condition
>  - Add fallback code if logical_cpus == 0
>  - 8365633: JFR reports incorrect number of cores on hybrid CPU

src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:

> 2593:   // estimate the number of cores.
> 2594:   // -1 if hybrid CPU because it is difficult to derive number of cores.
> 2595:   _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);

It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2400979011

From aboldtch at openjdk.org  Fri Oct  3 08:17:50 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 3 Oct 2025 08:17:50 GMT
Subject: RFR: 8367149: Add convenient construction for creating ad-hoc
 VMErrorCallback [v5]
In-Reply-To: <Cg4LOai5-cQ7hR-qy97a9aoYPgcM71wk4uRVykUYjUM=.665079a5-6112-4960-b5eb-794eda8c1383@github.com>
References: <Cg4LOai5-cQ7hR-qy97a9aoYPgcM71wk4uRVykUYjUM=.665079a5-6112-4960-b5eb-794eda8c1383@github.com>
Message-ID: <2QTd9ZuWtIroiKHChw6ap1VP02dt3E2Hfm9iXpBMPsw=.dd09773c-7c47-4c13-8396-4bcb9a1c972e@github.com>

> Add a class OnVMError which uses the VMErrorCallback mechanism which is a convenient construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use:
> ```C++
>   {
>     // Note the lambda is invoked after an error occurs within this thread,
>     // and during on_error's lifetime. If state prior to the crash is required,
>     // capture a copy of it first.
>     auto important_value = get_the_value();
> 
>     OnVMError on_error([&](outputStream* st) {
>       // Dump the important bits.
>       st->print("Prior value: ");
>       important_value.print_on(st);
>       st->print("During crash: ")
>       get_the_value().print_on(st);
>       // Dump whole the whole state.
>       this->print_on(st);
>     });
> 
>     // Sometimes doing a thing will crash the VM.
>     do_a_thing();
>   }
> 
> 
> C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods.

Axel Boldt-Christmas 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 seven additional commits since the last revision:

 - Merge tag 'jdk-26+18' into JDK-8367149
   
   Added tag jdk-26+18 for changeset 5251405c
 - Merge tag 'jdk-26+17' into JDK-8367149
   
   Added tag jdk-26+17 for changeset 2aafda19
 - Replace ergonomic with convenient
 - Add a comment explaining the deduction rules
 - Skip multiple inheritance and allow more than lambda like callables.
 - Update doc example
 - 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27159/files
  - new: https://git.openjdk.org/jdk/pull/27159/files/f2f3a1c1..250f23f3

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

  Stats: 11978 lines in 389 files changed: 6399 ins; 3203 del; 2376 mod
  Patch: https://git.openjdk.org/jdk/pull/27159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159

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

From kbarrett at openjdk.org  Fri Oct  3 09:05:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Oct 2025 09:05:45 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>

On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

I agree the similarity between `relaxed_store` and `release_store` isn't
ideal. I think unqualified `load` and `store` is worse.

> Atomic r-m-w operations (pretty much everything except base load/store) were
> required to have full bi-directional fence semantics from "day one". That
> doesn't make sense for base load/store so they are "relaxed" by default.

That's only true in the HotSpot API. It's not true for C++ <atomic> or the C
equivalent, or in most published papers, where the default for "atomic" loads
and stores is sequentially consistent. So we're weird that way. We don't even
directly have those operations (though they can probably be more or less
simulated using RMW operations).

> I personally hate the term "relaxed" as it suggests to me a removal of
> "normal" ordering, when really it means the absence of a stronger ordering.

I agree that "relaxed" doesn't seem like the greatest of terms. But I think
it's the generally accepted term in this area. At least, it's what's used for
C/C++ <atomic> and friends. (But maybe I'm wrong about it being generally
accepted? Looking through some papers, I'm not always finding that
nomenclature.)

So it might be a mistake to invent our own terminology. But for the sake of
discussion I'll throw out one idea: "unordered".

(I think "atomic" has the right technical meaning (indivisible, i.e. no
tearing, but doesn't imply ordering), but is probably too confusing. It would
also require something different for the proposed `atomic_inc()` and
`atomic_dec()` member functions.)

How do we resolve this? I feel like this whole PR is stuck here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3364872165

From bmaillard at openjdk.org  Fri Oct  3 10:27:49 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Fri, 3 Oct 2025 10:27:49 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <6fuddGArO-vzDhPQ0IHlovlo3xqNDWiSZIzgw7ABT4c=.9c607eec-b4f0-45e1-9745-631282164704@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
 <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
 <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>
 <6fuddGArO-vzDhPQ0IHlovlo3xqNDWiSZIzgw7ABT4c=.9c607eec-b4f0-45e1-9745-631282164704@github.com>
Message-ID: <iHMe9TxqSGUWGWAxt9RzWCab0wi6Zmgh-iObgJmcY58=.e315f2dd-5fc5-4039-9319-4c2d687bbc95@github.com>

On Thu, 2 Oct 2025 15:29:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This should not happen because we got here by following data inputs, so typically it cannot be an `IfNode` (I have added a comment). However @TobiHartmann pointed out that if we are trying to print the return value of a java call we should use the fall through projection of the `CatchNode` after the call. I have made the necessary changes.
>
> Then which CFG/Multi nodes you expect here?

I have run all the examples I have, and I have found that the only time this path is executed is when we reach the `StartNode`. I would leave it as it is just in case. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2401468154

From aph at openjdk.org  Fri Oct  3 10:48:46 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 3 Oct 2025 10:48:46 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
Message-ID: <bZR53aRAjWAZvONfRVv5lySVbqY9YpwCO5iucERmaw8=.91bc28b4-3888-4b96-aa83-5b85a4c1c04e@github.com>

On Fri, 3 Oct 2025 09:02:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I agree the similarity between `relaxed_store` and `release_store` isn't ideal. I think unqualified `load` and `store` is worse.

Strong agree.

> > I personally hate the term "relaxed" as it suggests to me a removal of
> > "normal" ordering, when really it means the absence of a stronger ordering.
> 
> I agree that "relaxed" doesn't seem like the greatest of terms. But I think it's the generally accepted term in this area. At least, it's what's used for C/C++ and friends. (But maybe I'm wrong about it being generally accepted? Looking through some papers, I'm not always finding that nomenclature.)

Java (or, at least, the `java.util.concurrent` package) uses the term "opaque" for this meaning.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3365229625

From dholmes at openjdk.org  Fri Oct  3 11:48:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 11:48:46 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <xEnFkXv5MtEtTcLBPE5G8h1Jb3lVuclgBsGVgiF5TOg=.adb1d06f-ed2f-49f0-aa33-16938d45fcb6@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <kA4XiN40meLCLoSCtqng2pLjs6M-6c4J5eRxRx6tHNg=.0d277940-4a67-45d3-a7d0-a07ae62ce81c@github.com>
 <xEnFkXv5MtEtTcLBPE5G8h1Jb3lVuclgBsGVgiF5TOg=.adb1d06f-ed2f-49f0-aa33-16938d45fcb6@github.com>
Message-ID: <EA917u5bZtlEGWlHew5VSlOHEUvMs7GOp5hYJYdIjLY=.e185dfe3-405f-49da-b80c-76a4093f1612@github.com>

On Thu, 2 Oct 2025 18:19:20 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1335:
>> 
>>> 1333: 
>>> 1334:   bool inner_is_member = false;
>>> 1335:   Klass* outer_klass = k->compute_enclosing_class(&inner_is_member, CHECK_NULL);
>> 
>> Why not put this change in compute_enclosing_class() instead?
>
> Various other similar methods such as:
> - JVM_GetClassDeclaredFields
> - JVM_GetClassDeclaredMethods
> - JVM_GetClassDeclaredConstructors
> 
> already contain the same code fragment:
> 
>   // Ensure class is linked
>   k->link_class(CHECK_NULL);
> 
> so without some deep thoughts I have added it also to this method where it was missing and causing a crash:
> - JVM_GetDeclaringClass
> 
> Without any real world proof it looked to me the similar pattern is also in:
> - JVM_GetSimpleBinaryName
> 
> I can move it to `InstanceKlass::compute_enclosing_class` although first I would like to find a reproducer = test case.

Various reflection methods have to work on a linked class, but that doesn't mean they all have to. I'm not convinced the true problem has been identified here yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2401619726

From stefank at openjdk.org  Fri Oct  3 11:51:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 3 Oct 2025 11:51:47 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
Message-ID: <ZjMY-LIOOTdQAILsh8CHxEJeU_LrErDCGO9cpekQrBM=.4b4e09b8-d293-4833-b702-61693e99d99f@github.com>

On Fri, 3 Oct 2025 09:02:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> How do we resolve this? I feel like this whole PR is stuck here.

Just a reminder that I wrote:
> The following isn't a strong request, but maybe more of stated preference and an inquiry what other HotSpot devs think about the proposed names

I really would have liked to hear from other Reviewers what they think. So, I've been waiting for others to chime in. If I'm really alone in my lack of enthusiasm for the names `relaxed_store` / `load_releaxed` then so be it. 

If you are going to skip the names Atomic<T>::load/store will you also update the names AtomicAccess<T>::load/store in a follow-up RFE?

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3365389935

From ysuenaga at openjdk.org  Fri Oct  3 12:42:52 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 3 Oct 2025 12:42:52 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
Message-ID: <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>

On Fri, 3 Oct 2025 06:53:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.

Yes, so I think this PR needs reviewer(s) from HotSpot folks.

> So the current code would do:

Unfortunately, no. It would derive wrong number of sockets as following:


_no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
threads_per_core()  = 2   // HT enabled
cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors
threads_per_package = 14 // 2 threads per core * 7 cores per cpu
_no_of_sockets = 2 // 28 threads / 14 threads per package


`cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)).


  if (is_intel()) {
    bool supports_topology = supports_processor_topology();
    if (supports_topology) {
      result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
               _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
    }


In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`.


_no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
threads_per_core()  = 2   // HT enabled
cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID`
threads_per_package = 14 // ** different from current implementation ** the value from `CPUID`
_no_of_sockets = 2 // 28 threads / 14 threads per package


I uploaded test code for `CPUID` leaf  0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401759645

From ysuenaga at openjdk.org  Fri Oct  3 12:59:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 3 Oct 2025 12:59:50 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <3EbBfiANbzyez4insW9WqZcbNTged0_EMHnJrbm5h4Y=.9ee9ca3d-087c-4430-b4c4-f037127e09fa@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <3EbBfiANbzyez4insW9WqZcbNTged0_EMHnJrbm5h4Y=.9ee9ca3d-087c-4430-b4c4-f037127e09fa@github.com>
Message-ID: <OmWmWXzyikAV0ir55dznh0DX13cv3rApZn1Ny7NxvGw=.76a746ca-66a2-4022-87a6-76e08bf910ad@github.com>

On Fri, 3 Oct 2025 06:55:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jfr-on-hy-cpu
>>  - Use jmc_undefined_long if runs on hybrid CPU
>>  - Revert "Update condition"
>>    
>>    This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
>>  - Update condition
>>  - Add fallback code if logical_cpus == 0
>>  - 8365633: JFR reports incorrect number of cores on hybrid CPU
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:
> 
>> 2593:   // estimate the number of cores.
>> 2594:   // -1 if hybrid CPU because it is difficult to derive number of cores.
>> 2595:   _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);
> 
> It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1.

I think incorrect value is not useful because it causes confusing.

If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401819924

From ayang at openjdk.org  Fri Oct  3 13:02:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 13:02:49 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
Message-ID: <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>

On Mon, 29 Sep 2025 11:45:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I'm no sure about putting the word relaxed before the word store in relaxed_store.

I would vote for consistent `<verb>_<strength>` for all APIs, i.e. `store_relaxed` in this case.

> I understand why it was done for release_store

I skimmed through the current code base and can see lots of places that assumes `release` precedes `store`, but I don't get why it has to be this way. Why `store_release` doesn't work? (It matches `load_acquire` in a symmetry, IMO.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3365603368

From egahlin at openjdk.org  Fri Oct  3 13:17:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 3 Oct 2025 13:17:58 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <OmWmWXzyikAV0ir55dznh0DX13cv3rApZn1Ny7NxvGw=.76a746ca-66a2-4022-87a6-76e08bf910ad@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <3EbBfiANbzyez4insW9WqZcbNTged0_EMHnJrbm5h4Y=.9ee9ca3d-087c-4430-b4c4-f037127e09fa@github.com>
 <OmWmWXzyikAV0ir55dznh0DX13cv3rApZn1Ny7NxvGw=.76a746ca-66a2-4022-87a6-76e08bf910ad@github.com>
Message-ID: <_xWKjgnQjsDHTvxZqp_l5tQE0etiJoK5nu8PuLAr4v0=.1b91e771-d0e2-4829-9928-26e118691f10@github.com>

On Fri, 3 Oct 2025 12:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:
>> 
>>> 2593:   // estimate the number of cores.
>>> 2594:   // -1 if hybrid CPU because it is difficult to derive number of cores.
>>> 2595:   _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);
>> 
>> It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1.
>
> I think incorrect value is not useful because it causes confusing.
> 
> If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event.

Even if the value is incorrect, it still has some value as an approximation. We could update the description to make this clearer, or perhaps provide additional information to help users.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401874712

From ayang at openjdk.org  Fri Oct  3 14:13:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 14:13:27 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v8]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <cnK3OQz5KWqelrUFUbTLtHEs_zcxH7iKmf4BvluYyLY=.c0a18b7c-bc15-42da-9703-96921bd4b5d5@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/2ccd0dd6..3227621e

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

  Stats: 17 lines in 3 files changed: 12 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From jsikstro at openjdk.org  Fri Oct  3 14:33:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 3 Oct 2025 14:33:10 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v6]
In-Reply-To: <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <Dok3MuPRbbrHUfFtwY5eu4n6IXm7tL8Zw6nWvPz6n64=.d38dc2ac-5301-4cab-b6d3-b824062f46a3@github.com>
 <8eWze_-jDaiR6YqPIXO69uHyMLQUSG_0wM3jyTmYYN4=.bf449c42-7659-498f-b7f3-c8f3073b36d5@github.com>
 <TydqjZ-401J-3RByzvnMJz8zqHPWLfGjx7GeZddD15E=.a178114b-8423-4c60-8833-3ba04de7e9a4@github.com>
Message-ID: <BSA9TeBOYmwOZ2ma-qPc8ubortjQaBPjeEFhEWUaNug=.6fdcb78a-edf4-424b-a664-00c36b01226c@github.com>

On Thu, 2 Oct 2025 09:52:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 131:
>> 
>>> 129:   if (page_sz == os::vm_page_size()) {
>>> 130:     log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
>>> 131:     return;
>> 
>> Wouldn't it make sense to do `FLAG_SET_ERGO(UseLargepages, false)` here since it is effectively disabled.
>
> There are non-heap uses of `UseLargePages` as well. Here we concluded heap can't use large-page, but other systems still can.

I see, thank you.

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 137:
>> 
>>> 135:   assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
>>> 136:   // Space is largepage-aligned.
>>> 137:   size_t new_alignment = page_sz;
>> 
>> To me it looks like new_alignment will always be different from SpaceAlignment here. We could simplify this to the following:
>> 
>> 
>>   SpaceAlignment = page_sz;
>>     
>>   // Redo everything from the start
>>   initialize_heap_flags_and_sizes_one_pass();
>
>> To me it looks like new_alignment will always be different from SpaceAlignment here. 
> 
> Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

We discussed this offline, but if `default_space_alignment()` ever coincided with a Large page size, say 2MB, and 2MB large pages are chosen, SpaceAlignment would still be equal to `default_space_alignment()` and we would end up reserving small pages in `ParallelScavengeHeap::initialize()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2402168281
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2402167659

From ayang at openjdk.org  Fri Oct  3 14:44:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 14:44:15 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v9]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/3227621e..421f1c4d

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

  Stats: 10 lines in 2 files changed: 2 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From kvn at openjdk.org  Fri Oct  3 14:46:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Oct 2025 14:46:52 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <iHMe9TxqSGUWGWAxt9RzWCab0wi6Zmgh-iObgJmcY58=.e315f2dd-5fc5-4039-9319-4c2d687bbc95@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
 <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
 <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>
 <6fuddGArO-vzDhPQ0IHlovlo3xqNDWiSZIzgw7ABT4c=.9c607eec-b4f0-45e1-9745-631282164704@github.com>
 <iHMe9TxqSGUWGWAxt9RzWCab0wi6Zmgh-iObgJmcY58=.e315f2dd-5fc5-4039-9319-4c2d687bbc95@github.com>
Message-ID: <IWkxli81o4UoMq706P3sKvcu7bIY8wSLIivguYmikzE=.bdfba3d4-969a-4089-a774-f9e4e9744c61@github.com>

On Fri, 3 Oct 2025 10:24:31 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> Then which CFG/Multi nodes you expect here?
>
> I have run all the examples I have, and I have found that the only time this path is executed is when we reach the `StartNode`. I would leave it as it is just in case. What do you think?

I suggest to add `assert(!n->is_MultiBranch(), "unexpected node: %s", n->Name());`  if you are sure we never see such nodes here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2402222767

From mbeckwit at openjdk.org  Fri Oct  3 15:18:43 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 3 Oct 2025 15:18:43 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <sH6zjpkJkvzJn7_GW6EpTLFHF2-6r7QfZULNZCjb26A=.a27046a7-fb19-423e-8268-28a798682963@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <t0AbPAeCTlvyPkiOPkvjw4sLNHnok8QIDiAuraTt_yQ=.135c2ef2-f2ba-4db5-b4ff-9d62d5fee230@github.com>
 <sKysUUUhzjgodDBw0yEihSvzZ0aiLWrAaWcO2C8x-sM=.b8efdfc8-b008-43a9-9b6b-291855e1ef11@github.com>
 <sH6zjpkJkvzJn7_GW6EpTLFHF2-6r7QfZULNZCjb26A=.a27046a7-fb19-423e-8268-28a798682963@github.com>
Message-ID: <PW3d9v_7Ljz6k96kgQKZkvKFm1OdPcoep9-tTMpUF-s=.a6da1089-1f38-4e33-8575-584f92d552f1@github.com>

On Wed, 27 Aug 2025 11:22:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1HeapEvaluationTask.hpp line 36:
>> 
>>> 34: // Time-based heap evaluation task that runs during idle periods.
>>> 35: // Uses PeriodicTask rather than G1ServiceTask due to build compatibility issues
>>> 36: // in JDK 25+. PeriodicTask's 10ms granularity is adequate for heap evaluation
>> 
>> Can you please elaborate on these "compatibility issues"
>
> +1. I would absolutely try to avoid subscribing to `PeriodicTask`. Is there something missing with `G1ServiceTask`?

changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2402353147

From kbarrett at openjdk.org  Fri Oct  3 15:22:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Oct 2025 15:22:43 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <b0Sn1_PUUHhxWhibZLdbQWCWlNCEjEpowbvzL02Cjxs=.0f87c610-166b-4eac-a1e7-3f14c38d4093@github.com>

On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

> If you are going to skip the names Atomic::load/store will you also update the names AtomicAccess::load/store in a follow-up RFE?

That makes sense to do, for the residue after conversion to using Atomic<T>.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3366160256

From kbarrett at openjdk.org  Fri Oct  3 15:25:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Oct 2025 15:25:48 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
Message-ID: <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>

On Fri, 3 Oct 2025 13:00:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I skimmed through the current code base and can see lots of places that assumes `release` precedes `store`, but I don't get why it has to be this way. Why `store_release` doesn't work? (It matches `load_acquire` in a symmetry, IMO.)

The naming is intentional, to map onto the behavior.
release_store() is roughly like release(); store();
release_store_fence() is roughly like release(); store(); fence()
load_acquire() is roughly like load(); acquire();

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3366171793

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

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

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

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

From ayang at openjdk.org  Fri Oct  3 20:15:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 20:15:46 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
Message-ID: <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>

On Fri, 3 Oct 2025 15:23:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> The naming is intentional, to map onto the behavior.
> release_store() is roughly like release(); store();

By `release()`, do you mean `OrderAccess::release()`? I believe the latter imposes stronger synchronization than `release_store()`. (Similar to atomic_store_explicit vs atomic_thread_fence in cpp.)`

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3367076262

From ayang at openjdk.org  Fri Oct  3 21:05:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Oct 2025 21:05:17 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300900845

From dcubed at openjdk.org  Fri Oct  3 21:05:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:18 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <mgOLvnR1MQjGI9_8EnNU5geiJw_R6G2d_JX5n7n19kc=.e0c75b93-abd6-4d72-a3b6-fe257741e19a@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Blasted auto-correct keeps changing what I type...

It's been too long since I've bundled multiple fixes together. I forgot a couple of steps...

All Mach5 testing that I've done is documented in each bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367198386
PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367205612
PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367207761

From dcubed at openjdk.org  Fri Oct  3 21:05:16 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:16 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
Message-ID: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>

In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:

[JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs

[JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC

[JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

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

Commit messages:
 - 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
 - 8369132 disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
 - 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs

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

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

From dcubed at openjdk.org  Fri Oct  3 21:05:19 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:05:19 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
 <63cMLQaAuITwPnfrDch2UblWoWXcKu1pwJk54-ehVXA=.feee83fd-1d9b-47dd-8a3e-fd6b98f3f3e0@github.com>
Message-ID: <_a422YA5GgS6goxf5CnnaG-YsMmfn-M6vYqkK0XYnR4=.21894e92-f2f6-4d93-8fd7-3cfa0447f7c8@github.com>

On Fri, 3 Oct 2025 20:47:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
>> 
>> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
>> 
>> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
>> 
>> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367206699

From dholmes at openjdk.org  Fri Oct  3 21:10:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 21:10:53 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v9]
In-Reply-To: <AWHThZIA8Ay3elncy_r1uDaTWR3OKf0XduewTLNhvPk=.9747fc78-e40e-4660-b53c-4d5e0eb510ab@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
 <AWHThZIA8Ay3elncy_r1uDaTWR3OKf0XduewTLNhvPk=.9747fc78-e40e-4660-b53c-4d5e0eb510ab@github.com>
Message-ID: <hLfy6d03kxe9GHNReWVb15S8TGltbo2Ei7HfhYapxu8=.8d51babb-9ffe-4ac7-b313-5599b6c458e0@github.com>

On Tue, 30 Sep 2025 10:15:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build issue
>
> Andrei has already reviewed. Maybe @jbachorik could rereview it.

@parttimenerd this has been ready for integration for a couple of days now. But now the test is being ProblemListed so you will need to merge with master and remove it again and then get a re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3367219277

From dholmes at openjdk.org  Fri Oct  3 21:14:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Oct 2025 21:14:58 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Seems reasonable.

I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java   a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27629#pullrequestreview-3300964363

From dcubed at openjdk.org  Fri Oct  3 21:14:59 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 21:14:59 GMT
Subject: Integrated: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
Message-ID: <xcMGbupgO3JhcE9laWQzZTCnPkLmBw3z0euW1ehBKEo=.dd8b00a5-d232-449e-9b2b-d35d23d5678e@github.com>

On Fri, 3 Oct 2025 20:41:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
> 
> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
> 
> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
> 
> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

This pull request has now been integrated.

Changeset: 837f634b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/837f634bf29fd877dd62a2e0f7d7a1bd383372d3
Stats:     4 lines in 4 files changed: 4 ins; 0 del; 0 mod

8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
8369132: Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option

Reviewed-by: ayang, dholmes

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

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

From dcubed at openjdk.org  Fri Oct  3 22:20:10 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:20:10 GMT
Subject: Integrated: 8369138: New test
 compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails
In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
Message-ID: <8jFcnpEQJ0A-ewTXxSDdsKHPTc_sW4rDxuhZQTCShKk=.9c7d9937-045a-47a7-adfd-bbad9b899eaa@github.com>

On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java
> to execute with release bits.

This pull request has now been integrated.

Changeset: e6868c62
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6868c624851d5c6bd182e45ba908cb06b731e8c
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails

Reviewed-by: kvn

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

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

From dcubed at openjdk.org  Fri Oct  3 22:15:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:15:55 GMT
Subject: RFR: 8369128: ProblemList
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
In-Reply-To: <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>
References: <2y3lFDzY9oh1bIIt57Bd3hAXXrGyivq2AKI_l2Lhhvc=.41331210-c95c-4811-a567-81a8fb72c2e3@github.com>
 <vTz-Ajc6zR7Sc5dLXlXoH584Qy-NWb2Jzca0ETM5Lwc=.2f04a3d1-a4fa-4024-ba30-b11af63c965b@github.com>
Message-ID: <0aO_PY7lyXtH0jQ2_Zhk7QYFdDtZjYFr_-oluOpdF8k=.e7659811-f5a6-40a9-a4e6-7e2357cc77ac@github.com>

On Fri, 3 Oct 2025 21:10:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In order to reduce noise in the JDK26 CI, I'm bundling the following three trivial fixes:
>> 
>> [JDK-8369128](https://bugs.openjdk.org/browse/JDK-8369128) ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs
>> 
>> [JDK-8369132](https://bugs.openjdk.org/browse/JDK-8369132) Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC
>> 
>> [JDK-8369133](https://bugs.openjdk.org/browse/JDK-8369133) Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option
>
> Seems reasonable.
> 
> I approved the fix for jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java   a couple of days ago but for some reason the author has not been around to integrate it. I have made a note on the PR that now they will need to fix the PL too.
> 
> Thanks

@dholmes-ora - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27629#issuecomment-3367369658

From kvn at openjdk.org  Fri Oct  3 22:20:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Oct 2025 22:20:08 GMT
Subject: Integrated: 8369138: New test
 compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails
In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
Message-ID: <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com>

On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java
> to execute with release bits.

Good

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27630#pullrequestreview-3301152546

From dcubed at openjdk.org  Fri Oct  3 22:20:09 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:20:09 GMT
Subject: Integrated: 8369138: New test
 compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails
In-Reply-To: <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com>
References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
 <-9uQtIDwqmzu91j5YIq8VNCIPKukIvWBj_vkpaSEBSI=.9badf4fd-0b0a-4f1e-98f1-74854e5044a6@github.com>
Message-ID: <3naIU4lB6Vlr8RjCZKKAmHU4QfQJTjdHbX5rtOXy3L0=.d0b7c7fa-173e-43fe-9f7e-64da86e191fa@github.com>

On Fri, 3 Oct 2025 22:14:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java
>> to execute with release bits.
>
> Good

@vnkozlov - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27630#issuecomment-3367377929

From dcubed at openjdk.org  Fri Oct  3 22:20:07 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:20:07 GMT
Subject: Integrated: 8369138: New test
 compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails
Message-ID: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>

A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java
to execute with release bits.

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

Commit messages:
 - 8369138: new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails

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

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

From dcubed at openjdk.org  Fri Oct  3 22:20:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Oct 2025 22:20:08 GMT
Subject: Integrated: 8369138: New test
 compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails
In-Reply-To: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
References: <7CRh-ioETkcKO1GkBy8K7fJghm0f7fjlPFt__ZRoSxI=.c2f1dea3-b179-408d-8353-d506f556b0fc@github.com>
Message-ID: <WNRxRtoqYZ1PNuV74q_lgVvBe6KqtIJ2xtTJPs7DPqs=.71a9f194-e393-4b25-a480-dbe3273304ce@github.com>

On Fri, 3 Oct 2025 22:10:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to allow new test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java
> to execute with release bits.

I tested this fix with a local release bits run on my MBP14.

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

PR Comment: https://git.openjdk.org/jdk/pull/27630#issuecomment-3367377177

From ysuenaga at openjdk.org  Sat Oct  4 00:39:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 4 Oct 2025 00:39:50 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <_xWKjgnQjsDHTvxZqp_l5tQE0etiJoK5nu8PuLAr4v0=.1b91e771-d0e2-4829-9928-26e118691f10@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <3EbBfiANbzyez4insW9WqZcbNTged0_EMHnJrbm5h4Y=.9ee9ca3d-087c-4430-b4c4-f037127e09fa@github.com>
 <OmWmWXzyikAV0ir55dznh0DX13cv3rApZn1Ny7NxvGw=.76a746ca-66a2-4022-87a6-76e08bf910ad@github.com>
 <_xWKjgnQjsDHTvxZqp_l5tQE0etiJoK5nu8PuLAr4v0=.1b91e771-d0e2-4829-9928-26e118691f10@github.com>
Message-ID: <uEFowLF_vJFXHXmglxh60Mgcx36lqOGudaJ5cnVRxyI=.1cb0e6e4-25b6-4e76-b0ec-78b24d4caedb@github.com>

On Fri, 3 Oct 2025 13:15:03 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think incorrect value is not useful because it causes confusing.
>> 
>> If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event.
>
> Even if the value is incorrect, it still has some value as an approximation. We could update the description to make this clearer, or perhaps provide additional information to help users.

This PR adds "Hybrid Architecture" to the description field. Do you think it is enough only it?

I think it is better to add some notice that number of cores is approximate value, and it might be incorrect on hybrid CPU. However I have no idea where to add it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2403620724

From kbarrett at openjdk.org  Sat Oct  4 01:09:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Oct 2025 01:09:53 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
 <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
Message-ID: <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>

On Fri, 3 Oct 2025 20:12:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > The naming is intentional, to map onto the behavior.
> > release_store() is roughly like release(); store();
> 
> By `release()`, do you mean `OrderAccess::release()`?

Yes, which is why I said "roughly like". And on some platforms it might be "exactly like", because that's how it's
implemented for that platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3367717639

From alanb at openjdk.org  Sat Oct  4 05:09:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 4 Oct 2025 05:09:27 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8353835
 - Add test for -Xlog:jni=debug
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Improve CommandLineTest.testWarn
 - More test cleanup
 - Merge branch 'master' into JDK-8353835
 - Expand jni/JNIAttachMutatorTest to final fields in named modules
 - Merge branch 'master' into JDK-8353835
 - Test updates based on reviewer feedback
 - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=06
  Stats: 4858 lines in 66 files changed: 4681 ins; 54 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From dholmes at openjdk.org  Sun Oct  5 04:52:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 5 Oct 2025 04:52:53 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
Message-ID: <nAWq6X_8TvxqKvFSO_5EH-W8A4XdfpWvGPPYLPb_Wyo=.008f9f39-7c0b-4749-9f67-3f5aa654858b@github.com>

On Tue, 30 Sep 2025 15:06:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. 
>> 
>> A common theme I've struggled with: While JEP explicitly mentions of `static` fields, and `MethodHandle`s, they are not always exercised in tests. It very well might be unnecessary given the context, but dropped some comments anyway.
>> 
>> For those who were about to jump the gun after seeing no mentions of `VarHandle`s: _"The 2 APIs that are changed by the JEP are `Field.setXXX` and `Lookup.unreflectSetter`.  A `VarHandle` produced by `Lookup.unreflectVarHandle` has never been allowed write access to final fields, so no change there, `UOE` will continue to be thrown."_ ? @AlanBateman
>
>> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully.
> 
> @vy Thank you very much for your thorough review and walk through of all of the tests. You clearly spent a lot of time on this. I went through your comments and pushed an update [5acb1d727c5e0feee52c7a1f47665264eb534489](
> https://github.com/openjdk/jdk/pull/25115/commits/5acb1d727c5e0feee52c7a1f47665264eb534489) to add more tests, improves some comments, and remove the unused setInt methods that you spotted in the x-module test. Many of the tests are focused on specific parts of the solution (APIs, access checks, CLI options, JAR file manifest, JNI, ...) and I've resisted going further with some of these tests to avoid too much overlap.  You have rightly identified a few opportunities for more tests, e.g. JNI attached thread doing upcall to mutate a final field in named module as the tests only checks the unnamed module case right now. This are good suggestions but they require a good bit of setup, I'll try to get to it (or find someone) so that we have more tests before we are done.

@AlanBateman  - Sorry should have realized this sooner.  This is only the preparatory step so writing to final fields is still allowed at the moment, in which case -Xcheck:jni should only be issuing a warning, otherwise code that still writes to finals (but which knows it has to stop before final-really-means-final) won't be able to use -Xcheck:jni to watch for other problems.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3368748448

From duke at openjdk.org  Sun Oct  5 13:00:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:00:44 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Move from j.l.management to com.sun.management etc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/ae29e031..64313101

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

  Stats: 345 lines in 13 files changed: 225 ins; 111 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

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

From duke at openjdk.org  Sun Oct  5 13:05:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <4EoYAdS53Tor8IKojA3sXvzWPZOl7ENkvI7dvucgyj0=.12a455c1-03f7-490d-ac56-12e4fc63af19@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

@AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369044318

From duke at openjdk.org  Sun Oct  5 13:05:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <5dSkJW6Hrhm0M_3xFwlG4UwK1ITG2PvKhohIzQiDeA8=.cd29171f-1dae-486a-a525-beb13cb9ef2b@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

I introduced a JDK-specific MemoryMXBean in `com.sun.management` and added `getTotalGcCpuTime` there. I believe the Java idiomatic way to retrieve GC CPU time and process CPU time would be something like:


import java.lang.management.ManagementFactory;
import com.sun.management.MemoryMXBean;
import com.sun.management.OperatingSystemMXBean;

public class Main2 {
    public static void main(String[] args) {
        final MemoryMXBean mxMemoryBean = ManagementFactory.getPlatformMXBean(MemoryMXBean.class);
        final OperatingSystemMXBean mxOSBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);

        System.out.println("getTotalGcCpuTime: " + mxMemoryBean.getTotalGcCpuTime());
        System.out.println("getProcessCpuTime: " + mxOSBean.getProcessCpuTime());
    }
}


Given that `getTotalGcCpuTime` is most useful when you also sample process CPU time I like this symmetry, thanks for the suggestion.

I updated the language in the documentation:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> CPU time used by all garbage collection. In
     * general this includes time for all driver threads,
     * workers, VM operations on the VM thread and the string
     * deduplication thread (if enabled). May be non-zero even if no
     * GC cycle occurred. This method returns {@code -1} if the
     * platform does not support this operation or if called during
     * shutdown.
     *
     * @return the total accumulated CPU time for garbage collection
     * in nanoseconds.
     *
     * @since 26
     */


Since we include time om VM thread which strictly is not a garbage collection thread I think it is better to constrain it to "garbage collection" in general. Let me know what you think.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369043846

From alanb at openjdk.org  Sun Oct  5 13:20:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Oct 2025 13:20:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <XMa-r0ly3bAyMX-j6DVKHFSO2gSGgaOCt-d_9ppCCGs=.c2ebb81f-5072-4b79-9a1c-0652c8d987a3@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

> @AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

A JDK-specific management interface is a supported/documented interface so additions/changes will need a CSR. I would suggest ignoring for the CSR for a few days to give time for feedback here on the updated proposal.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369053361

From duke at openjdk.org  Sun Oct  5 13:30:27 2025
From: duke at openjdk.org (jonghoonpark)
Date: Sun, 5 Oct 2025 13:30:27 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v4]
In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
Message-ID: <sndhDHP_SpmYc7_jHwGO9M4QKZu3ODGdaH1CGQV6kjQ=.acbb83c8-c550-475f-8611-f2ead28ab793@github.com>

> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
> 
> ---
> 
> Following the direction outlined in the issue description,
> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
> 
> I've confirmed that it works without issues in my local tests.
> 
> Reviews and feedback are welcome.

jonghoonpark 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:

  Refactor: Introduce Smaps class for testing
  
  Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27273/files
  - new: https://git.openjdk.org/jdk/pull/27273/files/873804c5..57b1dcaf

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

  Stats: 80 lines in 3 files changed: 39 ins; 28 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273

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

From duke at openjdk.org  Sun Oct  5 13:37:46 2025
From: duke at openjdk.org (jonghoonpark)
Date: Sun, 5 Oct 2025 13:37:46 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v3]
In-Reply-To: <5dc7WZjOY4ymVSZcN7ixLlg4rGahTo9ObDSwW-xbpRQ=.7c749ebc-4b70-4492-b565-27922bfb9f78@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
 <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com>
 <5dc7WZjOY4ymVSZcN7ixLlg4rGahTo9ObDSwW-xbpRQ=.7c749ebc-4b70-4492-b565-27922bfb9f78@github.com>
Message-ID: <IKmKae-iuleUlT-36N0LTCZNgzaL_21BBHNxgISciE4=.25894c11-aa83-4366-b0fb-11b2ec6d250e@github.com>

On Wed, 17 Sep 2025 16:45:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> jonghoonpark 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:
>> 
>>   Refactor: Introduce Smaps class for testing
>>   
>>   Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
>
> Found some time to look closer at this. I would prefer if we could clean up the `Smaps` class even more when moving it to the testlib. We might want to go even further than this:
> https://github.com/openjdk/jdk/compare/master...kstefanj:jdk:pull/27273-v2
> 
> I felt it was easier to show you my ideas this way rather than just giving comment. Some names might need improving and some more polishing, but what do you think about the general structure [here](https://github.com/openjdk/jdk/commit/4550eb677d74803935be64a1cc321c671f91adc7)?

@kstefanj  
Sorry for the late reply.

I?ve reviewed the code you wrote, and I think it?s much clearer!
I?ve updated it with your suggested changes and confirmed that everything works fine in testing.

//

Sorry for rebasing ? it?s a habit of mine, and I did it without thinking. I?ll be more careful next time.

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

PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3369062974

From alanb at openjdk.org  Sun Oct  5 13:52:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Oct 2025 13:52:50 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
Message-ID: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>

On Tue, 30 Sep 2025 15:06:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. 
>> 
>> A common theme I've struggled with: While JEP explicitly mentions of `static` fields, and `MethodHandle`s, they are not always exercised in tests. It very well might be unnecessary given the context, but dropped some comments anyway.
>> 
>> For those who were about to jump the gun after seeing no mentions of `VarHandle`s: _"The 2 APIs that are changed by the JEP are `Field.setXXX` and `Lookup.unreflectSetter`.  A `VarHandle` produced by `Lookup.unreflectVarHandle` has never been allowed write access to final fields, so no change there, `UOE` will continue to be thrown."_ ? @AlanBateman
>
>> I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully.
> 
> @vy Thank you very much for your thorough review and walk through of all of the tests. You clearly spent a lot of time on this. I went through your comments and pushed an update [5acb1d727c5e0feee52c7a1f47665264eb534489](
> https://github.com/openjdk/jdk/pull/25115/commits/5acb1d727c5e0feee52c7a1f47665264eb534489) to add more tests, improves some comments, and remove the unused setInt methods that you spotted in the x-module test. Many of the tests are focused on specific parts of the solution (APIs, access checks, CLI options, JAR file manifest, JNI, ...) and I've resisted going further with some of these tests to avoid too much overlap.  You have rightly identified a few opportunities for more tests, e.g. JNI attached thread doing upcall to mutate a final field in named module as the tests only checks the unnamed module case right now. This are good suggestions but they require a good bit of setup, I'll try to get to it (or find someone) so that we have more tests before we are done.

> @AlanBateman - Sorry should have realized this sooner. This is only the preparatory step so writing to final fields is still allowed at the moment, in which case -Xcheck:jni should only be issuing a warning, otherwise code that still writes to finals (but which knows it has to stop before final-really-means-final) won't be able to use -Xcheck:jni to watch for other problems.

JEP 500 is about using deep reflection to mutate final instance fields. It defines the CLI option to enable final field mutation for specific modules and the CLI option to determine the action when illegal final field mutation is attempted. The proposal is to start with the the action "warn" as the default, some future JEP will propose to change it to "deny" and drop the "allow" action. 

The JEP does not propose to change JNI. Native code that uses JNI to mutate final instance or final static fields will work as before and in the future. So JNI is outside of the fold and the CLI option to allow/warn/deny does not apply to JNI. The roadmap to move to "deny" by default does not include JNI.

The change to the JNI implementation is limited to logging with -Xlog:jni=debug and a fatal error when running with -Xcheck:jni. I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.

I don't see any issue with changing that section of the JEP but only if Ron/Alex agree.  TBH, aside from the write-protected fields that are System.in/out/errr, it should be very rare to encounter native code mutating final fields. A more gentle transition for -Xcheck:jni users might not make any difference.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3369072100

From vaivanov at openjdk.org  Sun Oct  5 23:58:57 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Sun, 5 Oct 2025 23:58:57 GMT
Subject: Integrated: 8365290: [perf] x86 ArrayFill intrinsic generates
 SPLIT_STORE for unaligned arrays
In-Reply-To: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
References: <uabMKle9lWdK3MRJOZsgmucIdj66fyC0OGohRmj7ppE=.74539f17-b7f5-47b9-b287-caa48cb68462@github.com>
Message-ID: <xZXY1vLTCgGZZGYRk9gpXIml9RiFQDEDvMHot5kH1Qo=.6c6092ea-1a19-48c7-b592-f1a5c2b6bd5c@github.com>

On Tue, 12 Aug 2025 14:54:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974  the fill intrinsics used by default.
> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like
> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711
> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859
> while for 'bad' case these metrics are
> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785
> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659
> 
> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic.
> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled
> -- | -- | -- | -- | --
> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03
> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41
> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09
> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29
> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10
> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30
> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32
> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03
> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20
> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58
> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07
> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88
> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91
> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92
> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98
> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98
> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00
> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00
> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00
> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00
> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00
> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00
> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00
> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00
> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75
> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35
> ArraysFill.testShortFill | 250 | 58872.03 | 9962...

This pull request has now been integrated.

Changeset: ba7bf43c
Author:    Vladimir Ivanov <vaivanov at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba7bf43c76c94bea85dbbd865794184b7ee0cc86
Stats:     43 lines in 1 file changed: 36 ins; 3 del; 4 mod

8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays

Reviewed-by: sviswanathan, vpaprotski, kvn

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

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

From fbredberg at openjdk.org  Mon Oct  6 08:13:04 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 6 Oct 2025 08:13:04 GMT
Subject: Integrated: 8367601: Remove held_monitor_count
In-Reply-To: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
Message-ID: <De9em1eUGtKmXDlQiUVT5IuJDCqpa7MoZyMomleaBok=.bd4bc21e-75c5-4b34-a772-3d0eb1200084@github.com>

On Tue, 30 Sep 2025 09:43:51 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
> - `_held_monitor_count`
> - `_parent_held_monitor_count`
> - `_jni_monitor_count`
> 
> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
> They are not present in other platforms.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> `PowerPC` and `RISC-V` has been sanity checked using QEMU.

This pull request has now been integrated.

Changeset: e6781fd9
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6781fd9497723a7baab38d6bfb958ba1b1c24ff
Stats:     401 lines in 27 files changed: 0 ins; 384 del; 17 mod

8367601: Remove held_monitor_count

Reviewed-by: mdoerr, pchilanomate, fyang

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

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

From fbredberg at openjdk.org  Mon Oct  6 08:13:03 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 6 Oct 2025 08:13:03 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <ZloUxsk_VyPX2j9XfPh-kPlfkdIl3huoMwClos5USew=.54eb9c8c-6edb-4c1d-81ac-7a37c5a571d8@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
>> - `_held_monitor_count`
>> - `_parent_held_monitor_count`
>> - `_jni_monitor_count`
>> 
>> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
>> They are not present in other platforms.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> `PowerPC` and `RISC-V` has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

Thank you all for the reviews. Now let's...

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

PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3370402267

From shade at openjdk.org  Mon Oct  6 08:57:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 08:57:48 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
Message-ID: <GaVMDVCVL2zrIo5Nsw3cX3wJ6Pp2-4UrnQW8IkliNSg=.25e9bb76-019a-4862-bed2-71c2ea20f3a7@github.com>

On Thu, 2 Oct 2025 17:14:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Next try

This is a good compromise.

At the risk of dragging it ever further, I think we can make it ever crisper by catching the fact we are going for `volatile_field_(load|store)` either for proper volatile, or because we wanted to force atomicity.


 bool needs_atomic = AlwaysAtomicAccesses && !access_is_atomic(result->type());
 ...
 if ((is_volatile || needs_atomic) && !needs_patching) {
   gen->volatile_field_store(...)
 }


It looks like we really want to push the `membar()`-s down to `LIRGenerator`, though. Especially as AArch64 emits more membars on top:


void LIRGenerator::volatile_field_load(LIR_Address* address, LIR_Opr result,
                                       CodeEmitInfo* info) {
  // 8179954: We need to make sure that the code generated for
  // volatile accesses forms a sequentially-consistent set of
  // operations when combined with STLR and LDAR.  Without a leading
  // membar it's possible for a simple Dekker test to fail if loads
  // use LD;DMB but stores use STLR.  This can happen if C2 compiles
  // the stores in one method and C1 compiles the loads in another.
  if (!CompilerConfig::is_c1_only_no_jvmci()) {
    __ membar();
  }
  __ volatile_load_mem_reg(address, result, info);
}


But that can be left for future refactoring.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3303449966

From shade at openjdk.org  Mon Oct  6 09:04:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 09:04:01 GMT
Subject: RFR: 8367601: Remove held_monitor_count [v2]
In-Reply-To: <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
References: <AjmDieRQAqH41-eYBYaytL4n9GV1ASdmgSnA8e0Xwms=.d35f49c8-976e-4446-b64c-dfe3cb022121@github.com>
 <W8ewRZ0NhJBGnAu9h4l1QUB5ighZSfwRAdr4EtgZIyQ=.b711a0d6-6d4f-4b30-a31c-1da313067774@github.com>
Message-ID: <YujzfudL8eb278grrAdxO4x3IN3NYeKnu1YNH2nX0vk=.8c459a3f-9f68-420d-9a49-d200d3667226@github.com>

On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need:
>> - `_held_monitor_count`
>> - `_parent_held_monitor_count`
>> - `_jni_monitor_count`
>> 
>> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`.
>> They are not present in other platforms.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> `PowerPC` and `RISC-V` has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

Good cleanup, thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3303476645

From ayang at openjdk.org  Mon Oct  6 10:22:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 10:22:07 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
 <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
 <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
Message-ID: <Twxggb4LzbmQgmPU0yt7su7yre7Rz0TzJxK3ViqzXK8=.27cc7013-2a93-4a35-b55f-957eba0eafc0@github.com>

On Sat, 4 Oct 2025 01:07:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Yes, which is why I said "roughly like."

OK, I understand the reasoning behind the naming. However, I?d argue that the design feels somewhat *inside-out* ? it exposes implementation details through the abstraction.

Returning to the example of `atomic_store_explicit` vs. `atomic_thread_fence` in C++, they are two distinct sets of APIs with different specifications and semantics. Mixing them only introduces unnecessary confusion.  
The corresponding APIs in HotSpot are `Atomic::release_store` and `OrderAccess::release`, and drawing parallels between them can also be misleading.

A more accurate way to view `Atomic::release_store` is that the memory synchronization is *intrinsically tied* to the `store` operation ? not before it, not after it. (Also, I wonder if using an arg, i.e. `store(mo_release)`, similar to what's in C++, can avoid the confusion of viewing `store` and `release` as two separate steps.)

> And on some platforms it might be "exactly like", because that's how it's implemented for that platform.

That?s merely an implementation detail, which shouldn?t be reflected at the specification level (or in the naming).

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3370902620

From alanb at openjdk.org  Mon Oct  6 11:48:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Oct 2025 11:48:50 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

src/jdk.management/share/classes/com/sun/management/MemoryMXBean.java line 45:

> 43:      * GC cycle occurred. This method returns {@code -1} if the
> 44:      * platform does not support this operation or if called during
> 45:      * shutdown.

Now that the proposal is a JDK-specific management interface it means that this method can say something about how it relates to, or how it might be used with, OperatingSystemMXBean::getProcessCpuTime. 

I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0. The former concerns Java threads so it might not have any connection to this new method which concerns CPU usage by non-Java threads, but someone is bound to ask.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405893440

From duke at openjdk.org  Mon Oct  6 12:22:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 6 Oct 2025 12:22:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
Message-ID: <JkqE79GvlPwCKJumq_ADRDzrm8poExa9abYAXgbcwWo=.e7d89796-16f1-49cb-8efa-694c6f859c59@github.com>

On Mon, 6 Oct 2025 11:46:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0.

`ThreadMXBean::isThreadCpuTimeSupported` uses the value from `os::is_thread_cpu_time_supported`:

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L131-L137

I ensure to always return `-1` if thread cpu time is not supported as this is the contract that is promised by the documentation.

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L894-L896

So, no this is not possible. However, `is_thread_cpu_time_enabled` is not being considered, but as you say, this method only concerns Java threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405993712

From fandreuzzi at openjdk.org  Mon Oct  6 12:27:57 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 6 Oct 2025 12:27:57 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and ThreadsClaimTokenScope
 in G1RootProcessor
Message-ID: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>

Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.

- `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
- `active_workers ` is guaranteed to be `> 0`

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - revert
 - replace

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

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

From rehn at openjdk.org  Mon Oct  6 12:30:55 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 6 Oct 2025 12:30:55 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
Message-ID: <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>

On Wed, 1 Oct 2025 10:34:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> 
>> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
>> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
>> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
>> 
>> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order RV_NON_EXT_FEATURE_FLAGS

Hey, I don't get the premise.

VMVersion have a bunch of methods e.g VM_Version::supports_data_cache_line_flush() / VM_Version::get_current_sve_vector_length, etc....
Now we call some of them "non_ext_UnalignedScalar()", why ? And how is this a improvement ?

VM_Version methods is not related to whatever or not some information we need is part of an RVI extension.

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3371395516

From cnorrbin at openjdk.org  Mon Oct  6 12:58:21 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 6 Oct 2025 12:58:21 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container values
 separately
Message-ID: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>

Hi everyone,

The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:

- A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
- A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.

To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.

In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.

`OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.

Testing:
- Oracle tiers 1-5
- Container tests on cgroup v1 and v2 hosts.

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

Commit messages:
 - separate-machine-container-functions

Changes: https://git.openjdk.org/jdk/pull/27646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367319
  Stats: 433 lines in 20 files changed: 273 ins; 70 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/27646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27646/head:pull/27646

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

From aph at openjdk.org  Mon Oct  6 13:06:31 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 13:06:31 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v3]
In-Reply-To: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
Message-ID: <l7BCHhGpiM3mluSdLn1LegP4eaoBepuY-kwiPBaRTys=.add3188b-127b-4b17-b00d-79f826c9700b@github.com>

> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
> 
> We need this in order to allow progress on JDK-8365147.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Review feeback
 - Review feeback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27432/files
  - new: https://git.openjdk.org/jdk/pull/27432/files/f61f6fce..7399fc59

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

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

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

From aph at openjdk.org  Mon Oct  6 13:06:32 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 13:06:32 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <GaVMDVCVL2zrIo5Nsw3cX3wJ6Pp2-4UrnQW8IkliNSg=.25e9bb76-019a-4862-bed2-71c2ea20f3a7@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
 <GaVMDVCVL2zrIo5Nsw3cX3wJ6Pp2-4UrnQW8IkliNSg=.25e9bb76-019a-4862-bed2-71c2ea20f3a7@github.com>
Message-ID: <cjLlvS-reAaPMGyQEspcuWjozETCmnsUCFh62wU8Lq4=.8b3ebbc5-ebab-4c71-84dd-cba59350b570@github.com>

On Mon, 6 Oct 2025 08:55:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is a good compromise.
> 
> At the risk of dragging it ever further, I think we can make it ever crisper by catching the fact we are going for `volatile_field_(load|store)` either for proper volatile, or because we wanted to force atomicity.

Mmm yes, good point. Done.

> It looks like we really want to push the `membar()`-s down to `LIRGenerator`, though. Especially as AArch64 emits more membars on top:

Yes, that's WIP, waiting for this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3371519513

From mli at openjdk.org  Mon Oct  6 13:40:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 6 Oct 2025 13:40:03 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>
Message-ID: <LeZiwW5tZ-CXHfCh9YuNJ3XQAn8-MmZta2NpLQ4cN3o=.55b872bd-20e8-4da7-bf79-cb5f3e3908fb@github.com>

On Mon, 6 Oct 2025 12:28:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hey, I don't get the premise.
> 
> VMVersion have a bunch of methods e.g VM_Version::supports_data_cache_line_flush() / VM_Version::get_current_sve_vector_length, etc.... Now we call some of them "non_ext_UnalignedScalar()", why ? And how is this a improvement ?
> 
> VM_Version methods is not related to whatever or not some information we need is part of an RVI extension.
> 
> E.g. VMVersion::unaligned_scalar() (hotspot don't do camel case) seems more reasonable.

I don't have a preference to the name, either `unaligned_scalar` or `non_ext_UnalignedScalar`. Let's see how others think about it, then I'll modify accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3371708640

From shade at openjdk.org  Mon Oct  6 13:40:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 13:40:03 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v3]
In-Reply-To: <l7BCHhGpiM3mluSdLn1LegP4eaoBepuY-kwiPBaRTys=.add3188b-127b-4b17-b00d-79f826c9700b@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <l7BCHhGpiM3mluSdLn1LegP4eaoBepuY-kwiPBaRTys=.add3188b-127b-4b17-b00d-79f826c9700b@github.com>
Message-ID: <01lDsKijaHMjvU4cToqLkrIgATtE9FeWkeufUh5jtVA=.1da1b4f6-42d0-4f09-9a5b-1e4147bed54c@github.com>

On Mon, 6 Oct 2025 13:06:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review feeback
>  - Review feeback

There is a comment suggestion from Dean, otherwise it looks ready.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3304705877

From shade at openjdk.org  Mon Oct  6 13:40:07 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 13:40:07 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v2]
In-Reply-To: <1ka3dGAl0S2Nv5QX9JDun3AGwDdVOFlGXmI3Fc2U8CU=.c7f44432-2f91-4c3c-a9cf-d7f712d4d3af@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <2T6nVTK6gqOnFJkm2cGf2gcy3EVwWHB8TXAjsyvilw0=.82dea076-7fc9-4475-b67c-26c39d348a73@github.com>
 <1ka3dGAl0S2Nv5QX9JDun3AGwDdVOFlGXmI3Fc2U8CU=.c7f44432-2f91-4c3c-a9cf-d7f712d4d3af@github.com>
Message-ID: <Y0_KxeiUPZ9OTk3sMtSDxlvY3i32fJi7t7gi79UlkUY=.0b75b73a-fe7c-4351-a49a-28f723ea5f96@github.com>

On Thu, 2 Oct 2025 22:22:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Next try
>
> src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 45:
> 
>> 43: // The JMM requires atomicity for all accesses to fields of primitive
>> 44: // types other than double and long. In practice, HotSpot assumes that
>> 45: // on all all processors, accesses to memory operands of wordSize and
> 
> Suggestion:
> 
> // on all processors, accesses to memory operands of wordSize and

^^^

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27432#discussion_r2406363375

From jcking at openjdk.org  Mon Oct  6 14:04:04 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 14:04:04 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers
Message-ID: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>

Add store barrier at the appropriate place in `JavaFrameAnchor::copy`. Move `sp` store to be last in `MacroAssembler::set_last_Java_frame`. Add `dmb ISHST` to `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.

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

Commit messages:
 - Update comments
 - JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers

Changes: https://git.openjdk.org/jdk/pull/27645/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369190
  Stats: 22 lines in 2 files changed: 15 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27645/head:pull/27645

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

From alanb at openjdk.org  Mon Oct  6 14:10:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Oct 2025 14:10:34 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
Message-ID: <7cSeWafk5WIAtnmaDBStH8a3bqx0PwecHIdPv0gK62c=.2eff8fb5-ec8e-4d8c-9d4b-305dabdd57ec@github.com>

On Mon, 29 Sep 2025 10:19:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RemoveFields(duration) and filter internal frames
>
> test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 100:
> 
>> 98:         testExecutableJar(jarFile, "testUnreflectSetter")
>> 99:                 .shouldNotContain(WARNING_LINE1)
>> 100:                 .shouldNotContain(WARNING_UNREFLECTED)
> 
> We test
> 
> * `manifest={mutation=allow}` & `cliOpts={}`, and
> * `manifest={mutation=allow}` & `cliOpts={mutation=deny}`.
> 
> Shall we also add a test with `manifest={}` & `cliOpts={mutation=allow}`? That is, in the absence of a manifest entry, do command line arguments still apply?

The test is to check that `Enable-Final-Field-Mutation: ALL-UNNAMED` works like -`-enable-final-field-mutation=ALL-UNNAMED`.  cli/CommandLineTest.java will test the CLI option. So I think we have reasonable coverage here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2406550210

From ayang at openjdk.org  Mon Oct  6 14:13:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 14:13:36 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
Message-ID: <Mrp6vRYKL2cC0KQx2AMV22Kx8TJqJNM2A7S94EEInII=.90930ea6-cca4-4803-be0c-61723cf7feb2@github.com>

On Mon, 6 Oct 2025 12:20:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
> 
> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/g1RootProcessor.hpp line 54:

> 52:   NMethodMarkingScope _nmethod_marking_scope;
> 53:   ThreadsClaimTokenScope _threads_claim_token_scope;
> 54:   bool _is_parallel;

I would have used `uint _num_workers`, but I guess this also works.

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

PR Review: https://git.openjdk.org/jdk/pull/27644#pullrequestreview-3304938799
PR Review Comment: https://git.openjdk.org/jdk/pull/27644#discussion_r2406562709

From ayang at openjdk.org  Mon Oct  6 14:26:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 14:26:19 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately
In-Reply-To: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
Message-ID: <txrMe5zYutDYt1tU_HvR1id-I2rZQrnzVjHiY-KIZw0=.e3bb2ffa-ca11-4896-aca6-a9757942d784@github.com>

On Mon, 6 Oct 2025 12:51:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important.

Then, is it possible to keep the original API for "most use cases"? For others, they can query `is_containerized` and new `machine_` APIs.

The current proposed API kind of forces all users to distinguish btw inside a container or not, even though most use cases don't care.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3371953487

From fandreuzzi at openjdk.org  Mon Oct  6 14:33:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 6 Oct 2025 14:33:42 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <Mrp6vRYKL2cC0KQx2AMV22Kx8TJqJNM2A7S94EEInII=.90930ea6-cca4-4803-be0c-61723cf7feb2@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
 <Mrp6vRYKL2cC0KQx2AMV22Kx8TJqJNM2A7S94EEInII=.90930ea6-cca4-4803-be0c-61723cf7feb2@github.com>
Message-ID: <xkAUxRIpHAJb6VuBPzuFv9zw_2jMb6GWsH6KvG8_3fw=.6b62758b-1119-46dc-9c80-681c65b667fd@github.com>

On Mon, 6 Oct 2025 14:10:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
>> 
>> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
>> - `active_workers ` is guaranteed to be `> 0`
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> src/hotspot/share/gc/g1/g1RootProcessor.hpp line 54:
> 
>> 52:   NMethodMarkingScope _nmethod_marking_scope;
>> 53:   ThreadsClaimTokenScope _threads_claim_token_scope;
>> 54:   bool _is_parallel;
> 
> I would have used `uint _num_workers`, but I guess this also works.

We don't need to know how many workers there are, just if we are parallel or not. I think this goes in the same direction as the idea of the PR, being clear about what we actually need

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27644#discussion_r2406680110

From cnorrbin at openjdk.org  Mon Oct  6 14:39:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 6 Oct 2025 14:39:44 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately
In-Reply-To: <txrMe5zYutDYt1tU_HvR1id-I2rZQrnzVjHiY-KIZw0=.e3bb2ffa-ca11-4896-aca6-a9757942d784@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <txrMe5zYutDYt1tU_HvR1id-I2rZQrnzVjHiY-KIZw0=.e3bb2ffa-ca11-4896-aca6-a9757942d784@github.com>
Message-ID: <i_sGAdg9ZhtC-Ox2JFym4lZ7ekPrSH23Yp1K0Da4Sw8=.da3a4dd7-c98d-4823-9183-f91b6a96d32c@github.com>

On Mon, 6 Oct 2025 14:23:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Then, is it possible to keep the original API for "most use cases"? For others, they can query `is_containerized` and new `machine_` APIs.
> 
> The current proposed API kind of forces all users to distinguish btw inside a container or not, even though most use cases don't care.

The original API is untouched, so "most use cases" can still use that without ever worrying about containers. The `machine_` functions is simply an add-on to that API. Both the examples above remain unchanged, `os:: active_processor_count()` still returns both machine/container values, and `os::physical_memory()` still returns the appropriate memory limit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3372029042

From cnorrbin at openjdk.org  Mon Oct  6 14:48:29 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 6 Oct 2025 14:48:29 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
Message-ID: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>

> Hi everyone,
> 
> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
> 
> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
> 
> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
> 
> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
> 
> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
> 
> Testing:
> - Oracle tiers 1-5
> - Container tests on cgroup v1 and v2 hosts.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  Fixed print type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27646/files
  - new: https://git.openjdk.org/jdk/pull/27646/files/18527102..e59ff7c4

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

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

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

From aph at openjdk.org  Mon Oct  6 15:31:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 15:31:02 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v4]
In-Reply-To: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
Message-ID: <_rmzcPpWOYHtwoUvUXMY2gcOMlt_m_HCguEcOPWWeVA=.79cc7e8b-7ad4-4b39-b833-c7147a57bf00@github.com>

> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
> 
> We need this in order to allow progress on JDK-8365147.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
  
  Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27432/files
  - new: https://git.openjdk.org/jdk/pull/27432/files/7399fc59..e4cdd74b

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

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

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

From aph at openjdk.org  Mon Oct  6 15:31:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 15:31:02 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v4]
In-Reply-To: <_rmzcPpWOYHtwoUvUXMY2gcOMlt_m_HCguEcOPWWeVA=.79cc7e8b-7ad4-4b39-b833-c7147a57bf00@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <_rmzcPpWOYHtwoUvUXMY2gcOMlt_m_HCguEcOPWWeVA=.79cc7e8b-7ad4-4b39-b833-c7147a57bf00@github.com>
Message-ID: <Qhi0PxWnAAozmVDh_xEx94YZuW-i04MYq7po5gRCKgY=.556a6664-3433-47e1-83b1-524a37135554@github.com>

On Mon, 6 Oct 2025 15:28:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
>   
>   Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

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

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3305479104

From aph at openjdk.org  Mon Oct  6 15:33:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 15:33:09 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>

On Mon, 6 Oct 2025 12:35:44 GMT, Justin King <jcking at openjdk.org> wrote:

> Add store barrier at the appropriate place in `JavaFrameAnchor::copy`. Move `sp` store to be last in `MacroAssembler::set_last_Java_frame`. Add `dmb ISHST` to `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.

src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 43:

> 41:   void clear(void) {
> 42:     // Must clear sp first and place a store-store barrier (dmb ISHST) immediately after,
> 43:     // to ensure ACGT does not observe a corrupted frame.

What is ACGT that you want to slow down AArch64 HotSpot for it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407033608

From jcking at openjdk.org  Mon Oct  6 15:41:24 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 15:41:24 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers
In-Reply-To: <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>
Message-ID: <R26OJApNtNBAeyE0AEV9v8Ak9RHTRd9XjaAblbGmJ2I=.a1c1e0b3-7e4a-4f56-a827-f45fec8d555e@github.com>

On Mon, 6 Oct 2025 15:30:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Add store barrier at the appropriate place in `JavaFrameAnchor::copy`. Move `sp` store to be last in `MacroAssembler::set_last_Java_frame`. Add `dmb ISHST` to `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.
>
> src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 43:
> 
>> 41:   void clear(void) {
>> 42:     // Must clear sp first and place a store-store barrier (dmb ISHST) immediately after,
>> 43:     // to ensure ACGT does not observe a corrupted frame.
> 
> What is ACGT that you want to slow down AArch64 HotSpot for it?

`AsyncGetCallTrace`, meant `AGCT`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407078098

From ayang at openjdk.org  Mon Oct  6 15:53:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 6 Oct 2025 15:53:38 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately
In-Reply-To: <i_sGAdg9ZhtC-Ox2JFym4lZ7ekPrSH23Yp1K0Da4Sw8=.da3a4dd7-c98d-4823-9183-f91b6a96d32c@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <txrMe5zYutDYt1tU_HvR1id-I2rZQrnzVjHiY-KIZw0=.e3bb2ffa-ca11-4896-aca6-a9757942d784@github.com>
 <i_sGAdg9ZhtC-Ox2JFym4lZ7ekPrSH23Yp1K0Da4Sw8=.da3a4dd7-c98d-4823-9183-f91b6a96d32c@github.com>
Message-ID: <4kAv_UH8ouZkj4MWz0WR-vtQOZCdabwTu6NiQlXBVU8=.75f39d01-91d5-40f1-9954-80c14b6b90fa@github.com>

On Mon, 6 Oct 2025 14:36:49 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> The original API is untouched, ...

I see; I misunderstood the proposal. Then, there are 3 sets of public APIs, generic, machine_, and container_. I'd expect most use the generic ones and some might query the machine_ ones, so I don't see much need for container_ ones to be public APIs. YMMV.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3372426233

From bmaillard at openjdk.org  Mon Oct  6 15:55:19 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Mon, 6 Oct 2025 15:55:19 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v14]
In-Reply-To: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
Message-ID: <AQ9c0Bp5Axw8tM9_sD7yrlKrFM5QM-VCHj74HhMkIVY=.7bd87e2e-fe50-42c1-be4d-4a17692b58fd@github.com>

> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
> 
> ## Usage
> 
> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
> that we compile `square` with C2.
> 
> class Square {
>     static int square(int a) {
>         return a * a;
>     }
> 
>     public static void main(String[] args) {
>         square(9);
>     }
> }
> 
> 
> We would like to inspect the node that contains the value returned in this method.
> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
> 
> ```c++
> void Compile::return_values(JVMState* jvms) {
>   GraphKit kit(jvms);
>   Node* ret = new ReturnNode(TypeFunc::Parms,
>                              kit.control(),
>                              kit.i_o(),
>                              kit.reset_memory(),
>                              kit.frameptr(),
>                              kit.returnadr());
>   // Add zero or 1 return values
>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
> 
>   
>   Node* return_value;
>   if (ret_size > 0) {
>     kit.inc_sp(-ret_size);  // pop the return value(s)
>     kit.sync_jvms();
>     return_value = kit.argument(0);
>     ret->add_req(return_value);
> 
>     // <-------------------- Simply insert this
>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>   }
>   
>   // bind it to root
>   root()->add_req(ret);
>   record_for_igvn(ret);
>   initial_gvn()->transform(ret);
> }
> 
> 
> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
> and we get the following output:
> 
> 
> return:
> int 81
> 
> 
> This case is of course trivial, but more useful examples are shown later.
> 
> ## Implementation
> 
> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
> 
> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor.
> 
> The first argument to the runtime printing method is the printing message, a static string encoded as a `...

Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:

  Add assert for MultiBranchNode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26475/files
  - new: https://git.openjdk.org/jdk/pull/26475/files/f41b23fe..09505780

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

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

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

From bmaillard at openjdk.org  Mon Oct  6 15:55:20 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Mon, 6 Oct 2025 15:55:20 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v12]
In-Reply-To: <IWkxli81o4UoMq706P3sKvcu7bIY8wSLIivguYmikzE=.bdfba3d4-969a-4089-a774-f9e4e9744c61@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <RLs5mGrIUcX_NGm8GXAylcALzTq0aoGk-Q9OGPfO4U0=.ec011b47-dd99-4bc8-9d2d-968c53cdd5ff@github.com>
 <xHw3CXqraqFsv2JrbNXfFT3fjhC6CwJdFRFjBdEmPRU=.dd267441-1301-46e7-a868-d0a562cb712c@github.com>
 <9O9QeEqO0ZmaT4FmjroS0XIGgrTdZrzZEPQY8TEI_OQ=.b240cdbe-5565-4d7b-8e28-ca306d5c12a4@github.com>
 <6fuddGArO-vzDhPQ0IHlovlo3xqNDWiSZIzgw7ABT4c=.9c607eec-b4f0-45e1-9745-631282164704@github.com>
 <iHMe9TxqSGUWGWAxt9RzWCab0wi6Zmgh-iObgJmcY58=.e315f2dd-5fc5-4039-9319-4c2d687bbc95@github.com>
 <IWkxli81o4UoMq706P3sKvcu7bIY8wSLIivguYmikzE=.bdfba3d4-969a-4089-a774-f9e4e9744c61@github.com>
Message-ID: <eF-dRLQhoprF4Z47t5lrxKj0yua3KGvGEqIq8vboVcA=.906245d0-c06f-4dab-8641-770d0c08ce41@github.com>

On Fri, 3 Oct 2025 14:44:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I have run all the examples I have, and I have found that the only time this path is executed is when we reach the `StartNode`. I would leave it as it is just in case. What do you think?
>
> I suggest to add `assert(!n->is_MultiBranch(), "unexpected node: %s", n->Name());`  if you are sure we never see such nodes here.

Done, thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2407146600

From rehn at openjdk.org  Mon Oct  6 15:58:11 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 6 Oct 2025 15:58:11 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <LeZiwW5tZ-CXHfCh9YuNJ3XQAn8-MmZta2NpLQ4cN3o=.55b872bd-20e8-4da7-bf79-cb5f3e3908fb@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>
 <LeZiwW5tZ-CXHfCh9YuNJ3XQAn8-MmZta2NpLQ4cN3o=.55b872bd-20e8-4da7-bf79-cb5f3e3908fb@github.com>
Message-ID: <3hkT1x_jjhRREPVpaTZpAyZBBN36emMP3H5MLcWesdw=.51f5666c-03f7-44b1-9c69-f63308bc05da@github.com>

On Mon, 6 Oct 2025 13:37:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Hey, I don't get the premise.
> > VMVersion have a bunch of methods e.g VM_Version::supports_data_cache_line_flush() / VM_Version::get_current_sve_vector_length, etc.... Now we call some of them "non_ext_UnalignedScalar()", why ? And how is this a improvement ?
> > VM_Version methods is not related to whatever or not some information we need is part of an RVI extension.
> > E.g. VMVersion::unaligned_scalar() (hotspot don't do camel case) seems more reasonable.
> 
> I don't have a preference to the name, either `unaligned_scalar` or `non_ext_UnalignedScalar`. Let's see how others think about it, then I'll modify accordingly.


Camel case is not an opinon: "and function names are lower-case (foo_bar). (For these, avoid mixing in upper case letters.)"
https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names
See e.g. : https://github.com/openjdk/jdk/blob/b6a4cfecb731615b6ef70828ac10fae4b2264cdc/src/hotspot/share/runtime/abstract_vm_version.hpp

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3372451008

From jcking at openjdk.org  Mon Oct  6 16:04:56 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:04:56 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers [v2]
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <LWwOAfl_GDStjXk6-I7Ox2M2Ee5s2EW1XEAPAV465uE=.de51a1c1-2c42-442a-993d-d9b68742c09f@github.com>

> Add store barrier at the appropriate place in `JavaFrameAnchor::copy`. Move `sp` store to be last in `MacroAssembler::set_last_Java_frame`. Add `dmb ISHST` to `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Rename ACGT -> AGCT
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27645/files
  - new: https://git.openjdk.org/jdk/pull/27645/files/a0058eb4..a1414494

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

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

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

From shade at openjdk.org  Mon Oct  6 16:05:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Oct 2025 16:05:45 GMT
Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict [v4]
In-Reply-To: <_rmzcPpWOYHtwoUvUXMY2gcOMlt_m_HCguEcOPWWeVA=.79cc7e8b-7ad4-4b39-b833-c7147a57bf00@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
 <_rmzcPpWOYHtwoUvUXMY2gcOMlt_m_HCguEcOPWWeVA=.79cc7e8b-7ad4-4b39-b833-c7147a57bf00@github.com>
Message-ID: <AAnncxjgsNDCRRGMv8YfKSBw-9lG4vUDnGWMT1feXfU=.54c9364a-64fe-4461-99bb-8aa3eb3de5b7@github.com>

On Mon, 6 Oct 2025 15:31:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
>> 
>> We need this in order to allow progress on JDK-8365147.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
>   
>   Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27432#pullrequestreview-3305691185

From jcking at openjdk.org  Mon Oct  6 16:11:42 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:11:42 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers [v2]
In-Reply-To: <R26OJApNtNBAeyE0AEV9v8Ak9RHTRd9XjaAblbGmJ2I=.a1c1e0b3-7e4a-4f56-a827-f45fec8d555e@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>
 <R26OJApNtNBAeyE0AEV9v8Ak9RHTRd9XjaAblbGmJ2I=.a1c1e0b3-7e4a-4f56-a827-f45fec8d555e@github.com>
Message-ID: <FWQgLS0eAElDXP3OkuZqGXDbUOGLiT55KbWGs-P9DBA=.4845b0b2-2a9a-43d8-aaf1-079607f5fb69@github.com>

On Mon, 6 Oct 2025 15:38:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 43:
>> 
>>> 41:   void clear(void) {
>>> 42:     // Must clear sp first and place a store-store barrier (dmb ISHST) immediately after,
>>> 43:     // to ensure ACGT does not observe a corrupted frame.
>> 
>> What is ACGT that you want to slow down AArch64 HotSpot for it?
>
> `AsyncGetCallTrace`, meant `AGCT`.

Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407232782

From aph at openjdk.org  Mon Oct  6 16:21:25 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 16:21:25 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 appears to be missing
 barriers [v2]
In-Reply-To: <FWQgLS0eAElDXP3OkuZqGXDbUOGLiT55KbWGs-P9DBA=.4845b0b2-2a9a-43d8-aaf1-079607f5fb69@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>
 <R26OJApNtNBAeyE0AEV9v8Ak9RHTRd9XjaAblbGmJ2I=.a1c1e0b3-7e4a-4f56-a827-f45fec8d555e@github.com>
 <FWQgLS0eAElDXP3OkuZqGXDbUOGLiT55KbWGs-P9DBA=.4845b0b2-2a9a-43d8-aaf1-079607f5fb69@github.com>
Message-ID: <dzNVXQXXC143yaoMKtP480lL_9ksjBEJYTnkzHIZCLM=.9794efce-af62-4277-811d-135070f9e61c@github.com>

On Mon, 6 Oct 2025 16:08:43 GMT, Justin King <jcking at openjdk.org> wrote:

> Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.

Threads always see their own stores in program order, so no, we don't need store barriers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407277940

From jcking at openjdk.org  Mon Oct  6 16:35:24 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:35:24 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v3]
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <uMx1dymhdp-uUgeOX8Q9NCpnNntmwLcGemIyyAb2SWg=.40e45bcc-d7f1-43e7-a644-084cf9eb22d0@github.com>

> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove barriers and just fix program order for sp store in MacroAssembler
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27645/files
  - new: https://git.openjdk.org/jdk/pull/27645/files/a1414494..253417f9

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

  Stats: 20 lines in 2 files changed: 0 ins; 14 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27645/head:pull/27645

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

From aph at openjdk.org  Mon Oct  6 16:35:25 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 16:35:25 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v3]
In-Reply-To: <uMx1dymhdp-uUgeOX8Q9NCpnNntmwLcGemIyyAb2SWg=.40e45bcc-d7f1-43e7-a644-084cf9eb22d0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <uMx1dymhdp-uUgeOX8Q9NCpnNntmwLcGemIyyAb2SWg=.40e45bcc-d7f1-43e7-a644-084cf9eb22d0@github.com>
Message-ID: <rx8byaKFjQUR2V6CryxoLnOeow64iX5flCP1ynWTh9s=.db7999c6-e44f-4456-a3d6-961ce4cc8b1e@github.com>

On Mon, 6 Oct 2025 16:31:44 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove barriers and just fix program order for sp store in MacroAssembler
>   
>   Signed-off-by: Justin King <jcking at google.com>

Thanks. Add a comment to the effect that we don't need a fence because the profiler always reads from the same thread, and we're done.

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

PR Review: https://git.openjdk.org/jdk/pull/27645#pullrequestreview-3305856488

From jcking at openjdk.org  Mon Oct  6 16:35:26 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:35:26 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v3]
In-Reply-To: <dzNVXQXXC143yaoMKtP480lL_9ksjBEJYTnkzHIZCLM=.9794efce-af62-4277-811d-135070f9e61c@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <yfw3yyW1UaO5wvzQE-4odgVu30QU7LwHCYnm8zYgmRI=.9f55b8fd-3613-4ed3-92c1-fe75862c244e@github.com>
 <R26OJApNtNBAeyE0AEV9v8Ak9RHTRd9XjaAblbGmJ2I=.a1c1e0b3-7e4a-4f56-a827-f45fec8d555e@github.com>
 <FWQgLS0eAElDXP3OkuZqGXDbUOGLiT55KbWGs-P9DBA=.4845b0b2-2a9a-43d8-aaf1-079607f5fb69@github.com>
 <dzNVXQXXC143yaoMKtP480lL_9ksjBEJYTnkzHIZCLM=.9794efce-af62-4277-811d-135070f9e61c@github.com>
Message-ID: <8GOwfUodsm9VlKO1OR315W_UJ0nVBH8vwcqLlSr-ZL4=.76ef7ec4-bcfb-4f74-a318-b97b0db6d590@github.com>

On Mon, 6 Oct 2025 16:19:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.
>
>> Thinking about this, do we "actually" need store barriers at all, so long as the stores are in the correct program order and we put compiler reordering barriers? I assume when the signal is delivered to the thread, all writes are flushed before the signal handler is invoked such that it looks like program order was observed? AGCT is only ever used from the current thread.
> 
> Threads always see their own stores in program order, so no, we don't need store barriers.

Okay, updated the PR and issue. Removed the existing unnecesary barriers and just fixed the program order store issue in `MacroAssembler::set_last_Java_frame` to set `sp` last.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407329318

From jcking at openjdk.org  Mon Oct  6 16:38:51 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:38:51 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>

> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to JavaFrameAnchor regarding no need for fencing
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27645/files
  - new: https://git.openjdk.org/jdk/pull/27645/files/253417f9..016769df

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

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

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

From jcking at openjdk.org  Mon Oct  6 16:38:52 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 16:38:52 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v3]
In-Reply-To: <rx8byaKFjQUR2V6CryxoLnOeow64iX5flCP1ynWTh9s=.db7999c6-e44f-4456-a3d6-961ce4cc8b1e@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <uMx1dymhdp-uUgeOX8Q9NCpnNntmwLcGemIyyAb2SWg=.40e45bcc-d7f1-43e7-a644-084cf9eb22d0@github.com>
 <rx8byaKFjQUR2V6CryxoLnOeow64iX5flCP1ynWTh9s=.db7999c6-e44f-4456-a3d6-961ce4cc8b1e@github.com>
Message-ID: <jzfwJk6uqZEZ2JGTuhvJObMhH0IFWbzwU3MrOhGW57M=.b134eb59-af60-4372-8e61-9fbc86d573a8@github.com>

On Mon, 6 Oct 2025 16:29:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Thanks. Add a comment to the effect that we don't need a fence because the profiler always reads from the same thread, and we're done.

Done. Let me know if you had something else in mind where you wanted the comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/27645#issuecomment-3372714886

From aph at openjdk.org  Mon Oct  6 16:43:23 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 16:43:23 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
Message-ID: <fBlCACeCMmkouKKh8vFRuODIOkn-50S_n05Odp9a4OY=.4158619c-a1f0-456e-9974-8eae7debcac0@github.com>

On Mon, 6 Oct 2025 16:38:51 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to JavaFrameAnchor regarding no need for fencing
>   
>   Signed-off-by: Justin King <jcking at google.com>

Good.

Although in the end we don't need a fence, you prompted me to measure the difference between a releasing store (STLR) and a DMB ST; STR and to my surprise STLR is way faster, at least on Apple hardware.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27645#pullrequestreview-3305930035

From sgehwolf at openjdk.org  Mon Oct  6 16:45:22 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 6 Oct 2025 16:45:22 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <21KzYpwqo0LhSZS_jUfAvjaGnimucGaGcDZSWWTTMto=.01be3f79-137d-4af4-9964-76522b28750a@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

This will conflict mightily with the refactoring that I'm working on for https://bugs.openjdk.org/browse/JDK-8365606

src/hotspot/share/runtime/os.cpp line 2226:

> 2224: 
> 2225: double os::container_processor_count() {
> 2226:   assert(is_containerized(), "must be running containerized");

This is the equivalent of `assert(false)`. Shouldn't this be `ShouldNotReachHere()`?

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

PR Review: https://git.openjdk.org/jdk/pull/27646#pullrequestreview-3305915921
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2407367977

From aph at openjdk.org  Mon Oct  6 16:47:21 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 16:47:21 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
Message-ID: <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>

On Mon, 6 Oct 2025 16:38:51 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to JavaFrameAnchor regarding no need for fencing
>   
>   Signed-off-by: Justin King <jcking at google.com>

Sorry, approval rescinded.

src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 44:

> 42:     // clearing _last_Java_sp must be first
> 43:     _last_Java_sp = nullptr;
> 44:     OrderAccess::release();

You still need a compiler fence here.

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

Changes requested by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27645#pullrequestreview-3305952362
PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2407395441

From kvn at openjdk.org  Mon Oct  6 16:53:18 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Oct 2025 16:53:18 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v14]
In-Reply-To: <AQ9c0Bp5Axw8tM9_sD7yrlKrFM5QM-VCHj74HhMkIVY=.7bd87e2e-fe50-42c1-be4d-4a17692b58fd@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <AQ9c0Bp5Axw8tM9_sD7yrlKrFM5QM-VCHj74HhMkIVY=.7bd87e2e-fe50-42c1-be4d-4a17692b58fd@github.com>
Message-ID: <1uYO9Pdr-7QUZ4i68Y1uXwvksBib3RT03eC4Rcj70sg=.8b0d9c56-fb98-4a46-96ee-d6ff24d2c320@github.com>

On Mon, 6 Oct 2025 15:55:19 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
>> 
>> ## Usage
>> 
>> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
>> that we compile `square` with C2.
>> 
>> class Square {
>>     static int square(int a) {
>>         return a * a;
>>     }
>> 
>>     public static void main(String[] args) {
>>         square(9);
>>     }
>> }
>> 
>> 
>> We would like to inspect the node that contains the value returned in this method.
>> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
>> 
>> ```c++
>> void Compile::return_values(JVMState* jvms) {
>>   GraphKit kit(jvms);
>>   Node* ret = new ReturnNode(TypeFunc::Parms,
>>                              kit.control(),
>>                              kit.i_o(),
>>                              kit.reset_memory(),
>>                              kit.frameptr(),
>>                              kit.returnadr());
>>   // Add zero or 1 return values
>>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
>> 
>>   
>>   Node* return_value;
>>   if (ret_size > 0) {
>>     kit.inc_sp(-ret_size);  // pop the return value(s)
>>     kit.sync_jvms();
>>     return_value = kit.argument(0);
>>     ret->add_req(return_value);
>> 
>>     // <-------------------- Simply insert this
>>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>>   }
>>   
>>   // bind it to root
>>   root()->add_req(ret);
>>   record_for_igvn(ret);
>>   initial_gvn()->transform(ret);
>> }
>> 
>> 
>> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
>> and we get the following output:
>> 
>> 
>> return:
>> int 81
>> 
>> 
>> This case is of course trivial, but more useful examples are shown later.
>> 
>> ## Implementation
>> 
>> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
>> 
>> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ...
>
> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert for MultiBranchNode

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3305985721

From aph at openjdk.org  Mon Oct  6 16:56:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 16:56:11 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions
Message-ID: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>

RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.

While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.

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

Commit messages:
 - Tmp
 - Tmp
 - Devirtualize AArch64 RelocActions
 - Seems to work

Changes: https://git.openjdk.org/jdk/pull/27649/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369211
  Stats: 111 lines in 1 file changed: 5 ins; 36 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/27649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27649/head:pull/27649

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

From tanin47 at gmail.com  Mon Oct  6 17:30:18 2025
From: tanin47 at gmail.com (Tanin Na Nakorn)
Date: Mon, 6 Oct 2025 10:30:18 -0700
Subject: pthread_jit_write_protect_np(0) crashes if
 com.apple.security.cs.allow-jit
 isn't enabled on Mac (aarch64) (with a zero-variant JDK)
Message-ID: <CAAdYQOH-aLbYswCVYSW90NfkcNXnDwtYPejJbX2Qj2L=8M1fGg@mail.gmail.com>

Hello all,

I was building a Java app on Mac (aarch64) and trying to find a way to
avoid com.apple.security.cs.allow-jit using the zero-variant JDK 21, which
doesn't use JIT.

I've found that pthread_jit_write_protect_np(0) (invoked in threads.cpp,
line 430, through os::current_thread_enable_wx(WXWrite)) crashes if
com.apple.security.cs.allow-jit isn't enabled. It seems this method is
called regardless of the variant.

I have a few questions around this:

1. Does this mean a sandboxed Java app on Mac will always require
com.apple.security.cs.allow-jit? Is there a way around this? For example,
is there a way to avoid using pthread_jit_write_protect_np(0) in the zero
variant?

2. It seems like the term JIT has different meanings for Java and Apple
where, for Java, it means not to use compiler1 and compiler 2. But, for
Mac, it means something else e.g. never use pthread_jit_write_protect_np(0)
and generate code.

I'm still new to all this, so I might misunderstand something. Would love
some insights around this area.

Thank you so much!
Tanin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251006/3341ecdd/attachment-0001.htm>

From aph-open at littlepinkcloud.com  Mon Oct  6 17:55:33 2025
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 6 Oct 2025 18:55:33 +0100
Subject: pthread_jit_write_protect_np(0) crashes if
 com.apple.security.cs.allow-jit isn't enabled on Mac (aarch64) (with a
 zero-variant JDK)
In-Reply-To: <CAAdYQOH-aLbYswCVYSW90NfkcNXnDwtYPejJbX2Qj2L=8M1fGg@mail.gmail.com>
References: <CAAdYQOH-aLbYswCVYSW90NfkcNXnDwtYPejJbX2Qj2L=8M1fGg@mail.gmail.com>
Message-ID: <54c12388-d855-47c8-9df0-4dff6a515a1f@littlepinkcloud.com>

On 06/10/2025 18:30, Tanin Na Nakorn wrote:
> 1. Does this mean?a sandboxed Java app on Mac will always require 
> com.apple.security.cs.allow-jit? 

No, it just means that no one tried it.

> Is there a way around this? For 
> example, is there a way to avoid using pthread_jit_write_protect_np(0) 
> in the zero variant?

Sure, just wrap the call in #ifndef ZERO.

> 2. It seems like the term JIT has different meanings for Java and Apple 
> where, for Java, it means not to use compiler1 and compiler 2. But, for 
> Mac, it means something else e.g. never use 
> pthread_jit_write_protect_np(0) and generate code.

That sounds right. Even with no compiler, AArch64 HotSpot still will 
generate an interpreter, and that's effectively JIT as far as Apple is 
concerned.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mli at openjdk.org  Mon Oct  6 18:46:13 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 6 Oct 2025 18:46:13 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <3hkT1x_jjhRREPVpaTZpAyZBBN36emMP3H5MLcWesdw=.51f5666c-03f7-44b1-9c69-f63308bc05da@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>
 <LeZiwW5tZ-CXHfCh9YuNJ3XQAn8-MmZta2NpLQ4cN3o=.55b872bd-20e8-4da7-bf79-cb5f3e3908fb@github.com>
 <3hkT1x_jjhRREPVpaTZpAyZBBN36emMP3H5MLcWesdw=.51f5666c-03f7-44b1-9c69-f63308bc05da@github.com>
Message-ID: <iCr_kzIg-bq3UV705JTzuqJeTgsSX6ubcntrV67v0N4=.913cbd93-b631-4000-9227-651dd5c5d59a@github.com>

On Mon, 6 Oct 2025 15:55:36 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Camel case is not an opinion: "and function names are lower-case (foo_bar). (For these, avoid mixing in upper case letters.)" https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names See e.g. : https://github.com/openjdk/jdk/blob/b6a4cfecb731615b6ef70828ac10fae4b2264cdc/src/hotspot/share/runtime/abstract_vm_version.hpp

Make sense, will update it together later.

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

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3373339738

From tanin47 at gmail.com  Mon Oct  6 18:54:19 2025
From: tanin47 at gmail.com (Tanin Na Nakorn)
Date: Mon, 6 Oct 2025 11:54:19 -0700
Subject: pthread_jit_write_protect_np(0) crashes if
 com.apple.security.cs.allow-jit
 isn't enabled on Mac (aarch64) (with a zero-variant JDK)
In-Reply-To: <54c12388-d855-47c8-9df0-4dff6a515a1f@littlepinkcloud.com>
References: <CAAdYQOH-aLbYswCVYSW90NfkcNXnDwtYPejJbX2Qj2L=8M1fGg@mail.gmail.com>
 <54c12388-d855-47c8-9df0-4dff6a515a1f@littlepinkcloud.com>
Message-ID: <CAAdYQOGKpLd_gj7-of80ysHpiEqYyrvwb+Yw2izyfQNXGTUB8A@mail.gmail.com>

Is there a plan to make the zero variant to comply with the no JIT
definition from Apple? Or is it a no-go since JVM may depend heavily on
this mechanism? (I'm unfamiliar with the area and would like to understand
a bit more.)

> Sure, just wrap the call in #ifndef ZERO.

I tried commenting it out completely. It failed on being unable to reserve
code cache. The mechanism seems to be essential.

> That sounds right. Even with no compiler, AArch64 HotSpot still will
generate an interpreter, and that's effectively JIT as far as Apple is
concerned.

Thank you so much. This insight is helpful.


On Mon, Oct 6, 2025 at 10:55?AM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 06/10/2025 18:30, Tanin Na Nakorn wrote:
> > 1. Does this mean a sandboxed Java app on Mac will always require
> > com.apple.security.cs.allow-jit?
>
> No, it just means that no one tried it.
>
> > Is there a way around this? For
> > example, is there a way to avoid using pthread_jit_write_protect_np(0)
> > in the zero variant?
>
> Sure, just wrap the call in #ifndef ZERO.
>
> > 2. It seems like the term JIT has different meanings for Java and Apple
> > where, for Java, it means not to use compiler1 and compiler 2. But, for
> > Mac, it means something else e.g. never use
> > pthread_jit_write_protect_np(0) and generate code.
>
> That sounds right. Even with no compiler, AArch64 HotSpot still will
> generate an interpreter, and that's effectively JIT as far as Apple is
> concerned.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251006/fab23c30/attachment-0001.htm>

From sjohanss at openjdk.org  Mon Oct  6 19:19:50 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 6 Oct 2025 19:19:50 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v3]
In-Reply-To: <IKmKae-iuleUlT-36N0LTCZNgzaL_21BBHNxgISciE4=.25894c11-aa83-4366-b0fb-11b2ec6d250e@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
 <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com>
 <5dc7WZjOY4ymVSZcN7ixLlg4rGahTo9ObDSwW-xbpRQ=.7c749ebc-4b70-4492-b565-27922bfb9f78@github.com>
 <IKmKae-iuleUlT-36N0LTCZNgzaL_21BBHNxgISciE4=.25894c11-aa83-4366-b0fb-11b2ec6d250e@github.com>
Message-ID: <cp8lKEQq_Xmw6uieuToIUe45eQPlWRCguVs_KE2LGLY=.942339c5-7163-4f49-a033-ed158032cfa3@github.com>

On Sun, 5 Oct 2025 13:34:53 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> Found some time to look closer at this. I would prefer if we could clean up the `Smaps` class even more when moving it to the testlib. We might want to go even further than this:
>> https://github.com/openjdk/jdk/compare/master...kstefanj:jdk:pull/27273-v2
>> 
>> I felt it was easier to show you my ideas this way rather than just giving comment. Some names might need improving and some more polishing, but what do you think about the general structure [here](https://github.com/openjdk/jdk/commit/4550eb677d74803935be64a1cc321c671f91adc7)?
>
> @kstefanj  
> Sorry for the late reply.
> 
> I?ve reviewed the code you wrote, and I think it?s much clearer!
> I?ve updated it with your suggested changes and confirmed that everything works fine in testing.
> 
> //
> 
> Sorry for rebasing ? it?s a habit of mine, and I did it without thinking. I?ll be more careful next time.

@dev-jonghoonpark, thanks for addressing my concerns.

I need to look over it again but I'm traveling this week and will have less time than normal for reviews. I'll see if I can find some time, otherwise I will look at this next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3373496756

From aph at openjdk.org  Mon Oct  6 19:45:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 6 Oct 2025 19:45:47 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>
Message-ID: <gYVr-ObNRt1_XzeuKG7kKQRaHlpd7iC_rE3NDhVsKvo=.95d02b2e-4332-4395-b3f8-1622563899b2@github.com>

On Mon, 6 Oct 2025 16:43:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to JavaFrameAnchor regarding no need for fencing
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 44:
> 
>> 42:     // clearing _last_Java_sp must be first
>> 43:     _last_Java_sp = nullptr;
>> 44:     OrderAccess::release();
> 
> You still need a compiler fence here.

Maybe not, if this is the same thread as readers. I don't know what it's for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2408194924

From jcking at openjdk.org  Mon Oct  6 19:58:50 2025
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Oct 2025 19:58:50 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <gYVr-ObNRt1_XzeuKG7kKQRaHlpd7iC_rE3NDhVsKvo=.95d02b2e-4332-4395-b3f8-1622563899b2@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>
 <gYVr-ObNRt1_XzeuKG7kKQRaHlpd7iC_rE3NDhVsKvo=.95d02b2e-4332-4395-b3f8-1622563899b2@github.com>
Message-ID: <6xPqNdYUdDni24Gw_lENy5koPY5clPcluX03iVMKYnU=.c3f529da-68ca-4a73-b6ea-0600b333b4f6@github.com>

On Mon, 6 Oct 2025 19:43:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 44:
>> 
>>> 42:     // clearing _last_Java_sp must be first
>>> 43:     _last_Java_sp = nullptr;
>>> 44:     OrderAccess::release();
>> 
>> You still need a compiler fence here.
>
> Maybe not, if this is the same thread as readers. I don't know what it's for.

`OrderAccess::release()` is more than a compiler barrier on AArch64. I am guessing this was copied from x86 or one of the others where that same function is a compiler barrier? Should I move `compiler_barrier` from the random source files its in, into globalDefinitions, and use that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2408246891

From johannes.bechberger at sap.com  Mon Oct  6 20:53:47 2025
From: johannes.bechberger at sap.com (Bechberger, Johannes)
Date: Mon, 6 Oct 2025 20:53:47 +0000
Subject: pthread_jit_write_protect_np(0) crashes if
 com.apple.security.cs.allow-jit isn't enabled on Mac (aarch64) (with a
 zero-variant JDK)
In-Reply-To: <CAAdYQOGKpLd_gj7-of80ysHpiEqYyrvwb+Yw2izyfQNXGTUB8A@mail.gmail.com>
References: <CAAdYQOH-aLbYswCVYSW90NfkcNXnDwtYPejJbX2Qj2L=8M1fGg@mail.gmail.com>
 <54c12388-d855-47c8-9df0-4dff6a515a1f@littlepinkcloud.com>
 <CAAdYQOGKpLd_gj7-of80ysHpiEqYyrvwb+Yw2izyfQNXGTUB8A@mail.gmail.com>
Message-ID: <DB5PR02MB10263384803D2C6F3CCCABC30EAE3A@DB5PR02MB10263.eurprd02.prod.outlook.com>

The zero variant is not something that many people spent time on, as there are limited use cases for the variant.

________________________________
From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Tanin Na Nakorn <tanin47 at gmail.com>
Sent: Monday, October 6, 2025 8:54:19 PM
To: Andrew Haley <aph-open at littlepinkcloud.com>
Cc: hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: Re: pthread_jit_write_protect_np(0) crashes if com.apple.security.cs.allow-jit isn't enabled on Mac (aarch64) (with a zero-variant JDK)

You don't often get email from tanin47 at gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Is there a plan to make the zero variant to comply with the no JIT definition from Apple? Or is it a no-go since JVM may depend heavily on this mechanism? (I'm unfamiliar with the area and would like to understand a bit more.)

> Sure, just wrap the call in #ifndef ZERO.

I tried commenting it out completely. It failed on being unable to reserve code cache. The mechanism seems to be essential.

> That sounds right. Even with no compiler, AArch64 HotSpot still will generate an interpreter, and that's effectively JIT as far as Apple is concerned.

Thank you so much. This insight is helpful.


On Mon, Oct 6, 2025 at 10:55?AM Andrew Haley <aph-open at littlepinkcloud.com<mailto:aph-open at littlepinkcloud.com>> wrote:
On 06/10/2025 18:30, Tanin Na Nakorn wrote:
> 1. Does this mean a sandboxed Java app on Mac will always require
> com.apple.security.cs.allow-jit?

No, it just means that no one tried it.

> Is there a way around this? For
> example, is there a way to avoid using pthread_jit_write_protect_np(0)
> in the zero variant?

Sure, just wrap the call in #ifndef ZERO.

> 2. It seems like the term JIT has different meanings for Java and Apple
> where, for Java, it means not to use compiler1 and compiler 2. But, for
> Mac, it means something else e.g. never use
> pthread_jit_write_protect_np(0) and generate code.

That sounds right. Even with no compiler, AArch64 HotSpot still will
generate an interpreter, and that's effectively JIT as far as Apple is
concerned.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251006/2ac6fef7/attachment-0001.htm>

From dholmes at openjdk.org  Tue Oct  7 00:46:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 00:46:57 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
 <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
Message-ID: <VuK3AaZ6zIZmNgnGWk0ydc9wEazGvyHdfWiDVFeurHs=.514d7ab3-2811-4764-99a6-9ca95b20de1b@github.com>

On Sun, 5 Oct 2025 13:49:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.

@AlanBateman yes that is exactly what I am suggesting. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3374751322

From dholmes at openjdk.org  Tue Oct  7 01:08:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 01:08:47 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
Message-ID: <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>

On Fri, 3 Oct 2025 12:39:55 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
>> 
>> Let me walk through an example to see if I have it right:
>> 
>> We have a hybrid system with two sockets, each of which has 6P and 2E cores. Only the P cores have hyper-threading even though the HT bit is set. So the current code would do:
>> 
>> _no_of_threads = 28  // I hope that is what the OS reports: 2 * (6*2 + 2)
>> threads_per_core()  = 2   // because of HT bit
>> cores_per_cpu() = 8
>> threads_per_package = 2 * 8 = 16
>> _no_of_sockets = 28 / 16 = 1   // integer division -> gives wrong answer
>> 
>> with new code:
>> 
>> threads_per_package = 14   // direct from CPUID logical processors
>> _no_of_sockets = 28 / 14 = 12
>
>> Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
> 
> Yes, so I think this PR needs reviewer(s) from HotSpot folks.
> 
>> So the current code would do:
> 
> Unfortunately, no. It would derive wrong number of sockets as following:
> 
> 
> _no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
> threads_per_core()  = 2   // HT enabled
> cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors
> threads_per_package = 14 // 2 threads per core * 7 cores per cpu
> _no_of_sockets = 2 // 28 threads / 14 threads per package
> 
> 
> `cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)).
> 
> 
>   if (is_intel()) {
>     bool supports_topology = supports_processor_topology();
>     if (supports_topology) {
>       result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
>                _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
>     }
> 
> 
> In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`.
> 
> 
> _no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
> threads_per_core()  = 2   // HT enabled
> cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID`
> threads_per_package = 14 // ** different from current implementation ** the value from `CPUID`
> _no_of_sockets = 2 // 28 threads / 14 threads per package
> 
> 
> I uploaded test code for `CPUID` leaf  0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c

Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409066160

From dholmes at openjdk.org  Tue Oct  7 01:13:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 01:13:53 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <Twxggb4LzbmQgmPU0yt7su7yre7Rz0TzJxK3ViqzXK8=.27cc7013-2a93-4a35-b55f-957eba0eafc0@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
 <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
 <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
 <Twxggb4LzbmQgmPU0yt7su7yre7Rz0TzJxK3ViqzXK8=.27cc7013-2a93-4a35-b55f-957eba0eafc0@github.com>
Message-ID: <d4swLsm2NXZBItOsEHsu902d7oWntcfMQox_uq09Mcg=.575a6010-232f-45b9-adb8-e3b5d68d9dc2@github.com>

On Mon, 6 Oct 2025 10:19:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A more accurate way to view Atomic::release_store is that the memory synchronization is intrinsically tied to the store operation ? not before it, not after it. 

It has to be before it in the sense that the store cannot float ahead of the memory synchronization action - otherwise it could be reordered with other stores and that would break things.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3374789698

From dholmes at openjdk.org  Tue Oct  7 01:21:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 01:21:45 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations
In-Reply-To: <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <a2iMXNxEh-e2opxG2-qaXfOpNdL9Kh4UT-WRNV5bkro=.4bc368f4-bb3f-453d-8662-19b8b0e0a1fb@github.com>
Message-ID: <A20vYczKxJSZVNc7Zq6dI96VGB0-_GIHWTVKb6SXLp0=.77fb6612-627c-4be7-8ecc-824610d36360@github.com>

On Fri, 3 Oct 2025 09:02:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> That's only true in the HotSpot API. It's not true for C++ <atomic> or the C equivalent, or in most published papers, where the default for "atomic" loads and stores is sequentially consistent.

Well we were talking about the Hotspot API as it was the default there that you were commenting on. I would suggest that many published papers assume seq-cst so that they can write simplified algorithms for lock-free code that avoids getting bogged down in what, and where, memory barriers are needed. Correct me if I am wrong but my understanding is that assembler level loads/stores are "relaxed" unless you request otherwise.

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

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3374811706

From dholmes at openjdk.org  Tue Oct  7 01:35:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 01:35:46 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

> A user might need the physical cpu count of the machine, but os::active_processor_count() only returns the limited container value, which also represents something slightly different.

That is a mis-characterization of the API. `active_processor_count()` tells you how many logical processors are available to the JVM process. That can be very different to the "physical" (**) number of processors due to partitioning at various levels (e.g. virtualization, containerization), as well as direct restrictions through API's like `taskset`.

(**) "physical" actually has no meaning these days. There is some value you can obtain through the operating system that provides the maximum number of processors that the operating system can see (and thus make available to the JVM).

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3374848444

From egahlin at openjdk.org  Tue Oct  7 01:44:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 Oct 2025 01:44:53 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
Message-ID: <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>

On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Improve CommandLineTest.testWarn
>  - More test cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Expand jni/JNIAttachMutatorTest to final fields in named modules
>  - Merge branch 'master' into JDK-8353835
>  - Test updates based on reviewer feedback
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a

Thanks for adding the RemoveFields and StackFilter annotations to the event.  I believe the filter can be simplified to this     

    @StackFilter({"java.lang.reflect.Field", "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup"})

and then set the offset to 4 or 5 in PlatformEventType::determineStackTraceOffset() to skip the offer method. This is cheaper and probably more robust. It will also make the place where the mutation happens the top frame, similar to other events, which works well for tooling.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3374858793

From dholmes at openjdk.org  Tue Oct  7 01:55:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 01:55:47 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <kE7yoNDQqpOcX3mNuKHmu0Jd5rrTnE1DGieJihFTBVo=.79ff6724-f608-4c3d-be05-a098233bec08@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

What is a "machine" here? Historically we have misused "physical" to mean what does a bare-metal OS report on a bare-metal piece of hardware. But that became inaccurate decades ago once virtualization/hypervisors arrived. So we've adjusted API's (e.g. MXBeans) to report whatever the "operating system" reports. The problem there is some things the operating system reports take into account the presence of containers, and others do not. This has always been a problem with these container environments - they should be invisible to software but they are not.

> To support this, an os::is_containerized function should also be added.

For a long time this was an impossible question to answer accurately  -  we could query whether cgroups were configured on a system but we couldn't ask if the JVM process was running under any cgroup constraints - has that changed?

I would like to get a better idea of what kinds of "machine" information we need to query and how it will be used. I mean, how does it help to know a "machine" has 256 processors if the various software layers only make 16 available to you?

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3374885473

From ysuenaga at openjdk.org  Tue Oct  7 02:34:54 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 02:34:54 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
Message-ID: <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>

On Tue, 7 Oct 2025 01:06:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
>> 
>> Yes, so I think this PR needs reviewer(s) from HotSpot folks.
>> 
>>> So the current code would do:
>> 
>> Unfortunately, no. It would derive wrong number of sockets as following:
>> 
>> 
>> _no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
>> threads_per_core()  = 2   // HT enabled
>> cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors
>> threads_per_package = 14 // 2 threads per core * 7 cores per cpu
>> _no_of_sockets = 2 // 28 threads / 14 threads per package
>> 
>> 
>> `cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)).
>> 
>> 
>>   if (is_intel()) {
>>     bool supports_topology = supports_processor_topology();
>>     if (supports_topology) {
>>       result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
>>                _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
>>     }
>> 
>> 
>> In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`.
>> 
>> 
>> _no_of_threads = 28  // 2 sockets * (6 P-cores * 2 threads + 2 E-cores)
>> threads_per_core()  = 2   // HT enabled
>> cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID`
>> threads_per_package = 14 // ** different from current implementation ** the value from `CPUID`
>> _no_of_sockets = 2 // 28 threads / 14 threads per package
>> 
>> 
>> I uploaded test code for `CPUID` leaf  0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c
>
> Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect.

Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409166531

From dlong at openjdk.org  Tue Oct  7 02:44:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Oct 2025 02:44:51 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
Message-ID: <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>

On Mon, 6 Oct 2025 16:38:51 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to JavaFrameAnchor regarding no need for fencing
>   
>   Signed-off-by: Justin King <jcking at google.com>

src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp line 60:

> 58:     //
> 59:     // No fencing required, the members are declared volatile so the compiler will not reorder and
> 60:     // the profiler always reads from the same thread and should observe the state in program order.

I don't think copy() is ever called.  Can we remove it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2409180328

From fyang at openjdk.org  Tue Oct  7 04:36:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 7 Oct 2025 04:36:02 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
Message-ID: <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>

On Wed, 1 Oct 2025 10:34:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> 
>> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
>> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
>> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
>> 
>> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order RV_NON_EXT_FEATURE_FLAGS

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5877:

> 5875: // you want to use it elsewhere, note that cnt must be >= zicboz_block_size.
> 5876: void MacroAssembler::zero_dcache_blocks(Register base, Register cnt, Register tmp1, Register tmp2) {
> 5877:   int zicboz_block_size = VM_Version::non_ext_ZicbozBlockSize.value();

Hi, I am a bit concerned that the names might be too long. Say you have something like `VM_Version::non_ext_zicboz_block_size`.
How about introducing some extra namespaces if we want to distinguish these two groups (extensions and non-extensions)?
Then we could have something like `VM_Version::non_ext::zicboz_block_size`, `VM_Version::ext::rvi`, `VM_Version::ext::rvm`. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2409313398

From dholmes at openjdk.org  Tue Oct  7 04:46:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 04:46:47 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
Message-ID: <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>

On Tue, 7 Oct 2025 02:32:08 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect.
>
> Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said.

Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that:

int cores_per_cpu() {
  if (is_hybrid()) {
    if (hyper_threaded() ) {
      return _no_of_threads - _no_of_e_cores;
     } else {
      return _no_of_threads;
     }
  } else {
    return _no_of_threads / threads_per_core();
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409331900

From ysuenaga at openjdk.org  Tue Oct  7 05:46:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 05:46:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
 <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
Message-ID: <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>

On Tue, 7 Oct 2025 04:44:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said.
>
> Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that:
> 
> int cores_per_cpu() {
>   if (is_hybrid()) {
>     if (hyper_threaded() ) {
>       return _no_of_threads - _no_of_e_cores;
>      } else {
>       return _no_of_threads;
>      }
>   } else {
>     return _no_of_threads / threads_per_core();
>   }
> }

I think it is difficult for the following reasons:

1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c
2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409430996

From duke at openjdk.org  Tue Oct  7 05:49:48 2025
From: duke at openjdk.org (erifan)
Date: Tue, 7 Oct 2025 05:49:48 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v8]
In-Reply-To: <ledEIa5Cj9jGqJfRfGBCIF6_nvGBw5lG8j2ksYwePs8=.6dd826a7-c935-40be-afea-bd8ed146560f@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ledEIa5Cj9jGqJfRfGBCIF6_nvGBw5lG8j2ksYwePs8=.6dd826a7-c935-40be-afea-bd8ed146560f@github.com>
Message-ID: <_6err-oI7jnkN1zwTDpqBR4Gurfez_OdLJtveJYvORc=.53394d2b-2214-47e1-a87a-1590a356aaab@github.com>

On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update callGenerator.hpp copyright year

@jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks!

src/hotspot/cpu/x86/x86.ad line 10770:

> 10768: %}
> 10769: 
> 10770: instruct vector_slice_const_origin_LT16B_reg(vec dst, vec src1, vec src2, immI origin)

Suggestion:

instruct vector_slice_const_origin_EQ16B_reg(vec dst, vec src1, vec src2, immI origin)


Or

Suggestion:

instruct vector_slice_const_origin_16B_reg(vec dst, vec src1, vec src2, immI origin)

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

PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3308445233
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2409418070

From duke at openjdk.org  Tue Oct  7 05:49:50 2025
From: duke at openjdk.org (erifan)
Date: Tue, 7 Oct 2025 05:49:50 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v8]
In-Reply-To: <yMkNR3nPhpeTop0AxSZMW7f7sIHMYcEvDtwV86IFUVc=.cbbd64f8-ee7a-4dbd-8252-9ab24e39f5ae@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ledEIa5Cj9jGqJfRfGBCIF6_nvGBw5lG8j2ksYwePs8=.6dd826a7-c935-40be-afea-bd8ed146560f@github.com>
 <yMkNR3nPhpeTop0AxSZMW7f7sIHMYcEvDtwV86IFUVc=.cbbd64f8-ee7a-4dbd-8252-9ab24e39f5ae@github.com>
Message-ID: <30EG_sC2od4Xwsibk4Uv1XW_XROt9OtbYSaEDwFmycY=.c2c59c3b-dbfe-4d52-a353-08b7f41bab1d@github.com>

On Thu, 25 Sep 2025 08:52:09 GMT, erifan <duke at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update callGenerator.hpp copyright year
>
> test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 45:
> 
>> 43:     public static final VectorSpecies<Short> SSP = ShortVector.SPECIES_PREFERRED;
>> 44:     public static final VectorSpecies<Integer> ISP = IntVector.SPECIES_PREFERRED;
>> 45:     public static final VectorSpecies<Long> LSP = LongVector.SPECIES_PREFERRED;
> 
> The implementation supports floating point types, but why doesn't the test include fp types?

It might be better to consider **partial cases**. I looked at the aarch64 situation and found that different implementations are needed for partial and non-partial cases. The test indices in `test/jdk/jdk/incubator/vector/` are randomly generated, so it might be better to test different vector species here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2409431981

From rehn at openjdk.org  Tue Oct  7 06:28:48 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Oct 2025 06:28:48 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
Message-ID: <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>

On Tue, 7 Oct 2025 04:32:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   order RV_NON_EXT_FEATURE_FLAGS
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5877:
> 
>> 5875: // you want to use it elsewhere, note that cnt must be >= zicboz_block_size.
>> 5876: void MacroAssembler::zero_dcache_blocks(Register base, Register cnt, Register tmp1, Register tmp2) {
>> 5877:   int zicboz_block_size = VM_Version::non_ext_ZicbozBlockSize.value();
> 
> Hi, I am a bit concerned that the names might be too long. Say you have something like `VM_Version::non_ext_zicboz_block_size`.
> How about introducing some extra namespaces if we want to distinguish these two groups (extensions and non-extensions)?
> Then we could have something like `VM_Version::non_ext::zicboz_block_size`, `VM_Version::ext::rvi`, `VM_Version::ext::rvm`. What do you think?

Yes, maybe.

I just don't understand why vector length is something different than zicboz block size.
E.g.

CacheLineSize                             // gets cache-line size
VM_Version::ext::zic64b();                // gets 64b cache-line size
VM_Version::non_ext::zicboz_block_size(); // gets cache block size
VM_Version::cpu_vector_length();          // private, gets vector register length (HW), should be size not length IMHO
MaxVectorSize                             // gets vector register length (-+ cmd-line)


When I am actually using these value in MASM/stubs/instrinsic/etc.. I don't care where this value came from.
If it's command line or RVI extension or if we with some other mean figured this setting out.

I think it would be nice to try to get a consistent API in VM_Version.
But I don't think that is possible (due to global flags), but I think we can at least do something better here, no?

As it is now it really hard to review as I need to double check if the correct setting was used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2409520786

From bmaillard at openjdk.org  Tue Oct  7 07:06:06 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Tue, 7 Oct 2025 07:06:06 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v11]
In-Reply-To: <JbF8B5-8zuJA_PuGTbX6ae0Iu3nFu9e8bjj_dMVixdc=.16090783-d328-4177-8cf5-e3802fae2e49@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <YHXfwqAq7lsyDgiR0q4_EgbnaHwoew4EBxpmxhVXbf0=.20e86af3-3021-45be-bae4-1d9f1073e0b1@github.com>
 <JbF8B5-8zuJA_PuGTbX6ae0Iu3nFu9e8bjj_dMVixdc=.16090783-d328-4177-8cf5-e3802fae2e49@github.com>
Message-ID: <9Cy7RAbStz7nuwRMSuCii44TqOfwC5LKgl_De6_qrCo=.050f3b5b-fcbd-4fb2-b82f-f10309105ee6@github.com>

On Tue, 30 Sep 2025 07:49:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove implicit null check
>
> This looks good to me and will be handy for future printf-style debugging in compiled code. I could have made good use of this on several occasions in the past. Nice examples!

Thank you for your reviews @TobiHartmann, @mhaessig and @vnkozlov!

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

PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3375476627

From duke at openjdk.org  Tue Oct  7 07:06:09 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 07:06:09 GMT
Subject: RFR: 8360389: Support printing from C2 compiled code [v14]
In-Reply-To: <AQ9c0Bp5Axw8tM9_sD7yrlKrFM5QM-VCHj74HhMkIVY=.7bd87e2e-fe50-42c1-be4d-4a17692b58fd@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
 <AQ9c0Bp5Axw8tM9_sD7yrlKrFM5QM-VCHj74HhMkIVY=.7bd87e2e-fe50-42c1-be4d-4a17692b58fd@github.com>
Message-ID: <zw2GQJ5mk7NRDPubxNRzNSGTMgL7P5XDEO4qgmcHUbs=.6a7733bc-92e6-4356-9e37-940e6a0ac75a@github.com>

On Mon, 6 Oct 2025 15:55:19 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

>> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
>> 
>> ## Usage
>> 
>> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
>> that we compile `square` with C2.
>> 
>> class Square {
>>     static int square(int a) {
>>         return a * a;
>>     }
>> 
>>     public static void main(String[] args) {
>>         square(9);
>>     }
>> }
>> 
>> 
>> We would like to inspect the node that contains the value returned in this method.
>> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
>> 
>> ```c++
>> void Compile::return_values(JVMState* jvms) {
>>   GraphKit kit(jvms);
>>   Node* ret = new ReturnNode(TypeFunc::Parms,
>>                              kit.control(),
>>                              kit.i_o(),
>>                              kit.reset_memory(),
>>                              kit.frameptr(),
>>                              kit.returnadr());
>>   // Add zero or 1 return values
>>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
>> 
>>   
>>   Node* return_value;
>>   if (ret_size > 0) {
>>     kit.inc_sp(-ret_size);  // pop the return value(s)
>>     kit.sync_jvms();
>>     return_value = kit.argument(0);
>>     ret->add_req(return_value);
>> 
>>     // <-------------------- Simply insert this
>>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>>   }
>>   
>>   // bind it to root
>>   root()->add_req(ret);
>>   record_for_igvn(ret);
>>   initial_gvn()->transform(ret);
>> }
>> 
>> 
>> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
>> and we get the following output:
>> 
>> 
>> return:
>> int 81
>> 
>> 
>> This case is of course trivial, but more useful examples are shown later.
>> 
>> ## Implementation
>> 
>> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
>> 
>> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ...
>
> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert for MultiBranchNode

@benoitmaillard 
Your change (at version 0950578074700e278aac14c1c9d050468c091357) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3375481812

From dholmes at openjdk.org  Tue Oct  7 07:10:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 07:10:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
 <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
 <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>
Message-ID: <MbiU7J9_xs0o0DVb_F4Gp-yYbY6_iQl-3i4QmfrO5qk=.2c0b37a2-c88c-4166-bd0c-6bf4ff184c56@github.com>

On Tue, 7 Oct 2025 05:43:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that:
>> 
>> int cores_per_cpu() {
>>   if (is_hybrid()) {
>>     if (hyper_threaded() ) {
>>       return _no_of_threads - _no_of_e_cores;
>>      } else {
>>       return _no_of_threads;
>>      }
>>   } else {
>>     return _no_of_threads / threads_per_core();
>>   }
>> }
>
> I think it is difficult for the following reasons:
> 
> 1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c
> 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future.

Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.

I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.

So where does this leave us?
- `cores_per_cpu` is an approximation
-  anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409613404

From bmaillard at openjdk.org  Tue Oct  7 07:47:02 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Tue, 7 Oct 2025 07:47:02 GMT
Subject: Integrated: 8360389: Support printing from C2 compiled code
In-Reply-To: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
References: <Ga6voT2WHQMulc7JEwT9I87MBdrsq3QCRJCDV1b6DSc=.1626e8d8-9e06-4b62-81b9-c79e0f72e4ca@github.com>
Message-ID: <L6kz-g4vhAkvy0hvnk5-S9esO2DbNE5wCaGYeY1sGO0=.77309eef-c76d-423e-9814-13fbaa56865c@github.com>

On Fri, 25 Jul 2025 09:39:00 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
> 
> ## Usage
> 
> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
> that we compile `square` with C2.
> 
> class Square {
>     static int square(int a) {
>         return a * a;
>     }
> 
>     public static void main(String[] args) {
>         square(9);
>     }
> }
> 
> 
> We would like to inspect the node that contains the value returned in this method.
> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
> 
> ```c++
> void Compile::return_values(JVMState* jvms) {
>   GraphKit kit(jvms);
>   Node* ret = new ReturnNode(TypeFunc::Parms,
>                              kit.control(),
>                              kit.i_o(),
>                              kit.reset_memory(),
>                              kit.frameptr(),
>                              kit.returnadr());
>   // Add zero or 1 return values
>   int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
> 
>   
>   Node* return_value;
>   if (ret_size > 0) {
>     kit.inc_sp(-ret_size);  // pop the return value(s)
>     kit.sync_jvms();
>     return_value = kit.argument(0);
>     ret->add_req(return_value);
> 
>     // <-------------------- Simply insert this
>     C->make_debug_print<jint>("return: ", initial_gvn(), return_value);
>   }
>   
>   // bind it to root
>   root()->add_req(ret);
>   record_for_igvn(ret);
>   initial_gvn()->transform(ret);
> }
> 
> 
> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
> and we get the following output:
> 
> 
> return:
> int 81
> 
> 
> This case is of course trivial, but more useful examples are shown later.
> 
> ## Implementation
> 
> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
> 
> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor.
> 
> The first argument to the runtime printing method is the printing message, a static string encoded as a `...

This pull request has now been integrated.

Changeset: 07549f3e
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07549f3e1539a2dd491a4f9ffe9df8580d7d7dea
Stats:     317 lines in 6 files changed: 317 ins; 0 del; 0 mod

8360389: Support printing from C2 compiled code

Reviewed-by: kvn, thartmann, mhaessig

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

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

From alanb at openjdk.org  Tue Oct  7 08:01:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Oct 2025 08:01:54 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <k6_-Fsk4Q3cQH8q1j3qAVbhkuDQXtWOcBn-c1QyBsFY=.03be8309-396e-46d5-9c0e-d4cf29fd327a@github.com>
Message-ID: <uIxLQJE7F6w8qDRRX1NWF4kc8iHQe5RTNTV0JBTLF-k=.01d912c3-af44-4a02-8d48-b62141fdb20a@github.com>

On Tue, 7 Oct 2025 01:42:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>  I believe the filter can be simplified to this
> 
> ```
> @StackFilter({"java.lang.reflect.Field", "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup"})
> ```
> 
> and then set the offset to 4 or 5 in PlatformEventType::determineStackTraceOffset() to skip the offer method. This is cheaper and probably more robust. It will also make the place where the mutation happens the top frame, similar to other events, which works well for tooling.

The APIs are in Field and Lookup so having the API method as the top frame is useful.  It would be possible to reduce the filter to `{ "java.lang.reflect.ReflectAccess", "java.lang.invoke.MethodHandles$Lookup::unreflectField" }` with determineStackTraceOffset returning 6 but it's too fiddly and requires knowing about two "faraway places" when doing any refactoring. Mutating final fields is the slow path so performance is not a concern. So I think the trade-off to keep it as maintainable as possible is okay. The test checks the top frame and also scans the StackFilter to ensure the class is visible and that any filter value with a method name at least names a method that is declared in the class.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3375647041

From aph at openjdk.org  Tue Oct  7 08:14:27 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 08:14:27 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>
Message-ID: <XTkmae7BFlwck7FmgVC4xu-af9BWuzBMCvjB-KB1QUY=.95629e5e-6657-41d4-ad61-6ed3f3c538dd@github.com>

On Tue, 7 Oct 2025 02:41:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> I don't think copy() is ever called. Can we remove it?

Sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2409785962

From mli at openjdk.org  Tue Oct  7 08:16:28 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 Oct 2025 08:16:28 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
Message-ID: <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>

On Tue, 7 Oct 2025 06:24:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5877:
>> 
>>> 5875: // you want to use it elsewhere, note that cnt must be >= zicboz_block_size.
>>> 5876: void MacroAssembler::zero_dcache_blocks(Register base, Register cnt, Register tmp1, Register tmp2) {
>>> 5877:   int zicboz_block_size = VM_Version::non_ext_ZicbozBlockSize.value();
>> 
>> Hi, I am a bit concerned that the names might be too long. Say you have something like `VM_Version::non_ext_zicboz_block_size`.
>> How about introducing some extra namespaces if we want to distinguish these two groups (extensions and non-extensions)?
>> Then we could have something like `VM_Version::non_ext::zicboz_block_size`, `VM_Version::ext::rvi`, `VM_Version::ext::rvm`. What do you think?
>
> Yes, maybe.
> 
> I just don't understand why vector length is something different than zicboz block size.
> E.g.
> 
> CacheLineSize                             // gets cache-line size
> VM_Version::ext::zic64b();                // gets 64b cache-line size
> VM_Version::non_ext::zicboz_block_size(); // gets cache block size
> VM_Version::cpu_vector_length();          // private, gets vector register length (HW), should be size not length IMHO
> MaxVectorSize                             // gets vector register length (-+ cmd-line)
> 
> 
> When I am actually using these value in MASM/stubs/instrinsic/etc.. I don't care where this value came from.
> If it's command line or RVI extension or if we with some other mean figured this setting out.
> 
> I think it would be nice to try to get a consistent API in VM_Version.
> But I don't think that is possible (due to global flags), but I think we can at least do something better here, no?
> 
> As it is now it really hard to review as I need to double check if the correct setting was used.

Maybe just keep the original names, and use them as pretty too? The code looks like `VM_Version::non_ext::zicboz_block_size()`, and the printed feature "pretty" name would be "zicboz_block_size".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2409791358

From aph at openjdk.org  Tue Oct  7 08:32:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 08:32:58 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <6xPqNdYUdDni24Gw_lENy5koPY5clPcluX03iVMKYnU=.c3f529da-68ca-4a73-b6ea-0600b333b4f6@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>
 <gYVr-ObNRt1_XzeuKG7kKQRaHlpd7iC_rE3NDhVsKvo=.95d02b2e-4332-4395-b3f8-1622563899b2@github.com>
 <6xPqNdYUdDni24Gw_lENy5koPY5clPcluX03iVMKYnU=.c3f529da-68ca-4a73-b6ea-0600b333b4f6@github.com>
Message-ID: <CzuBUv8xBDScUUbJn3_2LHQBxerncuftV54uLjGQ-DA=.33fb63fb-03ad-46b2-81a7-60497e85612e@github.com>

On Mon, 6 Oct 2025 19:56:17 GMT, Justin King <jcking at openjdk.org> wrote:

>> Maybe not, if this is the same thread as readers. I don't know what it's for.
>
> `OrderAccess::release()` is more than a compiler barrier on AArch64. I am guessing this was copied from x86 or one of the others where that same function is a compiler barrier? Should I move `compiler_barrier` from the random source files its in, into globalDefinitions, and use that?

As far as I can see, the frame anchor is only accessed from its owner thread, so it doesn't matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2409836163

From aph at openjdk.org  Tue Oct  7 08:32:59 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 08:32:59 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <XTkmae7BFlwck7FmgVC4xu-af9BWuzBMCvjB-KB1QUY=.95629e5e-6657-41d4-ad61-6ed3f3c538dd@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>
 <XTkmae7BFlwck7FmgVC4xu-af9BWuzBMCvjB-KB1QUY=.95629e5e-6657-41d4-ad61-6ed3f3c538dd@github.com>
Message-ID: <5zp2DW3Dxpfi1AkzodWNMS1hq_dgejRK2IztXht7rN0=.240f8764-5dbc-4f62-801f-628220ec4e4f@github.com>

On Tue, 7 Oct 2025 08:11:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > I don't think copy() is ever called. Can we remove it?
> 
> Sure.

Ah no. `copy()` is called after the anchor is constructed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2409837998

From jsikstro at openjdk.org  Tue Oct  7 09:15:34 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:15:34 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Revert MaxRAM default removals, defer to future enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/bd1f632e..2304c6aa

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

  Stats: 17 lines in 2 files changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

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

From ayang at openjdk.org  Tue Oct  7 09:23:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 09:23:26 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
Message-ID: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>

On Tue, 7 Oct 2025 09:15:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert MaxRAM default removals, defer to future enhancement

src/hotspot/share/runtime/arguments.cpp line 1514:

> 1512: 
> 1513:   // Check if the user has configured any limit on the amount of RAM we may use.
> 1514:   bool ram_limit_set = !FLAG_IS_DEFAULT(MaxRAMPercentage) ||

How about `has_ram_limit`/`is_ram_limit_set`?

src/hotspot/share/runtime/arguments.cpp line 1544:

> 1542:     uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100);
> 1543: 
> 1544:     const size_t reasonable_min = limit_by_size_t_max(min_memory);

I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result.

src/hotspot/share/runtime/arguments.cpp line 1590:

> 1588: 
> 1589:     if (UseCompressedOops) {
> 1590:       size_t heap_end = HeapBaseMinAddress + MaxHeapSize;

I wonder if this is a pre-existing issue: `HeapBaseMinAddress` , according to its name, sounds like a `uintptr_t` instead of `size_t`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409967306
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409970585
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2409973796

From rehn at openjdk.org  Tue Oct  7 09:25:30 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Oct 2025 09:25:30 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
Message-ID: <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>

On Tue, 7 Oct 2025 08:13:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Yes, maybe.
>> 
>> I just don't understand why vector length is something different than zicboz block size.
>> E.g.
>> 
>> CacheLineSize                             // gets cache-line size
>> VM_Version::ext::zic64b();                // gets 64b cache-line size
>> VM_Version::non_ext::zicboz_block_size(); // gets cache block size
>> VM_Version::cpu_vector_length();          // private, gets vector register length (HW), should be size not length IMHO
>> MaxVectorSize                             // gets vector register length (-+ cmd-line)
>> 
>> 
>> When I am actually using these value in MASM/stubs/instrinsic/etc.. I don't care where this value came from.
>> If it's command line or RVI extension or if we with some other mean figured this setting out.
>> 
>> I think it would be nice to try to get a consistent API in VM_Version.
>> But I don't think that is possible (due to global flags), but I think we can at least do something better here, no?
>> 
>> As it is now it really hard to review as I need to double check if the correct setting was used.
>
> Maybe just keep the original names, and use them as pretty too? The code looks like `VM_Version::non_ext::zicboz_block_size()`, and the printed feature "pretty" name would be "zicboz_block_size".

But why is not vector size/length called:
`VM_Version::non_ext::rvv_vlen()`  or similar ? Should it ?

Should VM_Version::non_ext and VM_Version::ext be private, so we create a public:
VM_Version::ziboz_block_size() ?

I added:
`static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`


Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?

Can we agree to one consistent way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2409975644

From jsikstro at openjdk.org  Tue Oct  7 09:34:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:34:19 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename ram_limit_set to has_ram_limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/2304c6aa..c6e585e2

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

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

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

From jsikstro at openjdk.org  Tue Oct  7 09:34:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 7 Oct 2025 09:34:21 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v4]
In-Reply-To: <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <kIoRqz3UdU2Ft-DH1o3c6CeD7iwHaA1ZbTt1v-EZnL4=.16b72197-1058-4761-80fe-76fc45d7b53e@github.com>
 <0JlKR_0U6obGNVYe0Os0c2Q1w6WR9F_o6gHjApjzLJM=.db81f2ce-a74c-40a8-9ae9-591b9684e787@github.com>
Message-ID: <cbExN6kX2oAk4Fo6KY8ZhWY7iZHiCMH-__EXQLh6yh4=.1fb6351c-0b03-4e32-a684-16bd715a79f7@github.com>

On Tue, 7 Oct 2025 09:19:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert MaxRAM default removals, defer to future enhancement
>
> src/hotspot/share/runtime/arguments.cpp line 1544:
> 
>> 1542:     uint64_t max_memory = (uint64_t)(((double)physical_memory * MaxRAMPercentage) / 100);
>> 1543: 
>> 1544:     const size_t reasonable_min = limit_by_size_t_max(min_memory);
> 
> I wonder whether we should emit a log-info/warning, if `limit_by_size_t_max` does change the result.

I'm a bit hesitant to add non-debug logging here as I don't have resources to test this on a 32-bit VM. Also, I'm not sure how much extra code we'd like to have for 32-bit support.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2410006373

From cnorrbin at openjdk.org  Tue Oct  7 09:47:04 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 7 Oct 2025 09:47:04 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
Message-ID: <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>

On Tue, 7 Oct 2025 01:33:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That is a mis-characterization of the API. `active_processor_count()` tells you how many logical processors are available to the JVM process. That can be very different to the "physical" (**) number of processors due to partitioning at various levels (e.g. virtualization, containerization), as well as direct restrictions through API's like `taskset`.
> 
> (**) "physical" actually has no meaning these days. There is some value you can obtain through the operating system that provides the maximum number of processors that the operating system can see (and thus make available to the JVM).

Agreed, I conflated the two here. What I actually should have written is like you said, the number of logical processors available for the JVM to execute on. That is also the value the new  `machine_active_processor_count()` returns.

By contrast, the current container-reported value treats cpu quota and logical processors as the same thing, even though quota only restricts cpu time, not the number of cores we can run on. With a quota of 1, we might still execute on two cores for 50% of the time each, but `os::active_processor_count()` still only reports "1". 

> What is a "machine" here? Historically we have misused "physical" to mean what does a bare-metal OS report on a bare-metal piece of hardware. But that became inaccurate decades ago once virtualization/hypervisors arrived. So we've adjusted API's (e.g. MXBeans) to report whatever the "operating system" reports. The problem there is some things the operating system reports take into account the presence of containers, and others do not. This has always been a problem with these container environments - they should be invisible to software but they are not.

Machine in this context is the values the operating system reports, which could already be limited depending on the configuration. All this is of course Linux-only, as we don't support containers on any other platforms. In many container deployments the cgroup limits do differ from the OS view, but in a fully virtualized environment they can coincide. In that situation none of this makes a difference anyways, and both functions would report the same value.

> For a long time this was an impossible question to answer accurately - we could query whether cgroups were configured on a system but we couldn't ask if the JVM process was running under any cgroup constraints - has that changed?

Our container detection still isn't perfect, but it has improved:
1. We first check whether all cgroup controllers are mounted read-only, which is the default for many container runtimes.
2. If not, we examine the JVM's cgroup path to see if there are any memory/cpu limits present (covers JVMs started in restricted systemd slices).

These heuristics can miss more exotic setups but are pretty accurate for most use cases today.

> I would like to get a better idea of what kinds of "machine" information we need to query and how it will be used. I mean, how does it help to know a "machine" has 256 processors if the various software layers only make 16 available to you?

Like I mentioned above when explaining `os::active_processor_count()`, it can be very relevant to know that the underlying machine (virtualized or not) has 16 cpus available, even though the JVM's cgroup quota restricts us to an average of 2 cpus. In latency-sensitive workloads we might burst onto all 16 cores for a short interval and still stay within the 2-cpu quota. At the moment, the JVM has no way to know that those extra 14 cores even exist, so it cannot make that optimization.

The same argument applies to memory. GC heuristics may want to look at overall memory pressure on the machine, not just the container's limit. Imagine several containers on one host, where one is consuming most of its limit while others are relatively idle. From the host perspective the system is still comfortable, so the GC could be less aggressive compared to if every container was close to its limit. Without access to the host-level numbers we can't distinguish these scenarios.

Admittedly these functions are niche and will only matter for very specialised, performance-critical tasks. Still, the information is already available from the operating system, and the JVM should not hide or overwrite it for those users who can benefit from it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3376037169

From cnorrbin at openjdk.org  Tue Oct  7 09:50:46 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 7 Oct 2025 09:50:46 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <21KzYpwqo0LhSZS_jUfAvjaGnimucGaGcDZSWWTTMto=.01be3f79-137d-4af4-9964-76522b28750a@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <21KzYpwqo0LhSZS_jUfAvjaGnimucGaGcDZSWWTTMto=.01be3f79-137d-4af4-9964-76522b28750a@github.com>
Message-ID: <u_vRyBsJ1_ZgjBIvlJrFhSxZ41rrKsNxNmi6hp2pdj0=.e1f72414-c906-4d8d-b799-675e5b33f730@github.com>

On Mon, 6 Oct 2025 16:42:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This will conflict mightily with the refactoring that I'm working on for https://bugs.openjdk.org/browse/JDK-8365606

Understood, thanks for flagging that. The amount of change in the container layer isn't that big except for `CgroupUtil::processor_count()`, which wasn't of a java type to begin with. Is there something I could change to lessen the conflict at all?

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3376048807

From jsjolen at openjdk.org  Tue Oct  7 10:00:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Oct 2025 10:00:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Move BSMAttribute BSMAttributeEntries to own header file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/55f6d5bc..aed82e9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=09-10

  Stats: 385 lines in 8 files changed: 226 ins; 159 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From aph at openjdk.org  Tue Oct  7 10:11:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 10:11:58 GMT
Subject: Integrated: 8368303: AlwaysAtomicAccesses is excessively strict
In-Reply-To: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
References: <bGXwqjXWGjwzJmw91TwU3F7uJNAXhGTa7K1wbRgpuJg=.189af3bb-ac4e-4cb9-8265-9aac1bdfa92f@github.com>
Message-ID: <LhNbiT5lJNcj0a0_9MQL-oVlt8GmDefGNw3bH_pjCI4=.e1ed9dbc-0125-4ebe-b06f-e8de4e89e266@github.com>

On Mon, 22 Sep 2025 16:51:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. 
> 
> We need this in order to allow progress on JDK-8365147.

This pull request has now been integrated.

Changeset: aed9485b
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aed9485bbb1d93063e5e5f60ed84bfb36053bdd1
Stats:     14 lines in 1 file changed: 10 ins; 0 del; 4 mod

8368303: AlwaysAtomicAccesses is excessively strict

Reviewed-by: shade, vlivanov, dlong

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

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

From aph at openjdk.org  Tue Oct  7 10:17:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 10:17:48 GMT
Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1
 volatile field loads [v2]
In-Reply-To: <OQLPzrNubg-pVrE0zS5yVSq9eNDA_kkP40IUR55SAfg=.abfcbcf1-3ed5-4729-b590-ddde46800d89@github.com>
References: <p7XaTTrJZA65XAB3EoXH_cI34eOKXcSaPozylNiWMss=.4b218507-adbd-4351-996f-88f1c38f5f18@github.com>
 <OQLPzrNubg-pVrE0zS5yVSq9eNDA_kkP40IUR55SAfg=.abfcbcf1-3ed5-4729-b590-ddde46800d89@github.com>
Message-ID: <rkSInDDKHPJxR-E5iJRzlTvwRx3Y7bR9TFTTnnmO1ng=.5da25214-c0b0-4667-ba93-567a46a9c998@github.com>

On Tue, 19 Aug 2025 13:42:19 GMT, Samuel Chee <duke at openjdk.org> wrote:

>> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get.
>> 
>> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required.
>> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed.
>> 
>> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient.
>
> Samuel Chee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    
>    Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd
>  - Refine code generation for mem2reg_volatile
>    
>    The patch is contributed by @theRealAph.
>    
>    Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586

> See #27432

Now that this is integrated, you may proceed.

Will you also proceed with [8360654](https://github.com/openjdk/jdk/pull/26000)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3376146146

From mli at openjdk.org  Tue Oct  7 10:22:48 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 Oct 2025 10:22:48 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
Message-ID: <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>

On Tue, 7 Oct 2025 09:21:00 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?

I think this should be in another pr.

> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?

If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.

> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
> Can we agree to one consistent way?

As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2410138667

From jbechberger at openjdk.org  Tue Oct  7 10:26:14 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 7 Oct 2025 10:26:14 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v10]
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <RL1PjkcG_t_KaM_SmMMmQpruO0aw8TD03sYrI2lqzNM=.bfa66209-f2c3-4d14-a25a-e6aae82c127f@github.com>

> This change hopefully fixes the test failures by making the test cases more resilient.

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Remove from ProblemList
 - Merge branch 'master' into parttimenerd_make_auto_size_test_more_resilient
 - Fix build issue
 - Fix disabling out-of-stack walking and time box handling
 - Make main assertion less strict
 - Add synchronized
 - Add @requires vm.flagless
 - Remove synchronized
 - Tiny fixes
 - Simplify code
 - ... and 1 more: https://git.openjdk.org/jdk/compare/33b311d0...3f6fa333

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27293/files
  - new: https://git.openjdk.org/jdk/pull/27293/files/afd9815f..3f6fa333

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=08-09

  Stats: 162276 lines in 1928 files changed: 132930 ins; 17108 del; 12238 mod
  Patch: https://git.openjdk.org/jdk/pull/27293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293

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

From dholmes at openjdk.org  Tue Oct  7 10:49:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 10:49:07 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v10]
In-Reply-To: <RL1PjkcG_t_KaM_SmMMmQpruO0aw8TD03sYrI2lqzNM=.bfa66209-f2c3-4d14-a25a-e6aae82c127f@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <RL1PjkcG_t_KaM_SmMMmQpruO0aw8TD03sYrI2lqzNM=.bfa66209-f2c3-4d14-a25a-e6aae82c127f@github.com>
Message-ID: <koEICWgTUG9E1dc5kIl_CJw7VJF-TzTjnrSrXriTaw0=.b18921a5-f752-4093-ae7f-b1a1632361d8@github.com>

On Tue, 7 Oct 2025 10:26:14 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Remove from ProblemList
>  - Merge branch 'master' into parttimenerd_make_auto_size_test_more_resilient
>  - Fix build issue
>  - Fix disabling out-of-stack walking and time box handling
>  - Make main assertion less strict
>  - Add synchronized
>  - Add @requires vm.flagless
>  - Remove synchronized
>  - Tiny fixes
>  - Simplify code
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/298af78f...3f6fa333

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3309536074

From dholmes at openjdk.org  Tue Oct  7 10:54:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 10:54:50 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
 <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>
Message-ID: <KTQ9ZY-H51_DB9fg8yi1nFrueNF7GM3pEUeqHVeWJTQ=.acb5bd3c-0e85-4aac-9e94-5f4b7b4f7bad@github.com>

On Tue, 7 Oct 2025 09:44:15 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> By contrast, the current container-reported value treats cpu quota and logical processors as the same thing, even though quota only restricts cpu time, not the number of cores we can run on. With a quota of 1, we might still execute on two cores for 50% of the time each, but os::active_processor_count() still only reports "1".

Right - the way the "container folk" dealt with quotas etc never made any sense to me at all. I tried arguing the point but to no avail. So basically what you are looking for here is a way to get around the "broken" definition of available-processors when quotas are enforced.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3376353013

From dholmes at openjdk.org  Tue Oct  7 10:58:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 10:58:48 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
Message-ID: <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>

On Tue, 7 Oct 2025 10:00:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move BSMAttribute BSMAttributeEntries to own header file

src/hotspot/share/oops/bsmAttribute.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

You need to preserve the initial copyright year from the files that originally contained the relocated code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2410226254

From duke at openjdk.org  Tue Oct  7 12:07:44 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 7 Oct 2025 12:07:44 GMT
Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1
 volatile field loads [v2]
In-Reply-To: <OQLPzrNubg-pVrE0zS5yVSq9eNDA_kkP40IUR55SAfg=.abfcbcf1-3ed5-4729-b590-ddde46800d89@github.com>
References: <p7XaTTrJZA65XAB3EoXH_cI34eOKXcSaPozylNiWMss=.4b218507-adbd-4351-996f-88f1c38f5f18@github.com>
 <OQLPzrNubg-pVrE0zS5yVSq9eNDA_kkP40IUR55SAfg=.abfcbcf1-3ed5-4729-b590-ddde46800d89@github.com>
Message-ID: <y4cdKQwZVuP90QeBcNxfxqxQ-92uFbXKYHkw_HTSdjc=.31f2a962-3517-4b4d-9ff2-d8747f6fdb31@github.com>

On Tue, 19 Aug 2025 13:42:19 GMT, Samuel Chee <duke at openjdk.org> wrote:

>> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get.
>> 
>> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required.
>> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed.
>> 
>> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient.
>
> Samuel Chee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    
>    Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd
>  - Refine code generation for mem2reg_volatile
>    
>    The patch is contributed by @theRealAph.
>    
>    Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586

>Now that this is integrated, you may proceed.

> Will you also proceed with https://github.com/openjdk/jdk/pull/26000?


Thanks, Andrew. Yes - I plan to proceed with both PRs. I am scheduling this for late October / early November. If you would like these done sooner, please let me know, I can reprioritize.

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

PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3376586098

From duke at openjdk.org  Tue Oct  7 12:18:56 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 7 Oct 2025 12:18:56 GMT
Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores
In-Reply-To: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
References: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
Message-ID: <hBrb9d-1VA66PEuJD7clQ4i5KVFdD_-dSQza5bPWMvU=.176e8f7b-b033-47a8-92be-8ee899cc9af3@github.com>

On Fri, 8 Aug 2025 14:50:13 GMT, Ruben <duke at openjdk.org> wrote:

> For Neoverse N1, N2, V1, and V2, the following JVM flags are set:
>  - UseSIMDForMemoryOps=true
>  - OnSpinWaitInst=isb
>  - OnSpinWaitInstCount=1
>  - AlwaysMergeDMB=false
> 
> Additionally, for Neoverse V1 and V2 only, these flags are set:
>  - UseCryptoPmullForCRC32=true
>  - CodeEntryAlignment=32
> 
> Set the same flags for Neoverse N3 and V3, respectively.

@theRealAph, @adinn, if this PR looks suitable, I'd appreciate if you could approve it. Please let me know if any change is required before this can be integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3376625294

From cnorrbin at openjdk.org  Tue Oct  7 12:22:54 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 7 Oct 2025 12:22:54 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <KTQ9ZY-H51_DB9fg8yi1nFrueNF7GM3pEUeqHVeWJTQ=.acb5bd3c-0e85-4aac-9e94-5f4b7b4f7bad@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
 <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>
 <KTQ9ZY-H51_DB9fg8yi1nFrueNF7GM3pEUeqHVeWJTQ=.acb5bd3c-0e85-4aac-9e94-5f4b7b4f7bad@github.com>
Message-ID: <R2la5XahUigPOTo6MHY5r17IOwq15a_WQw1Dciy9kw4=.b76d5d30-89c5-47c6-952a-1ca0a3023688@github.com>

On Tue, 7 Oct 2025 10:52:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So basically what you are looking for here is a way to get around the "broken" definition of available-processors when quotas are enforced.

Partly, yes. The cpu quota is the clearest example, but the same mismatch shows up for other values. The meaning of the container values don't always map 1:1 to OS numbers. What I'm after is a clean way to get those numbers separately. Pairing `machine_` and `container_` gives access to both pieces of data, offering just the machine side would leave us without a direct path to the container value.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3376638884

From sgehwolf at openjdk.org  Tue Oct  7 12:22:56 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 7 Oct 2025 12:22:56 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <u_vRyBsJ1_ZgjBIvlJrFhSxZ41rrKsNxNmi6hp2pdj0=.e1f72414-c906-4d8d-b799-675e5b33f730@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <21KzYpwqo0LhSZS_jUfAvjaGnimucGaGcDZSWWTTMto=.01be3f79-137d-4af4-9964-76522b28750a@github.com>
 <u_vRyBsJ1_ZgjBIvlJrFhSxZ41rrKsNxNmi6hp2pdj0=.e1f72414-c906-4d8d-b799-675e5b33f730@github.com>
Message-ID: <WtQOJ6I5w7addCV6V4llAKxEW2UjItr6cIS2UB4wOds=.04e25197-b578-4bc6-921a-46f53146bfb9@github.com>

On Tue, 7 Oct 2025 09:47:51 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> > This will conflict mightily with the refactoring that I'm working on for https://bugs.openjdk.org/browse/JDK-8365606
> 
> Understood, thanks for flagging that. The amount of change in the container layer isn't that big except for `CgroupUtil::processor_count()`, which wasn't of a java type to begin with. Is there something I could change to lessen the conflict at all?

Separating out the `processor_count()` change would be good (irrespective of the conflict). But other than that, I'd think there isn't really a good way. Perhaps to wait for JDK-8365606 to land as those are way more changes to deal with rather than what is done here. I.e. merge should be simpler. I should have something ready by end of the week, fwiw.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3376641522

From ayang at openjdk.org  Tue Oct  7 12:43:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Oct 2025 12:43:39 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
Message-ID: <bDKs5xn1pabzX2qKNk3JNMM6mscmLlcABWrzywGkiBM=.dd00b428-d643-4096-821e-ba6f814a2eb3@github.com>

On Tue, 7 Oct 2025 09:34:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ram_limit_set to has_ram_limit

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3309934893

From shade at openjdk.org  Tue Oct  7 12:49:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 12:49:13 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery
Message-ID: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>

During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc.

This leans heavily on unified logging to do the right thing. The configuration I found most useful for testing is:


-Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos


My tentative plan is to visualize this more comprehensively with a little tool that digests that log.

I am open for bikeshedding on logging wording. The log example is in the comment below.

Additional testing:
 - [x] Ad-hoc log peeking
 - [ ] Linux x86_64 server fastdebug, `tier1`

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

Commit messages:
 - Work

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

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

From shade at openjdk.org  Tue Oct  7 12:49:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 12:49:14 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <zmbwZFTpKxizG6naYps6Dt-U6yBpQPBdMKWoM8i40k4=.d8f48e39-4301-4351-9fbc-c4ccfe9ad688@github.com>

On Tue, 7 Oct 2025 12:42:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc.
> 
> This leans heavily on unified logging to do the right thing. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [ ] Linux x86_64 server fastdebug, `tier1`

Example log, plus some comments:


$ ... -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos ...

$ sort safepoint.log | less
[3564874277ns] Safepoint synchronization begins using futex wait barrier
[3564880769ns] Setting thread local yield flag for threads         
<------ polling flags in Java threads are set in 5 us ------->
<------ safepoint machinery makes 1st attempt at synchronizing------>
[3564886400ns] Checking thread status
[3564891580ns] Thread "Worker-0" [0x0000788bcc4af530] is still running
[3564892331ns] Thread "Worker-1" [0x0000788bcc4bb470] is still running
[3564892892ns] Thread "Worker-2" [0x0000788bcc4bbf20] is still running
[3564893734ns] Thread "Worker-3" [0x0000788bcc4bd1e0] is still running
[3564894215ns] Thread "Worker-4" [0x0000788bcc4be7f0] is still running
[3564894666ns] Thread "Worker-5" [0x0000788bcc4bfb90] is still running
[3564895066ns] Thread "Worker-6" [0x0000788bcc4c0f30] is still running
[3564895377ns] Thread "Worker-7" [0x0000788bcc4c22e0] is still running
[3564895918ns] Thread "Allocator-0" [0x0000788bcc4c3d50] is still running
[3564896289ns] Thread "Allocator-1" [0x0000788bcc4c5270] is still running
[3564896740ns] Thread "Allocator-5" [0x0000788bcc4ca490] is still running
[3564896860ns] Waiting for threads to block
<------- first thread responds in 63 us after poll set ----->
[3564943298ns] Blocking thread "Allocator-0" [0x0000788bcc4c3d50]   
[3564945072ns] Blocking thread "Worker-5" [0x0000788bcc4bfb90]
[3564945122ns] Blocking thread "Worker-3" [0x0000788bcc4bd1e0]
[3564945302ns] Blocking thread "Worker-4" [0x0000788bcc4be7f0]
[3564946144ns] Blocking thread "Worker-1" [0x0000788bcc4bb470]
[3564943709ns] Blocking thread "Worker-7" [0x0000788bcc4c22e0]
[3564945943ns] Blocking thread "Worker-6" [0x0000788bcc4c0f30]
<------ safepoint machinery makes 2nd attempt ------>
[3564965701ns] Checking thread status                               
[3564966212ns] Thread "Worker-0" [0x0000788bcc4af530] is still running
[3564966522ns] Thread "Worker-1" [0x0000788bcc4bb470] is now blocked
[3564966743ns] Thread "Worker-2" [0x0000788bcc4bbf20] is still running
[3564966973ns] Thread "Worker-3" [0x0000788bcc4bd1e0] is now blocked
[3564967184ns] Thread "Worker-4" [0x0000788bcc4be7f0] is now blocked
[3564967414ns] Thread "Worker-5" [0x0000788bcc4bfb90] is now blocked
[3564967645ns] Thread "Worker-6" [0x0000788bcc4c0f30] is now blocked
[3564967855ns] Thread "Worker-7" [0x0000788bcc4c22e0] is now blocked
[3564968105ns] Thread "Allocator-0" [0x0000788bcc4c3d50] is now blocked
[3564968316ns] Thread "Allocator-1" [0x0000788bcc4c5270] is still running
[3564968576ns] Thread "Allocator-5" [0x0000788bcc4ca490] is still running
[3564968677ns] Waiting for threads to block
[3564970410ns] Blocking thread "Allocator-5" [0x0000788bcc4ca490]
[3564975119ns] Blocking thread "Worker-2" [0x0000788bcc4bbf20] 
[3564977724ns] Blocking thread "Allocator-1" [0x0000788bcc4c5270]
<------ last thread responds in 103 us after poll set ----->
[3564984196ns] Blocking thread "Worker-0" [0x0000788bcc4af530]     
<------ safepoint machinery makes 3rd attempt ------>
[3565036576ns] Checking thread status
[3564037287ns] Thread "Worker-0" [0x0000788bcc4af530] is now blocked
[3564037658ns] Thread "Worker-2" [0x0000788bcc4bbf20] is now blocked
[3564037898ns] Thread "Allocator-1" [0x0000788bcc4c5270] is now blocked
[3564038189ns] Thread "Allocator-5" [0x0000788bcc4ca490] is now blocked
<------ safepoint machinery detects the last thread with 50 us delay --->
[3564038700ns] Safepoint synchronization finished                  
<------ VM OPERATION RUNS HERE ---->
[3564243099ns] Leaving safepoint
<------ safepoint machinery initiates wakeups --->
<------ first thread experiences 285us total delay --->
[3564253689ns] Resuming thread "Allocator-0" [0x0000788bcc4c3d50]
[3564254010ns] Resuming thread "Worker-1" [0x0000788bcc4bb470]
[3564253729ns] Resuming thread "Worker-4" [0x0000788bcc4be7f0]
[3564254250ns] Resuming thread "Worker-5" [0x0000788bcc4bfb90]
[3564255182ns] Resuming thread "Worker-7" [0x0000788bcc4c22e0]
[3564254871ns] Resuming thread "Worker-3" [0x0000788bcc4bd1e0]
[3564265862ns] Resuming thread "Worker-6" [0x0000788bcc4c0f30]
[3564283796ns] Resuming thread "Allocator-5" [0x0000788bcc4ca490]
[3564392820ns] Safepoint complete
<------ wakeups are complete at this point ----->
[3568389497ns] Resuming thread "Worker-0" [0x0000788bcc4af530]
[3568393484ns] Resuming thread "Worker-2" [0x0000788bcc4bbf20]
<------ last thread experiences 7.5ms total delay --->
[3572390561ns] Resuming thread "Allocator-1" [0x0000788bcc4c5270]

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3376730861

From aph at openjdk.org  Tue Oct  7 12:50:51 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 12:50:51 GMT
Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores
In-Reply-To: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
References: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
Message-ID: <tFgYMP2Vefrl5-DB5-9QHaqu-gjGEJ6dGqRzLJphr_I=.7804156b-4102-4c3c-986a-22bdc56d2b3e@github.com>

On Fri, 8 Aug 2025 14:50:13 GMT, Ruben <duke at openjdk.org> wrote:

> For Neoverse N1, N2, V1, and V2, the following JVM flags are set:
>  - UseSIMDForMemoryOps=true
>  - OnSpinWaitInst=isb
>  - OnSpinWaitInstCount=1
>  - AlwaysMergeDMB=false
> 
> Additionally, for Neoverse V1 and V2 only, these flags are set:
>  - UseCryptoPmullForCRC32=true
>  - CodeEntryAlignment=32
> 
> Set the same flags for Neoverse N3 and V3, respectively.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26701#pullrequestreview-3309959689

From jsjolen at openjdk.org  Tue Oct  7 12:57:04 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Oct 2025 12:57:04 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
 <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>
Message-ID: <PIjn0k_gZzVMUtq7jyCIrmMbLAB6zt8io0aMFAA4_gs=.710943ba-ed94-46f3-8872-d69b2d92f728@github.com>

On Tue, 7 Oct 2025 10:54:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move BSMAttribute BSMAttributeEntries to own header file
>
> src/hotspot/share/oops/bsmAttribute.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> You need to preserve the initial copyright year from the files that originally contained the relocated code.

I think all of the copied code is from 2025, but let's do the safe thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2410536152

From ysuenaga at openjdk.org  Tue Oct  7 13:05:21 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 13:05:21 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v4]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <IyoU70_09xlMBgbOdJg-8sH0ovqAkCYaw_SJFT-n1rc=.c38a48f7-0a5c-4683-89ef-f78ccc3f328b@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:

 - Fix comment line
 - Fix comments
 - Revert "Use jmc_undefined_long if runs on hybrid CPU"
   
   This reverts commit 2ebbde5f963eec47b8709afd68f45cb169b096a8.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/aeea3fb0..d7b2edd0

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

  Stats: 18 lines in 4 files changed: 4 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080

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

From duke at openjdk.org  Tue Oct  7 13:24:40 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 13:24:40 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
Message-ID: <Jr5jbrFyE9vSXjE0R6_qTe-80DQNfXuJsQLVBrmQ49I=.e035af2f-7daa-4cba-9279-960ee614ae02@github.com>

On Mon, 6 Oct 2025 12:20:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
> 
> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

@fandreuz 
Your change (at version 131f636cf09ab166d786210868a2197fa4d62565) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27644#issuecomment-3376875929

From swen at openjdk.org  Tue Oct  7 13:32:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 7 Oct 2025 13:32:43 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
Message-ID: <FybkYjm1LGzomISCLKPqkPKkyetk6G_3elgSbDZiMqA=.ad91093c-8f39-41fc-a393-7ea445ddd596@github.com>

On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Improve CommandLineTest.testWarn
>  - More test cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Expand jni/JNIAttachMutatorTest to final fields in named modules
>  - Merge branch 'master' into JDK-8353835
>  - Test updates based on reviewer feedback
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a

Field.set can be further simplified to reduce duplicate code, such as this https://github.com/wenshao/jdk/commit/188df2c43b313737552aa9f0b32d067de56a0d4d

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3376907134

From alanb at openjdk.org  Tue Oct  7 13:43:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Oct 2025 13:43:35 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <FybkYjm1LGzomISCLKPqkPKkyetk6G_3elgSbDZiMqA=.ad91093c-8f39-41fc-a393-7ea445ddd596@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <FybkYjm1LGzomISCLKPqkPKkyetk6G_3elgSbDZiMqA=.ad91093c-8f39-41fc-a393-7ea445ddd596@github.com>
Message-ID: <rG_G6K4nAdQ0K9o2XqaCwHviztHSPfRMiD6phSiRXwI=.a92e05c4-36ac-404e-9440-05ff33aecb8e@github.com>

On Tue, 7 Oct 2025 13:29:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Field.set can be further simplified to reduce duplicate code.

This PR is focused on the changes for JEP 500. There may be merit in doing refactoring some time in the future but not here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3376952169

From duke at openjdk.org  Tue Oct  7 13:45:30 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 13:45:30 GMT
Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores
In-Reply-To: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
References: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
Message-ID: <AB-5XgtrfBJHotodjv2fOuuR-lMGr34_QGHrjpuCHGA=.19fb8bdb-e927-4345-a5e2-179ab90aad35@github.com>

On Fri, 8 Aug 2025 14:50:13 GMT, Ruben <duke at openjdk.org> wrote:

> For Neoverse N1, N2, V1, and V2, the following JVM flags are set:
>  - UseSIMDForMemoryOps=true
>  - OnSpinWaitInst=isb
>  - OnSpinWaitInstCount=1
>  - AlwaysMergeDMB=false
> 
> Additionally, for Neoverse V1 and V2 only, these flags are set:
>  - UseCryptoPmullForCRC32=true
>  - CodeEntryAlignment=32
> 
> Set the same flags for Neoverse N3 and V3, respectively.

@ruben-arm 
Your change (at version 178e96f061dd38bc7b2fa44595d0337671b48491) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3376959457

From swen at openjdk.org  Tue Oct  7 14:04:38 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 7 Oct 2025 14:04:38 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
Message-ID: <J2BpfwMogNE7Na55hbsP2z86CXlAuqTnnWIxpy7yKhk=.b89b35ec-7190-4d59-87e6-5e50ce0f1b75@github.com>

On Sat, 4 Oct 2025 05:09:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - Merge branch 'master' into JDK-8353835
>  - Improve CommandLineTest.testWarn
>  - More test cleanup
>  - Merge branch 'master' into JDK-8353835
>  - Expand jni/JNIAttachMutatorTest to final fields in named modules
>  - Merge branch 'master' into JDK-8353835
>  - Test updates based on reviewer feedback
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a

src/java.base/share/classes/java/lang/reflect/Field.java line 982:

> 980:         } else {
> 981:             setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b));
> 982:         }

Suggestion:

        if (!Modifier.isFinal(modifiers)) {
            fa.setByte(obj, b);
        } else {
            setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b));
        }

src/java.base/share/classes/java/lang/reflect/Field.java line 1027:

> 1025:         } else {
> 1026:             setFinal(Reflection.getCallerClass(), obj, () -> fa.setChar(obj, c));
> 1027:         }

Suggestion:

        if (!Modifier.isFinal(modifiers)) {
            fa.setChar(obj, c);
        } else {
            setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setChar(obj, c));
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410745955
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410751688

From jcking at openjdk.org  Tue Oct  7 14:07:29 2025
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Oct 2025 14:07:29 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>

> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.

Justin King has updated the pull request incrementally with two additional commits since the last revision:

 - Add back header inclusion
   
   Signed-off-by: Justin King <jcking at google.com>
 - Move compiler_barrier() to globalDefinitions.hpp and use it
   
   Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27645/files
  - new: https://git.openjdk.org/jdk/pull/27645/files/016769df..7dc3313c

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

  Stats: 50 lines in 7 files changed: 27 ins; 15 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27645/head:pull/27645

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

From ysuenaga at openjdk.org  Tue Oct  7 14:04:46 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 14:04:46 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix build error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/d7b2edd0..a0520474

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

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

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

From jcking at openjdk.org  Tue Oct  7 14:07:30 2025
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Oct 2025 14:07:30 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <CzuBUv8xBDScUUbJn3_2LHQBxerncuftV54uLjGQ-DA=.33fb63fb-03ad-46b2-81a7-60497e85612e@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <DA1wut5fLpctpMipDxImmjs3Dp2uUN5gG_JCpmOy6AA=.a23b23ea-41f4-4ae3-a23a-fa994887cf5d@github.com>
 <gYVr-ObNRt1_XzeuKG7kKQRaHlpd7iC_rE3NDhVsKvo=.95d02b2e-4332-4395-b3f8-1622563899b2@github.com>
 <6xPqNdYUdDni24Gw_lENy5koPY5clPcluX03iVMKYnU=.c3f529da-68ca-4a73-b6ea-0600b333b4f6@github.com>
 <CzuBUv8xBDScUUbJn3_2LHQBxerncuftV54uLjGQ-DA=.33fb63fb-03ad-46b2-81a7-60497e85612e@github.com>
Message-ID: <bpZF2YvBGOhYgwD_qribmuHJ8orWPbx0PsaFbCk08u4=.950244c6-a053-4d7e-b672-0617e2bfec63@github.com>

On Tue, 7 Oct 2025 08:29:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> `OrderAccess::release()` is more than a compiler barrier on AArch64. I am guessing this was copied from x86 or one of the others where that same function is a compiler barrier? Should I move `compiler_barrier` from the random source files its in, into globalDefinitions, and use that?
>
> As far as I can see, the frame anchor is only accessed from its owner thread, so it doesn't matter.

I refactored `compiler_barrier()` into globalDefinitions and used it, it is potentially need to ensure the compiler doesn't change the store/load order so that `sp` is always last.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2410744044

From asmehra at openjdk.org  Tue Oct  7 14:34:25 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 14:34:25 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for resolving
 ConstantPool entries for static field
Message-ID: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>

This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.

Testing: tested x86-64 by running `hotspot_runtime` group
Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

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

Commit messages:
 - 8369296: Add fast class init checks in interpreter for resolving ConstantPool entries for static field

Changes: https://git.openjdk.org/jdk/pull/27676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369296
  Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

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

From aph at openjdk.org  Tue Oct  7 14:47:40 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 14:47:40 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
Message-ID: <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>

On Tue, 7 Oct 2025 14:07:29 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add back header inclusion
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Move compiler_barrier() to globalDefinitions.hpp and use it
>    
>    Signed-off-by: Justin King <jcking at google.com>

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 105:

> 103:   __asm__ volatile ("" : : : "memory");
> 104: }
> 105: 

You can do this in portable C++ since C++11:

// Complier barrier which prevents the compiler from reordering loads and stores.
static inline void compiler_barrier() {
  std::atomic_signal_fence(memory_order_seq_cst);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2410896439

From asmehra at openjdk.org  Tue Oct  7 14:49:24 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 14:49:24 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Fix compile failure
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/667db8af..995d4bbb

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

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

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

From aph at openjdk.org  Tue Oct  7 14:54:04 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Oct 2025 14:54:04 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
 <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>
Message-ID: <j1NaPSjsjshdV2H4OonSfJyOCLj5NlHhV7NJOvmYkFc=.61a64d9a-fb53-4cce-a453-3c35fe1c6e6c@github.com>

On Tue, 7 Oct 2025 14:44:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add back header inclusion
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Move compiler_barrier() to globalDefinitions.hpp and use it
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 105:
> 
>> 103:   __asm__ volatile ("" : : : "memory");
>> 104: }
>> 105: 
> 
> You can do this in portable C++ since C++11:
> 
> // Complier barrier which prevents the compiler from reordering loads and stores.
> static inline void compiler_barrier() {
>   std::atomic_signal_fence(memory_order_seq_cst);
> }

There are some rules about not calling the Standard C++ libraries in the Guidelines, but given that this one only prevents the compiler from moving things around and does not generate any code, I don't think that really applies. More legalisticaily-minded people might disagree, but I prefer portable code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2410920190

From liach at openjdk.org  Tue Oct  7 15:07:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 Oct 2025 15:07:40 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <J2BpfwMogNE7Na55hbsP2z86CXlAuqTnnWIxpy7yKhk=.b89b35ec-7190-4d59-87e6-5e50ce0f1b75@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <J2BpfwMogNE7Na55hbsP2z86CXlAuqTnnWIxpy7yKhk=.b89b35ec-7190-4d59-87e6-5e50ce0f1b75@github.com>
Message-ID: <VJPTUBTMpO_7Y58MtQ0bLR6n5yk_8YpiczcRzTMN7iQ=.1bdb6c04-6ffd-48be-92f5-f6f7580da25f@github.com>

On Tue, 7 Oct 2025 13:59:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8353835
>>  - Add test for -Xlog:jni=debug
>>  - Merge branch 'master' into JDK-8353835
>>  - Merge branch 'master' into JDK-8353835
>>  - Improve CommandLineTest.testWarn
>>  - More test cleanup
>>  - Merge branch 'master' into JDK-8353835
>>  - Expand jni/JNIAttachMutatorTest to final fields in named modules
>>  - Merge branch 'master' into JDK-8353835
>>  - Test updates based on reviewer feedback
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/72319167...eed7ec4a
>
> src/java.base/share/classes/java/lang/reflect/Field.java line 982:
> 
>> 980:         } else {
>> 981:             setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b));
>> 982:         }
> 
> Suggestion:
> 
>         if (!Modifier.isFinal(modifiers)) {
>             fa.setByte(obj, b);
>         } else {
>             setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b));
>         }

We still need to capture `b` here so this doesn't really improve anything. Same for others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410965404

From alanb at openjdk.org  Tue Oct  7 15:17:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Oct 2025 15:17:52 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v7]
In-Reply-To: <VJPTUBTMpO_7Y58MtQ0bLR6n5yk_8YpiczcRzTMN7iQ=.1bdb6c04-6ffd-48be-92f5-f6f7580da25f@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <iKxxBPM7coB7Ydd44Q40ZOAVwartDmXQsqdCDmRPDD0=.ea0db056-6ecf-4683-8602-b0c2fb1811db@github.com>
 <J2BpfwMogNE7Na55hbsP2z86CXlAuqTnnWIxpy7yKhk=.b89b35ec-7190-4d59-87e6-5e50ce0f1b75@github.com>
 <VJPTUBTMpO_7Y58MtQ0bLR6n5yk_8YpiczcRzTMN7iQ=.1bdb6c04-6ffd-48be-92f5-f6f7580da25f@github.com>
Message-ID: <pr_I_UD79tYzFIdRget-1X8P_9QTM1oASSm6UHeu5Jo=.e4243ef6-35ec-4e77-9932-2a789d53c3a2@github.com>

On Tue, 7 Oct 2025 15:04:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Field.java line 982:
>> 
>>> 980:         } else {
>>> 981:             setFinal(Reflection.getCallerClass(), obj, () -> fa.setByte(obj, b));
>>> 982:         }
>> 
>> Suggestion:
>> 
>>         if (!Modifier.isFinal(modifiers)) {
>>             fa.setByte(obj, b);
>>         } else {
>>             setFinal(Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor().setByte(obj, b));
>>         }
>
> We still need to capture `b` here so this doesn't really improve anything. Same for others.

Right, and capturing fa/obj/b vs. this/obj/b is also not a concern because this is the slow case for final fields.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2410998983

From shade at openjdk.org  Tue Oct  7 15:40:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 15:40:31 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v2]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [ ] Linux x86_64 server fastdebug, `tier1`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Cannot allocate for Thread::name + adjust debug levels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/3036d32c..22700224

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

  Stats: 11 lines in 2 files changed: 2 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27673/head:pull/27673

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

From shade at openjdk.org  Tue Oct  7 15:40:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Oct 2025 15:40:32 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <h54pt6Mt77btwp82oqsrV600D-pc9fAzOhOiLmwQsv4=.4c8f1361-1fe8-4897-8273-18689d9418b2@github.com>

On Tue, 7 Oct 2025 12:42:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [ ] Linux x86_64 server fastdebug, `tier1`

Oops, cannot touch `JavaThread::name()` on this safepoint path, because it can allocate. Back to thread pointers only then.

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3377463872

From asmehra at openjdk.org  Tue Oct  7 16:07:49 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 16:07:49 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
Message-ID: <uEFqdPEdmXMKCZTXtIycCL9XcdsA-kjgBcbd3hQxot8=.96ddb44f-464f-4715-b921-0c1717cc4be1@github.com>

On Tue, 7 Oct 2025 14:49:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

@offamitkumar @Hamlin-Li  @RealFYang @TheRealMDoerr 
I need help in adding arch specific code for s390, risc-v and ppc for this PR. Would you be able to contribute the code for these platforms? Specifically, we need to add a call to `clinit_barrier` in `TemplateTable::resolve_cache_and_index_for_field`.

@vnkozlov  @adinn @iwanowww can you please review this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3377572102

From amitkumar at openjdk.org  Tue Oct  7 16:39:49 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 7 Oct 2025 16:39:49 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <uEFqdPEdmXMKCZTXtIycCL9XcdsA-kjgBcbd3hQxot8=.96ddb44f-464f-4715-b921-0c1717cc4be1@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <uEFqdPEdmXMKCZTXtIycCL9XcdsA-kjgBcbd3hQxot8=.96ddb44f-464f-4715-b921-0c1717cc4be1@github.com>
Message-ID: <87C_6FuOFoMBTzG5So9cza63FT6qRyOqK8DJIuyn8Yc=.a21361ef-7013-46a5-a264-b7dc201e0e86@github.com>

On Tue, 7 Oct 2025 16:05:18 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compile failure
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> @offamitkumar @Hamlin-Li  @RealFYang @TheRealMDoerr 
> I need help in adding arch specific code for s390, risc-v and ppc for this PR. Would you be able to contribute the code for these platforms? Specifically, we need to add a call to `clinit_barrier` in `TemplateTable::resolve_cache_and_index_for_field`.
> 
> @vnkozlov  @adinn @iwanowww can you please review this patch.

Hi @ashu-mehra,

This is fixing the test failure on s390: 


diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp
index 2b39cc8318c..cf34bff7746 100644
--- a/src/hotspot/cpu/s390/templateTable_s390.cpp
+++ b/src/hotspot/cpu/s390/templateTable_s390.cpp
@@ -2409,6 +2409,7 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
 
   NearLabel resolved;
+  Label L_clinit_barrier_slow;
 
   Bytecodes::Code code = bytecode();
   switch (code) {
@@ -2425,6 +2426,8 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
   __ z_bre(resolved);
 
   // resolve first time through
+  // Class initialization barrier slow path lands here as well.
+  __ bind(L_clinit_barrier_slow);
   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
   __ load_const_optimized(Z_ARG2, (int)code);
   __ call_VM(noreg, entry, Z_ARG2);
@@ -2434,6 +2437,15 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
 
   __ bind(resolved);
 
+  // Class initialization barrier for static fields
+  if (VM_Version::supports_fast_class_init_checks() &&
+      (bytecode() == Bytecodes::_getstatic || bytecode() == Bytecodes::_putstatic)) {
+    const Register field_holder = index;
+
+    __ load_sized_value(field_holder, Address(cache, ResolvedFieldEntry::field_holder_offset()), sizeof(void*), false);
+    __ clinit_barrier(field_holder, Z_thread, nullptr /*L_fast_path*/, &L_clinit_barrier_slow);
+  }
+
   BLOCK_COMMENT("} resolve_cache_and_index_for_field");
 }

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3377691185

From vlivanov at openjdk.org  Tue Oct  7 17:04:32 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Oct 2025 17:04:32 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
Message-ID: <arvnfub3z71Oi0PxvVHCm1Zq7XW4k60rxN6i887DW2Q=.df453af6-1e8d-4c81-8324-3b12acae835a@github.com>

On Tue, 7 Oct 2025 14:49:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

x86- and aarch64-specific changes look good.

There are 3 other platforms  (ppc, s390, and riscv) which report `VM_Version::supports_fast_class_init_checks() == true`. All of them require similar changes in platform-specific code.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3377767332

From jcking at openjdk.org  Tue Oct  7 17:12:28 2025
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Oct 2025 17:12:28 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <j1NaPSjsjshdV2H4OonSfJyOCLj5NlHhV7NJOvmYkFc=.61a64d9a-fb53-4cce-a453-3c35fe1c6e6c@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
 <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>
 <j1NaPSjsjshdV2H4OonSfJyOCLj5NlHhV7NJOvmYkFc=.61a64d9a-fb53-4cce-a453-3c35fe1c6e6c@github.com>
Message-ID: <s1F_fxBsa8_eSfKddYNT7ocheRZUtvyUiqofPF26dGA=.525ebf4f-c970-4ba4-af37-52e9e0ac49e3@github.com>

On Tue, 7 Oct 2025 14:50:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 105:
>> 
>>> 103:   __asm__ volatile ("" : : : "memory");
>>> 104: }
>>> 105: 
>> 
>> You can do this in portable C++ since C++11:
>> 
>> // Complier barrier which prevents the compiler from reordering loads and stores.
>> static inline void compiler_barrier() {
>>   std::atomic_signal_fence(memory_order_seq_cst);
>> }
>
> There are some rules about not calling the Standard C++ libraries in the Guidelines, but given that this one only prevents the compiler from moving things around and does not generate any code, I don't think that really applies. More legalisticaily-minded people might disagree, but I prefer portable code.

That does require including `<atomic>`, which seems not ideal in globalDefinitions. Additionally `<atomic>` will likely eventually include `<stdatomic.h>` which defines `memory_order` as well. So I think we will have to live with what is currently here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2411310540

From kvn at openjdk.org  Tue Oct  7 17:30:12 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 7 Oct 2025 17:30:12 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
Message-ID: <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>

On Tue, 7 Oct 2025 14:49:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Can we loop to `L_clinit_barrier_slow` several times until class is initialized?

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

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3311149861

From vlivanov at openjdk.org  Tue Oct  7 17:49:23 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Oct 2025 17:49:23 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
Message-ID: <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>

On Tue, 7 Oct 2025 17:27:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Can we loop to L_clinit_barrier_slow several times until class is initialized?

No, `clinit_barrier` either "blocks" (not yet initialized or being initialized, but not in init thread) or returns right away (fully initialized or being initialized and in init thread). No need for repeated attempts.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3377943496

From kvn at openjdk.org  Tue Oct  7 18:10:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 7 Oct 2025 18:10:14 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
Message-ID: <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>

On Tue, 7 Oct 2025 17:46:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > Can we loop to L_clinit_barrier_slow several times until class is initialized?
> 
> No, `clinit_barrier` either "blocks" (not yet initialized or being initialized, but not in init thread) or returns right away (fully initialized or being initialized and in init thread). No need for repeated attempts.

First, what do you mean "blocks"? It wait something with lock?

Second, my question was that slow path in `clinit_barrier` will jump to `L_clinit_barrier_slow` which is before `clinit_barrier` there are no branch there so after `call_VM` we again will call `clinit_barrier`? what I am missing?

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378009886

From asmehra at openjdk.org  Tue Oct  7 18:25:31 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 18:25:31 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
Message-ID: <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>

On Tue, 7 Oct 2025 18:07:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> First, what do you mean "blocks"? It wait something with lock?

> Second, my question was that slow path in clinit_barrier will jump to L_clinit_barrier_slow which is before clinit_barrier there are no branch there so after call_VM we again will call clinit_barrier? what I am missing?

`clinit_barrier` itself doesn't block. Its a quick check for class fully initialized or the current thread is the init thread. If not, then it jumps to the slow path. In this case slow path is the call to `InterpreterRuntime::resolve_from_cache` which may initialize the klass or get blocked if the klass is being initialized by another thread.
After returning it again executes `clinit_barrier`. But this time the class should have initialized, so it just falls through.

Also, I think `clinit_barrier` is not a very accurate name because it doesn't cause initialization of the klass. I think `fast_clinit_check` better conveys what it is doing, but that renaming can be done later if required.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378062190

From kvn at openjdk.org  Tue Oct  7 18:32:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 7 Oct 2025 18:32:01 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
Message-ID: <_eKaA0Y70YdMoZgwLyo8DfNkr50o90D3EF6pORqN0Hw=.c9972589-7815-4f40-9e0f-f795ee82d94f@github.com>

On Tue, 7 Oct 2025 18:22:21 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>>> > Can we loop to L_clinit_barrier_slow several times until class is initialized?
>>> 
>>> No, `clinit_barrier` either "blocks" (not yet initialized or being initialized, but not in init thread) or returns right away (fully initialized or being initialized and in init thread). No need for repeated attempts.
>> 
>> First, what do you mean "blocks"? It wait something with lock?
>> 
>> Second, my question was that slow path in `clinit_barrier` will jump to `L_clinit_barrier_slow` which is before `clinit_barrier` there are no branch there so after `call_VM` we again will call `clinit_barrier`? what I am missing?
>
>> First, what do you mean "blocks"? It wait something with lock?
> 
>> Second, my question was that slow path in clinit_barrier will jump to L_clinit_barrier_slow which is before clinit_barrier there are no branch there so after call_VM we again will call clinit_barrier? what I am missing?
> 
> `clinit_barrier` itself doesn't block. Its a quick check for class fully initialized or the current thread is the init thread. If not, then it jumps to the slow path. In this case slow path is the call to `InterpreterRuntime::resolve_from_cache` which may initialize the klass or get blocked if the klass is being initialized by another thread.
> After returning it again executes `clinit_barrier`. But this time the class should have initialized, so it just falls through.
> 
> Also, I think `clinit_barrier` is not a very accurate name because it doesn't cause initialization of the klass. I think `fast_clinit_check` better conveys what it is doing, but that renaming can be done later if required.

Thank you @ashu-mehra  for explanation. So we can call `clinit_barrier` second time but not more. Good.

> fast_clinit_check better conveys what it is doing,

Agree.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378084056

From kvn at openjdk.org  Tue Oct  7 18:43:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 7 Oct 2025 18:43:06 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
Message-ID: <jZipJ3VrGxA3vvaEYluEFtwBG5fyK_PCniLn8Zv_QuY=.120abc1b-3dc3-46a9-822c-e1c67606f241@github.com>

On Tue, 7 Oct 2025 14:49:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

I submitted our testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378177808

From dcubed at openjdk.org  Tue Oct  7 18:58:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 7 Oct 2025 18:58:37 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <MbiU7J9_xs0o0DVb_F4Gp-yYbY6_iQl-3i4QmfrO5qk=.2c0b37a2-c88c-4166-bd0c-6bf4ff184c56@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
 <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
 <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>
 <MbiU7J9_xs0o0DVb_F4Gp-yYbY6_iQl-3i4
 QmfrO5qk=.2c0b37a2-c88c-4166-bd0c-6bf4ff184c56@github.com>
Message-ID: <Ag5rLLSg9u_XaVvBfz5VTm7APMr6tl-zXbpOG-mEl-M=.c82d4b4c-e52e-456b-bd40-193207acd0d1@github.com>

On Tue, 7 Oct 2025 07:07:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it is difficult for the following reasons:
>> 
>> 1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c
>> 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future.
>
> Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
> 
> I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
> 
> So where does this leave us?
> - `cores_per_cpu` is an approximation
> -  anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation

Based on the comments that I'm reading in this PR, it seems like the existing logic
presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing
(AMP) or is the AMP support in a different place in the code.

A very long time ago, Solaris SPARC servers could be provisioned with differing processors
with different core counts and speed ratings. I don't know if we supported those AMP
servers in Java or not, but there was definitely support in Solaris itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2411598511

From asmehra at openjdk.org  Tue Oct  7 19:05:09 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 19:05:09 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v3]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <JCMZgFjLeTJHTPNZ8GohiE569q8GO49B297a6EAJi8s=.6b023a94-a61c-4952-8bf5-146968d3e608@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Add support for s390
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/995d4bbb..0ef8bddc

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

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

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

From asmehra at openjdk.org  Tue Oct  7 19:05:10 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 19:05:10 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <87C_6FuOFoMBTzG5So9cza63FT6qRyOqK8DJIuyn8Yc=.a21361ef-7013-46a5-a264-b7dc201e0e86@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <uEFqdPEdmXMKCZTXtIycCL9XcdsA-kjgBcbd3hQxot8=.96ddb44f-464f-4715-b921-0c1717cc4be1@github.com>
 <87C_6FuOFoMBTzG5So9cza63FT6qRyOqK8DJIuyn8Yc=.a21361ef-7013-46a5-a264-b7dc201e0e86@github.com>
Message-ID: <BCXTRSFLRcZaZpve0Av6oDXGDWqgqZ4rHfaouLlI3e0=.f30878aa-b4be-418c-8757-883e026c8280@github.com>

On Tue, 7 Oct 2025 16:37:24 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar @Hamlin-Li  @RealFYang @TheRealMDoerr 
>> I need help in adding arch specific code for s390, risc-v and ppc for this PR. Would you be able to contribute the code for these platforms? Specifically, we need to add a call to `clinit_barrier` in `TemplateTable::resolve_cache_and_index_for_field`.
>> 
>> @vnkozlov  @adinn @iwanowww can you please review this patch.
>
> Hi @ashu-mehra,
> 
> This is fixing the test failure on s390: 
> 
> 
> diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp
> index 2b39cc8318c..cf34bff7746 100644
> --- a/src/hotspot/cpu/s390/templateTable_s390.cpp
> +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp
> @@ -2409,6 +2409,7 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>  
>    NearLabel resolved;
> +  Label L_clinit_barrier_slow;
>  
>    Bytecodes::Code code = bytecode();
>    switch (code) {
> @@ -2425,6 +2426,8 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>    __ z_bre(resolved);
>  
>    // resolve first time through
> +  // Class initialization barrier slow path lands here as well.
> +  __ bind(L_clinit_barrier_slow);
>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>    __ load_const_optimized(Z_ARG2, (int)code);
>    __ call_VM(noreg, entry, Z_ARG2);
> @@ -2434,6 +2437,15 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>  
>    __ bind(resolved);
>  
> +  // Class initialization barrier for static fields
> +  if (VM_Version::supports_fast_class_init_checks() &&
> +      (bytecode() == Bytecodes::_getstatic || bytecode() == Bytecodes::_putstatic)) {
> +    const Register field_holder = index;
> +
> +    __ load_sized_value(field_holder, Address(cache, ResolvedFieldEntry::field_holder_offset()), sizeof(void*), false);
> +    __ clinit_barrier(field_holder, Z_thread, nullptr /*L_fast_path*/, &L_clinit_barrier_slow);
> +  }
> +
>    BLOCK_COMMENT("} resolve_cache_and_index_for_field");
>  }

@offamitkumar thanks for the patch. I have added it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378302987

From vlivanov at openjdk.org  Tue Oct  7 19:05:11 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Oct 2025 19:05:11 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
Message-ID: <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>

On Tue, 7 Oct 2025 18:22:21 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> After returning it again executes clinit_barrier. But this time the class should have initialized, so it just falls through.

There are no guarantees that the class is initialized. But the only case when it doesn't hold is when the class is being initialized and current thread is initializing one. So, it is guaranteed that slow path is taken at most once. 

> I think fast_clinit_check better conveys what it is doing

`clinit_barrier` implements a fast path check, so `clinit_barrier_fast_path` maybe a more accurate variant.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378320299

From asmehra at openjdk.org  Tue Oct  7 19:15:36 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Oct 2025 19:15:36 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
 <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
Message-ID: <Iu-81c4fMv0IU9QUicQVlgfLGS7vhipRBmP-ABJpPjo=.41996e36-8481-4942-8627-a17d7d1eebbd@github.com>

On Tue, 7 Oct 2025 19:02:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> clinit_barrier implements a fast path check, so clinit_barrier_fast_path maybe a more accurate variant.

yes, `clinit_barrier_fast_path` is better.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378351865

From mbeckwit at openjdk.org  Tue Oct  7 20:40:31 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Tue, 7 Oct 2025 20:40:31 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <UG79wN8Id7tooBVEDhlXlb4Uj-zGy4uVoMOwnN744qc=.8b02ea38-046e-4811-bcd9-ed34f0facc96@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <gxcHXLs8hO_LFLcOjIvGYsBtRP8i7F39EvaAmhy4tw4=.abb98a57-015c-4fed-8d8d-6a2f3e7f3ed0@github.com>
 <xILt8n9pT6aY1Om3Ftn2-mAXzC7jSP30JSG_I3PYMfo=.371d9d72-72e8-48b1-a084-3db2659d2b69@github.com>
 <XP4qCWHg0d7fPdT0i8eJqV5UA6JuA6XT5FFkb3-1Fwk=.2b438b7a-4f8b-4727-8f3a-85a3eed586b0@github.com>
 <UG79wN8Id7tooBVEDhlXlb4Uj-zGy4uVoMOwnN744qc=.8b02ea38-046e-4811-bcd9-ed34f0facc96@github.com>
Message-ID: <Pg9nD-LCFcQjcChaO4eHzRXJXndMiaboxKpNIcD_pMU=.b23f0c67-10d6-4435-b4bd-71ffb4b0d477@github.com>

On Tue, 2 Sep 2025 10:15:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> I also do not think this mechanism should ever uncommit the free regions reserved for the current young gen (without GC/recalculating the needed young gen) and potentially the survivor/old regions. There does not seem to be a limit here.
>> 
>> Otherwise the next GC (or just continuing work) will be riddled with in-pause commits. Or it will probably do a premature GC, I did not check.
>> 
>> Maybe this change should only madvise these regions as MADV_DONTNEED? (Not sure it does anything though).
>
> Also there should potentially be a buffer for humongous object allocation, otherwise they will cause immediate garbage collections.
> I.e.: err on the conservative side.

I have added multiple checks now:

GC Pressure:


 // Back off during allocation pressure - only evaluate when truly idle
  if (_analytics != nullptr) {
    double gc_time_ratio = _analytics->short_term_pause_time_ratio();
    if (gc_time_ratio > 0.05) { // 5% GC time still indicates pressure
      log_trace(gc, sizing)("Uncommit evaluation: skipping due to high GC overhead (%1.1f%%)", 
                           gc_time_ratio * 100.0);
      return 0;
    }
  }

 
 Reserve Calculation:
 
       // Use G1's existing reserve calculation plus young generation requirements
      // G1 maintains a reserve (default 10% via G1ReservePercent) for allocation needs
      size_t young_gen_regions = _g1h->policy()->young_list_target_length();
      size_t total_regions = _g1h->max_num_regions();
      size_t g1_reserve_regions = (size_t)ceil((double)total_regions * G1ReservePercent / 100.0);
      
      // Total regions we must keep available = young gen + G1's standard reserve
      size_t reserved_regions = young_gen_regions + g1_reserve_regions;
      
Conservative Limits:

      // Be very conservative about how much to uncommit at once
      // Never uncommit more than a small fraction of committed regions
      size_t max_uncommit_at_once = MAX2((size_t)G1MinRegionsToUncommit, committed_regions / 8);
      size_t regions_to_uncommit = MIN3(available_for_uncommit, max_inactive_regions, max_uncommit_at_once);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2411798199

From mbeckwit at openjdk.org  Tue Oct  7 21:01:39 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Tue, 7 Oct 2025 21:01:39 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <xILt8n9pT6aY1Om3Ftn2-mAXzC7jSP30JSG_I3PYMfo=.371d9d72-72e8-48b1-a084-3db2659d2b69@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <gxcHXLs8hO_LFLcOjIvGYsBtRP8i7F39EvaAmhy4tw4=.abb98a57-015c-4fed-8d8d-6a2f3e7f3ed0@github.com>
 <xILt8n9pT6aY1Om3Ftn2-mAXzC7jSP30JSG_I3PYMfo=.371d9d72-72e8-48b1-a084-3db2659d2b69@github.com>
Message-ID: <u6nkrXcN3fC-E_JkukDyb1DFVOUIXP1aYFzgARCgFH4=.5025d245-0417-4a17-b226-7e3b7f27a43b@github.com>

On Tue, 2 Sep 2025 09:38:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static _uncommit_delay member and accessor
>
> src/hotspot/share/gc/g1/g1VMOperations.cpp line 175:
> 
>> 173: 
>> 174: void VM_G1ShrinkHeap::doit() {
>> 175:   _g1h->shrink(_bytes);
> 
> I strongly believe that the shrink amount needs to be re-evaluated in the shrink pause again (ideally it would not need a VM operation, but I think this is not necessary for now). Between posting the VM operation and actual execution there can be any number of more (GC) VM operations that can change the shape of the heap, so the amount of necessary shrinking can change substantially.
> 
> Also, there needs to be some synchronization between the selection of regions made during determining that we should do this and the actual shrinking.
> 
> There is the risk that the region selection bases its decision based on e.g. region A, B, C being too old, and then uncommits regions D, E, and F here. Next time the idleness will be evaluated, regions A, B, and C will be found again as too old, so keeping on shrinking until eventually A, B, and C are uncommitted.
> 
> However the original goal of the method would have been to _only_ uncommit A, B and C. Which means this mechanism uncommitted way too many regions.

I have added execution-time handling that uses a pre-evaluated shrink amount but performs fresh region selection at VM operation execution time:

`_g1h->shrink_with_time_based_selection(_bytes);`

At execution time, we do the calculation/fresh eval by clearing the cache and applying the time-based criteria:


void G1CollectedHeap::shrink_with_time_based_selection(size_t shrink_bytes) {
  // Fresh region scanning and validation at VM operation execution time
  _hrm.remove_all_free_regions();
  shrink_helper_with_time_based_selection(aligned_shrink_bytes);
  rebuild_region_sets(true);
}

The actual region selection:

`num_regions_removed = _hrm.shrink_by(num_regions_to_remove, true /* use_time_based_selection */);`

This should address the stale region selection concern (A,B,C ? D,E,F) by ensuring region eligibility is determined fresh at VM operation execution time rather than using potentially outdated information from the scheduling phase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2411912340

From dlong at openjdk.org  Tue Oct  7 21:06:34 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Oct 2025 21:06:34 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <5zp2DW3Dxpfi1AkzodWNMS1hq_dgejRK2IztXht7rN0=.240f8764-5dbc-4f62-801f-628220ec4e4f@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>
 <XTkmae7BFlwck7FmgVC4xu-af9BWuzBMCvjB-KB1QUY=.95629e5e-6657-41d4-ad61-6ed3f3c538dd@github.com>
 <5zp2DW3Dxpfi1AkzodWNMS1hq_dgejRK2IztXht7rN0=.240f8764-5dbc-4f62-801f-628220ec4e4f@github.com>
Message-ID: <Vn8G1oqk9ic0cmonQP2FjEp-ilM1iQlT3-y8tAjpC7A=.200da6a4-7ad5-4675-9e70-48c713d455ee@github.com>

On Tue, 7 Oct 2025 08:30:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> I don't think copy() is ever called. Can we remove it?
>> 
>> Sure.
>
>> > I don't think copy() is ever called. Can we remove it?
>> 
>> Sure.
> 
> Ah no. `copy()` is called after the anchor is constructed.

I missed that because I had commented out the JavaFrameAnchor(JavaFrameAnchor *src) ctor, thinking it was the only use, and it still builds.

I tried to research what this comment is about:
    // Hack Alert: Temporary bugfix for 4717480/4721647
and my conclusion is that it seems to be left over from an earlier safepoint implementation where the VM thread could look at the anchor of other threads while they were still running.  I don't think we do that anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2411926281

From mbeckwit at openjdk.org  Tue Oct  7 21:09:18 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Tue, 7 Oct 2025 21:09:18 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <xILt8n9pT6aY1Om3Ftn2-mAXzC7jSP30JSG_I3PYMfo=.371d9d72-72e8-48b1-a084-3db2659d2b69@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <gxcHXLs8hO_LFLcOjIvGYsBtRP8i7F39EvaAmhy4tw4=.abb98a57-015c-4fed-8d8d-6a2f3e7f3ed0@github.com>
 <xILt8n9pT6aY1Om3Ftn2-mAXzC7jSP30JSG_I3PYMfo=.371d9d72-72e8-48b1-a084-3db2659d2b69@github.com>
Message-ID: <sHyjgFsbRySl6SrxBpYFpbDznoy7xEasdzGknefZNJQ=.8abfda4d-9520-462c-ab06-845d3a52835e@github.com>

On Tue, 2 Sep 2025 10:01:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused static _uncommit_delay member and accessor
>
> src/hotspot/share/gc/g1/g1HeapEvaluationTask.cpp line 37:
> 
>> 35: 
>> 36: G1HeapEvaluationTask::G1HeapEvaluationTask(G1CollectedHeap* g1h, G1HeapSizingPolicy* heap_sizing_policy) :
>> 37:   PeriodicTask(G1TimeBasedEvaluationIntervalMillis),  // Use PeriodicTask with interval
> 
> Periodic tasks do not have a flexible interval. So making `G1TimeBasedEvaluationIntervalMillis` manageable and changing it will have no effect (and `PeriodicTask` does not support changing intervals).

I have changed it to use the G1Service task framework

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26240#discussion_r2411931348

From mbeckwit at openjdk.org  Tue Oct  7 23:18:19 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Tue, 7 Oct 2025 23:18:19 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <LUHIyRiHzGeiS7s7HqJWUW2rPKsJmiAPT-zslpKOPug=.c3de5773-7a1e-45e5-993d-a97740808826@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
 <gxcHXLs8hO_LFLcOjIvGYsBtRP8i7F39EvaAmhy4tw4=.abb98a57-015c-4fed-8d8d-6a2f3e7f3ed0@github.com>
 <LUHIyRiHzGeiS7s7HqJWUW2rPKsJmiAPT-zslpKOPug=.c3de5773-7a1e-45e5-993d-a97740808826@github.com>
Message-ID: <uCpt3iMmLt2BXltmDkabCsRk-ztvvSW8rSX5eUfTrq4=.f4404c23-187c-4129-bfe8-86d57a556071@github.com>

On Tue, 2 Sep 2025 10:17:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Also, garbage collections and the `VM_G1ShrinkHeap` operation need to reset the timestamp for all (free) regions too. Otherwise the mechanism will try to uncommit the wrong amount of regions, similar to the issue I described in `VM_G1ShrinkHeap`.
> 
> E.g. Regions A, B, C are free for a long time, GC happens that keeps A, B, C for various reasons, now idle-evaluation happens, and A, B, C are determined idle in addition to the other regions if their timestamp is not reset. So the idle uncommit will free too many regions.

Makes sense. I have added activity tracking in region transitions:


void G1HeapRegion::set_free() {
  if (!is_free()) {
    report_region_type_change(G1HeapRegionTraceType::Free);
    record_activity(); // Updates timestamp when region becomes free
  }
  _type.set_free();
}

Hence, during GC operations like shown below the timestamp will be updated:


bool RebuildRegionSetsClosure::do_heap_region(G1HeapRegion* r) {
  if (r->is_empty()) {
    r->set_free();  // This updates timestamps for regions processed during GC
    _hrm->insert_into_free_list(r);
  }
  // ...
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3379007364

From ysuenaga at openjdk.org  Wed Oct  8 00:13:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 00:13:42 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <Ag5rLLSg9u_XaVvBfz5VTm7APMr6tl-zXbpOG-mEl-M=.c82d4b4c-e52e-456b-bd40-193207acd0d1@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
 <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
 <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>
 <MbiU7J9_xs0o0DVb_F4Gp-yYbY6_iQl-3i4
 QmfrO5qk=.2c0b37a2-c88c-4166-bd0c-6bf4ff184c56@github.com>
 <Ag5rLLSg9u_XaVvBfz5VTm7APMr6tl-zXbpOG-mEl-M=.c82d4b4c-e52e-456b-bd40-193207acd0d1@github.com>
Message-ID: <KBKkNhbzltmbzHjNR9E9pGW8FT8V-J-1OiW8E2D5Y34=.12d4f578-a6a4-4b47-ac23-d95c027bef8a@github.com>

On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
>> 
>> I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
>> 
>> So where does this leave us?
>> - `cores_per_cpu` is an approximation
>> -  anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation
>
> Based on the comments that I'm reading in this PR, it seems like the existing logic
> presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing
> (AMP) or is the AMP support in a different place in the code.
> 
> A very long time ago, Solaris SPARC servers could be provisioned with differing processors
> with different core counts and speed ratings. I don't know if we supported those AMP
> servers in Java or not, but there was definitely support in Solaris itself.

I updated this PR to revert data type change to `uint`, so number of cores might be incorrect on hybrid CPU. "cores" in `jdk.CPUInformation` event would be set "approximated" value, but "Hybrid Architecture" would be added into "description" field in that case.

I grep'ed to find user of `cores_per_cpu`, this value would be used in JFR and reporting only like I've fixed in #26808 , thus this change affects limited area only AFAICS.

> Based on the comments that I'm reading in this PR, it seems like the existing logic
presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing
(AMP) or is the AMP support in a different place in the code.

Has Intel released AMP processor for Xeon / Core line? If AMP is SPARC only in context of Java, it would be implemented on SPARC-specific code, but it has already gone...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412215707

From duke at openjdk.org  Wed Oct  8 01:19:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 8 Oct 2025 01:19:13 GMT
Subject: Withdrawn: 8363620: AArch64: reimplement emit_static_call_stub()
In-Reply-To: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
References: <4QaWBuyp2crNgc4QfWw3l4oUbtCxizQaTm6LndmoydQ=.c8d81eba-eab5-4b3d-b272-c958e5237601@github.com>
Message-ID: <U4whyF0XCWU28cuhkUAogRD_0ZRhKW9eriGbGejEB3c=.a99a87f4-7ebb-4b40-ae6b-d6f28bb80c9e@github.com>

On Tue, 5 Aug 2025 10:30:13 GMT, Fei Gao <fgao at openjdk.org> wrote:

> In the existing implementation, the static call stub typically emits a sequence like:
> `isb; movk; movz; movz; movk; movz; movz; br`.
> 
> This patch reimplements it using a more compact and patch-friendly sequence:
> 
> ldr x12, Label_data
> ldr x8, Label_entry
> br x8
> Label_data:
>   0x00000000
>   0x00000000
> Label_entry:
>   0x00000000
>   0x00000000
> 
> The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations.
> 
> While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches.
> 
> A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%.
> 
> 
> Benchmark                       (length)   Mode   Cnt Master     Patch      Units
> StaticCallStubFar.callCompiled    1000     avgt   5   39.346     22.474     us/op
> StaticCallStubFar.callCompiled    10000    avgt   5   390.05     218.478    us/op
> StaticCallStubFar.callCompiled    100000   avgt   5   3869.264   2174.001   us/op
> StaticCallStubNear.callCompiled   1000     avgt   5   39.093     22.582     us/op
> StaticCallStubNear.callCompiled   10000    avgt   5   387.319    217.398    us/op
> StaticCallStubNear.callCompiled   100000   avgt   5   3855.825   2206.923   us/op
> 
> 
> All tests in Tier1 to Tier3, under both release and debug builds, have passed.
> 
> [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads

This pull request has been closed without being integrated.

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

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

From dlong at openjdk.org  Wed Oct  8 02:18:34 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 02:18:34 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception
Message-ID: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>

In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

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

Commit messages:
 - remove debug printlns
 - deoptimize on missing compiled exception handler
 - new test

Changes: https://git.openjdk.org/jdk/pull/27683/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367002
  Stats: 139 lines in 5 files changed: 131 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27683/head:pull/27683

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

From dholmes at openjdk.org  Wed Oct  8 03:15:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 03:15:02 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <Ag5rLLSg9u_XaVvBfz5VTm7APMr6tl-zXbpOG-mEl-M=.c82d4b4c-e52e-456b-bd40-193207acd0d1@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
 <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>
 <stDyigt3Y-rtOh9w7noaP5uB9Tw5Ao-UCDsx-I8JYJA=.159a9f31-ae10-438f-8ed6-07be514f82c1@github.com>
 <lKbbnVZsusEv0MQjb3w2xvcyOAxsKKcYAi5Y2HkYGi0=.6f62626e-60ff-48fa-b465-1ab2b54cf74e@github.com>
 <WSkZHzgyuX615aZrEsV75njJZ0Pda9b-XkYPc9tCDGE=.bb15e4b1-d2f3-40c8-8202-c05077226f18@github.com>
 <3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>
 <ROnsX7vWgm9evRGxWVR1UUsW6vH88Qpey2AclIjw5ws=.808381ad-20b3-4fcc-bb21-6b6ef4728b6b@github.com>
 <SB4CHuK0Yqlqs59I_C3chyMMd10cHVJbtzB7o4a0SRM=.aed4655f-5ab9-446d-9ee0-37e047143933@github.com>
 <MbiU7J9_xs0o0DVb_F4Gp-yYbY6_iQl-3i4
 QmfrO5qk=.2c0b37a2-c88c-4166-bd0c-6bf4ff184c56@github.com>
 <Ag5rLLSg9u_XaVvBfz5VTm7APMr6tl-zXbpOG-mEl-M=.c82d4b4c-e52e-456b-bd40-193207acd0d1@github.com>
Message-ID: <Pl7IhDlCO8zvwjRvYJ6Ems-daR8gm0x06rZ5uKPGF20=.d5235b98-cd11-4d5b-b310-bb0fe62a026d@github.com>

On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
>> 
>> I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
>> 
>> So where does this leave us?
>> - `cores_per_cpu` is an approximation
>> -  anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation
>
> Based on the comments that I'm reading in this PR, it seems like the existing logic
> presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing
> (AMP) or is the AMP support in a different place in the code.
> 
> A very long time ago, Solaris SPARC servers could be provisioned with differing processors
> with different core counts and speed ratings. I don't know if we supported those AMP
> servers in Java or not, but there was definitely support in Solaris itself.

@dcubed-ojdk my recollection is that the "symmetry" in SMP related to memory accesses - but there are differing definitions. There is also a presumption that all "logical processors" behave effectively the same, and for multi-socket systems all CPU's are the same. That is still true-enough with these Hybrid chips, they just don't have the same internal topology so we can't coarsely assume we can calculate things like "number of cores" by knowing number-of-threads and whether hyper-threading is enabled. Unfortunately you also cannot easily get the exact details of that topology.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412394944

From fyang at openjdk.org  Wed Oct  8 03:30:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 8 Oct 2025 03:30:02 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <Iu-81c4fMv0IU9QUicQVlgfLGS7vhipRBmP-ABJpPjo=.41996e36-8481-4942-8627-a17d7d1eebbd@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
 <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
 <Iu-81c4fMv0IU9QUicQVlgfLGS7vhipRBmP-ABJpPjo=.41996e36-8481-4942-8627-a17d7d1eebbd@github.com>
Message-ID: <YX9K0p98JWJ-pIE96Ec0zdF3z2LRCxQ9CoaHMrySeAo=.c4ca9c30-ffcd-4622-9933-6434d17798b0@github.com>

On Tue, 7 Oct 2025 19:12:34 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>>> After returning it again executes clinit_barrier. But this time the class should have initialized, so it just falls through.
>> 
>> There are no guarantees that the class is initialized. But the only case when it doesn't hold is when the class is being initialized and current thread is initializing one. So, it is guaranteed that slow path is taken at most once. 
>> 
>>> I think fast_clinit_check better conveys what it is doing
>> 
>> `clinit_barrier` implements a fast path check, so `clinit_barrier_fast_path` maybe a more accurate variant.
>
>> clinit_barrier implements a fast path check, so clinit_barrier_fast_path maybe a more accurate variant.
> 
> yes, `clinit_barrier_fast_path` is better.

@ashu-mehra
Hi, Thanks for the ping! And here is the riscv-specific changes:
[27676-riscv.diff.txt](https://github.com/user-attachments/files/22758069/27676-riscv.diff.txt)
`hotspot:tier1` and `hotspot_runtime` passed with fastdebug build on linux-riscv64.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3379436856

From dholmes at openjdk.org  Wed Oct  8 03:34:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 03:34:05 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
Message-ID: <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>

On Tue, 7 Oct 2025 14:04:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error

src/hotspot/cpu/x86/vm_version_x86.cpp line 2579:

> 2577:   if (threads_per_package == 0) {
> 2578:     // Fallback code to avoid div by zero in subsequent code.
> 2579:     // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)

Can we assert that this is not a hybrid CPU?

src/hotspot/share/jfr/metadata/metadata.xml line 855:

> 853: 
> 854:   <Event name="CPUInformation" category="Operating System, Processor" label="CPU Information"
> 855:          description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that &quot;cores&quot; field would be incorrect on hybrid CPU."

Perhaps better stated on the cores field:

<Field type="uint" name="cores" label="Cores (approximation on a hybrid CPU" />

? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC?

BTW I assume that "hwThreads" is the number of logical processors - right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412407479
PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412412315

From kbarrett at openjdk.org  Wed Oct  8 04:01:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 04:01:28 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the C++
 Standard Library
Message-ID: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>

Please review this change to the HotSpot Style Guide to suggest that C++
Standard Library components may be used, after appropriate vetting and
discussion, rather than just a blanket "no, don't use it" with a few very
narrow exceptions. It provides some guidance on that vetting process and
the criteria to use, along with usage patterns.

In particular, it proposes that Standard Library headers should not be
included directly, but instead through HotSpot-provided wrapper headers. This
gives us a place to document usage, provide workarounds for platform issues in
a single place, and so on.

Such wrapper headers are provided by this PR for <cstddef>, <limits>, and
<type_info>, along with updates to use them. I have a separate change for
<new> that I plan to propose later, under JDK-8369187. There will be
additional followups for other C compatibility headers besides <cstddef>.

This PR also cleans up some nomenclature issues around forbid vs exclude and
the like.

Testing: mach5 tier1-5, GHA sanity tests

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

Commit messages:
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369186
  Stats: 623 lines in 68 files changed: 383 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From dholmes at openjdk.org  Wed Oct  8 04:56:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 04:56:02 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <R2la5XahUigPOTo6MHY5r17IOwq15a_WQw1Dciy9kw4=.b76d5d30-89c5-47c6-952a-1ca0a3023688@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
 <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>
 <KTQ9ZY-H51_DB9fg8yi1nFrueNF7GM3pEUeqHVeWJTQ=.acb5bd3c-0e85-4aac-9e94-5f4b7b4f7bad@github.com>
 <R2la5XahUigPOTo6MHY5r17IOwq15a_WQw1Dciy9kw4=.b76d5d30-89c5-47c6-952a-1ca0a3023688@github.com>
Message-ID: <BHFyRbkCc2gOMjej5z_0K0IyVqW9WNMWgChavqxckaM=.24aa671d-62eb-499e-a348-d0ac356b41ab@github.com>

On Tue, 7 Oct 2025 12:19:43 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> What I'm after is a clean way to get those numbers separately. Pairing machine_ and container_ gives access to both pieces of data, offering just the machine side would leave us without a direct path to the container value.

I don't like the naming "machine_" here - yes naming is hard and subjective - these "machine" API's are reporting whatever the operating system is exposing to the process.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3379562722

From kbarrett at openjdk.org  Wed Oct  8 05:04:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 05:04:48 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v2]
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <XySWtD69yeleklBjWgNGEoM3cpxsOdis3GxCCRDHPPc=.546995c9-bba9-4350-9148-6deef9a9e268@github.com>

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

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 12 additional commits since the last revision:

 - Merge branch 'master' into atomic-template-tag-select
 - add reference to gcc bug we're working around
 - fix typo in comment
 - update copyrights
 - update FreeListAllocator
 - update nonblockingQueue
 - update LockFreeStack
 - convert StringDedupTable
 - convert SingleWriterSynchronizer
 - test_atomic
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8160408a...8cdc458d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27539/files
  - new: https://git.openjdk.org/jdk/pull/27539/files/0c0f7ceb..8cdc458d

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

  Stats: 14734 lines in 586 files changed: 8479 ins; 3029 del; 3226 mod
  Patch: https://git.openjdk.org/jdk/pull/27539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27539/head:pull/27539

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

From dholmes at openjdk.org  Wed Oct  8 05:48:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 05:48:11 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v2]
In-Reply-To: <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
Message-ID: <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>

On Tue, 7 Oct 2025 15:40:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [ ] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cannot allocate for Thread::name + adjust debug levels

Generally seems okay but a few queries.

src/hotspot/share/runtime/safepoint.cpp line 169:

> 167:     LogStream ls(lt);
> 168:     cur_state->print_on(&ls);
> 169:   }

Why is this not useful for debugging? I can understand you might not need it for your profiling but UL is primarily about debugging assistance.

src/hotspot/share/runtime/safepoint.cpp line 261:

> 259: 
> 260:     if (still_running > 0) {
> 261:       log_trace(safepoint)("Waiting for threads to block");

Suggestion:

      log_trace(safepoint)("Waiting for %d threads to block", still_running);

?

src/hotspot/share/runtime/safepoint.cpp line 348:

> 346:   _nof_threads_hit_polling_page = 0;
> 347: 
> 348:   log_debug(safepoint)("Safepoint synchronization initiated using %s wait barrier. (%d threads)", _wait_barrier->description(), nof_threads);

I don't see the point in moving this partially into `SafepointTracing::begin` but losing the information as to how many threads are being handled.

src/hotspot/share/runtime/sharedRuntime.cpp line 643:

> 641:   return raw_exception_handler_for_return_address(current, return_address);
> 642: JRT_END
> 643: 

Again this seems useful for debugging.

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

PR Review: https://git.openjdk.org/jdk/pull/27673#pullrequestreview-3312869992
PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412549283
PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412529765
PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412543617
PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412572697

From dholmes at openjdk.org  Wed Oct  8 06:00:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 06:00:03 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception
In-Reply-To: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
Message-ID: <cOnK1dVTqQK0y0q3trfrr7zmhyS30lRusyPV1ZA6d3w=.df24534e-6f42-416e-8c13-8a55a7225708@github.com>

On Wed, 8 Oct 2025 02:09:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

test/hotspot/jtreg/compiler/exceptions/IllegalAccessInCatch.jasm line 24:

> 22:  */
> 23: 
> 24: super class IllegalAccessInCatch

Psuedo-code as a comment would be useful for those not fluent in asm.

test/hotspot/jtreg/compiler/exceptions/TestAccessErrorInCatch.java line 30:

> 28:  *
> 29:  * @compile IllegalAccessInCatch.jasm
> 30:  * @run main/othervm -Xbatch TestAccessErrorInCatch

Should this test be disabled if explicit compilation directives (e.g. `-Xcomp`) are being passed in?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27683#discussion_r2412601707
PR Review Comment: https://git.openjdk.org/jdk/pull/27683#discussion_r2412607048

From ysuenaga at openjdk.org  Wed Oct  8 06:17:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 06:17:06 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
 <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>
Message-ID: <dqI2FH-UmyiZUAH9hFDg3Jkomf_mw2kC8B-foyVcgwI=.e471efee-2c83-4ebc-a343-7df70229ad18@github.com>

On Wed, 8 Oct 2025 03:25:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build error
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 2579:
> 
>> 2577:   if (threads_per_package == 0) {
>> 2578:     // Fallback code to avoid div by zero in subsequent code.
>> 2579:     // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
> 
> Can we assert that this is not a hybrid CPU?

Maybe yes. I checked `CPUID` 0Bh subleaf 1 on both Core Ultra 5 135U and 225U, they reports correct number of logical processors. However I cannot check all of hybrid CPUs and I'm not sure all of them should return correct value at here. Thus I'm not sure we can add `assert` here for hybrid CPU.

> BTW I assume that "hwThreads" is the number of logical processors - right?

Yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412657326
PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412657709

From ysuenaga at openjdk.org  Wed Oct  8 06:27:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 06:27:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v6]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <BNRvDTmfWKElZJfURa7xDBAANBob5MYWuWh6pb5pjtE=.28ed10a2-7681-4233-afb2-b844def373c5@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update metadata.xml

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/a0520474..126feb9d

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

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

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

From ysuenaga at openjdk.org  Wed Oct  8 06:53:26 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 06:53:26 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v7]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <kXGecXvBw8ECiEuQx83C4RZVR6UvjkCvPatiK69Yj58=.1a532532-1e84-4934-898c-d935dba1f56f@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add description attribute to Field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/126feb9d..a9dbfb99

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

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

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

From ysuenaga at openjdk.org  Wed Oct  8 06:53:28 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 06:53:28 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <dqI2FH-UmyiZUAH9hFDg3Jkomf_mw2kC8B-foyVcgwI=.e471efee-2c83-4ebc-a343-7df70229ad18@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
 <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>
 <dqI2FH-UmyiZUAH9hFDg3Jkomf_mw2kC8B-foyVcgwI=.e471efee-2c83-4ebc-a343-7df70229ad18@github.com>
Message-ID: <dXSTy7hJzjv6dFvbWn4SXPv-ubWDZDphvcRttF7m34s=.2f070fec-99a8-4c4f-a1bf-8f40c23539b6@github.com>

On Wed, 8 Oct 2025 06:14:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 855:
>> 
>>> 853: 
>>> 854:   <Event name="CPUInformation" category="Operating System, Processor" label="CPU Information"
>>> 855:          description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that &quot;cores&quot; field would be incorrect on hybrid CPU."
>> 
>> Perhaps better stated on the cores field:
>> 
>> <Field type="uint" name="cores" label="Cores (approximation on a hybrid CPU" />
>> 
>> ? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC?
>> 
>> BTW I assume that "hwThreads" is the number of logical processors - right?
>
>> BTW I assume that "hwThreads" is the number of logical processors - right?
> 
> Yes

> Perhaps better stated on the cores field:

Thanks for your comment! I added that sentence to `description` attribute in `Field` element.
After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip)


$ jfr metadata --events jdk.CPUInformation /tmp/test.jfr
@Name("jdk.CPUInformation")
@Category({"Operating System", "Processor"})
@Label("CPU Information")
@Description("Characteristics and descriptions of the processor(s) the JVM is running on")
class CPUInformation extends jdk.jfr.Event {
  @Label("Start Time")
  @Timestamp("TICKS")
  long startTime;

  @Label("Type")
  String cpu;

  @Label("Description")
  String description;

  @Unsigned
  @Label("Sockets")
  int sockets;

  @Unsigned
  @Label("Cores")
  @Description("Approximation on a hybrid CPU")
  int cores;

  @Unsigned
  @Label("Hardware Threads")
  int hwThreads;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412763021

From fyang at openjdk.org  Wed Oct  8 06:54:13 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 8 Oct 2025 06:54:13 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
Message-ID: <tVKRKLrQSZQ2_LCi95uBLvDEY_8kD9Eh9glYubM-p4k=.dcf0fab8-3e5a-46e1-ab27-c133ea2992c4@github.com>

On Tue, 7 Oct 2025 10:19:39 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> But why is not vector size/length called:
>> `VM_Version::non_ext::rvv_vlen()`  or similar ? Should it ?
>> 
>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public:
>> VM_Version::ziboz_block_size() ?
>> 
>> I added:
>> `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>> 
>> 
>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>> 
>> Can we agree to one consistent way?
>
>> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?
> 
> I think this should be in another pr.
> 
>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?
> 
> If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.
> 
>> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>> Can we agree to one consistent way?
> 
> As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.

That reminds me of a previous discussion about non-extension features [1].
It doesn't seem to be necessary to have a `enabled()` check for non-extension features like `zicboz_block_size`, `mvendorid`, etc. So we might want to remove this check and give these features a default value (maybe -1 as suggested by @Hamlin-Li).

This is just like how the global flags are used. It will have a valid value if it could be detected from hwprobe interface at JVM startup. Hopefully, that will simplify the use sites of them a bit making it more consistent. In this repect, it works for me if we keep using the current naming, like `VM_Version::zicboz_block_size.value()`.

[1] https://github.com/openjdk/jdk/pull/27512#discussion_r2387421424

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2412752454

From rehn at openjdk.org  Wed Oct  8 06:54:14 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 8 Oct 2025 06:54:14 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <tVKRKLrQSZQ2_LCi95uBLvDEY_8kD9Eh9glYubM-p4k=.dcf0fab8-3e5a-46e1-ab27-c133ea2992c4@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
 <tVKRKLrQSZQ2_LCi95uBLvDEY_8kD9Eh9glYubM-p4k=.dcf0fab8-3e5a-46e1-ab27-c133ea2992c4@github.com>
Message-ID: <dV1z3r0vdKnqxfPi3ZFvTJj4tKGjADffT3U0wMtnff4=.00392dac-2f7d-4683-81d1-c7210e3049b5@github.com>

On Wed, 8 Oct 2025 06:46:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?
>> 
>> I think this should be in another pr.
>> 
>>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?
>> 
>> If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.
>> 
>>> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>>> Can we agree to one consistent way?
>> 
>> As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.
>
> That reminds me of a previous discussion about non-extension features [1].
> It doesn't seem to be necessary to have a `enabled()` check for non-extension features like `zicboz_block_size`, `mvendorid`, etc. So we might want to remove this check and give these features a default value (maybe -1 as suggested by @Hamlin-Li).
> 
> This is just like how the global flags are used. It will have a valid value if it could be detected from hwprobe interface at JVM startup. Hopefully, that will simplify the use sites of them a bit making it more consistent. In this repect, it works for me if we keep using the current naming, like `VM_Version::zicboz_block_size.value()`.
> 
> [1] https://github.com/openjdk/jdk/pull/27512#discussion_r2387421424

I don't have strong opinions except can we please make it as consistent as possible and make the actual useages (masm/stubs/instrinsic/ad) easy to read/review.
If you say this PR is on that part of such road-map, please go ahead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2412764993

From shade at openjdk.org  Wed Oct  8 07:03:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 07:03:42 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v3]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <baxnm5mHivDymgZxuaEwli4VrJnOn83YnJeBk8SXQDE=.0b51bf5a-fb54-4814-b224-8dd0ca9248bb@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/safepoint.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/22700224..c67d4a6a

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

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

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

From fyang at openjdk.org  Wed Oct  8 07:04:11 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 8 Oct 2025 07:04:11 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
Message-ID: <MSBpil5SJHsM4Gt9tYAlLzrzfOifYrrE5pKWsZzuICI=.a82a1cf8-c077-443b-a4da-82abcc074220@github.com>

On Tue, 7 Oct 2025 10:19:39 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> But why is not vector size/length called:
>> `VM_Version::non_ext::rvv_vlen()`  or similar ? Should it ?
>> 
>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public:
>> VM_Version::ziboz_block_size() ?
>> 
>> I added:
>> `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>> 
>> 
>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>> 
>> Can we agree to one consistent way?
>
>> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?
> 
> I think this should be in another pr.
> 
>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?
> 
> If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.
> 
>> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>> Can we agree to one consistent way?
> 
> As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.

@Hamlin-Li : Can we remove the `non_ext_` name prefix for non-extension features and maybe the `enabled()` check as well as we previously discussed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2412799354

From stefank at openjdk.org  Wed Oct  8 07:10:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 8 Oct 2025 07:10:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_info>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

doc/hotspot-style.md line 1658:

> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
> 1657: class is preferred to a tuple.
> 1658: 

I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.

I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.

src/hotspot/share/utilities/tuple.hpp line 2:

> 1: /*
> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

So we have our own tuple ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2412807041
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2412811951

From ssarathi at openjdk.org  Wed Oct  8 07:21:12 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Wed, 8 Oct 2025 07:21:12 GMT
Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers
 [v5]
In-Reply-To: <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
 <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
Message-ID: <1Mf6R5LDxIYmOGI1S0LQ9dNDxUMSk-TqCANEYrYp4Aw=.660eb1a5-9790-4ba8-b0df-d08da4daa740@github.com>

On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage.
>
> Martin Doerr 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 remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Move nmethod entry barrier code up in the signal handler.
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - 8334247: [PPC64] Consider trap based nmethod entry barriers

I've re-ran the benchmarks after fixing the java version issue. The updated results show slight but consistent performance improvements across most benchmarks with trap build compared to master baseline, and no regressions were observed.

It indicates the changes bring low level efficiency gain - the fix optimises general runtime behaviour rather than any GC specific tuning. 
<img width="1400" height="800" alt="gc_runtime_heatmap-final" src="https://github.com/user-attachments/assets/65017782-74fe-4781-acea-779425010ee6" />

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

PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3380084526

From shade at openjdk.org  Wed Oct  8 07:36:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 07:36:34 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v4]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <e1VCua-Kuj48yCJ8YYfi23mregaoUikGJggIILaCax0=.c00badcd-1205-483d-86fd-650efec0fd8b@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Rethink safepoint sync logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/c67d4a6a..5f4a13a4

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

  Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27673/head:pull/27673

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

From shade at openjdk.org  Wed Oct  8 07:36:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 07:36:36 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v4]
In-Reply-To: <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
Message-ID: <NZe971yV2E5KK5HmmoNziCeu-Jp_KlxWKjBb-5-sOgw=.53a4b31e-1370-4950-82ea-954e0089e499@github.com>

On Wed, 8 Oct 2025 05:28:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rethink safepoint sync logging
>
> src/hotspot/share/runtime/safepoint.cpp line 348:
> 
>> 346:   _nof_threads_hit_polling_page = 0;
>> 347: 
>> 348:   log_debug(safepoint)("Safepoint synchronization initiated using %s wait barrier. (%d threads)", _wait_barrier->description(), nof_threads);
> 
> I don't see the point in moving this partially into `SafepointTracing::begin` but losing the information as to how many threads are being handled.

I went back and forth on this myself yesterday, but settled on this variant, because:

 1. Completeness: the older placing was IMO too late. I think the logging statement is currently there to capture the total number of threads, which you can only reliably get after taking a `Threads_lock`. But in doing so we miss the time we took to take a `Threads_lock` itself, not to mention `Universe::safepoint_synchronize_begin()` that coordinates with GC. Both are parts of safepoint sync, IMO.
 2. Usefulness: the number of total threads makes little sense for arming, since it is likely the majority of non-runnable threads would never actually reach the wait barrier. The number of threads, including the number of runnable threads we actually handled, is printed in `SafepointTracing::end()`. The minor problem with that: in debugging, vm op might have crashed before reaching the end of safepoint.
 3. Consistency: all logging statements of the same "level" are in `SafepointTracing`. 
  
So, to make this even more complete, I added another tracing log right before arming, and before after the initial filtering, where we know exactly how many runnable and total threads we are dealing with.

It would be like this:


[5.500s][debug][safepoint] Safepoint synchronization begins 
[5.500s][trace][safepoint] Arming futex wait barrier
[5.500s][trace][safepoint] Setting thread local yield flag for threads
[5.500s][trace][safepoint] 26 total threads, waiting for 12 threads to block
[5.500s][trace][safepoint] Checking thread status
[5.500s][trace][safepoint] Thread 0x000073cc5c47f670 is still running
...
[5.500s][trace][safepoint] Thread 0x000073cc5c494e90 is still running
[5.500s][trace][safepoint] Waiting for 12 threads to block
...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412870376

From jsjolen at openjdk.org  Wed Oct  8 07:43:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 8 Oct 2025 07:43:01 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/aed82e9c..bb3a014d

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From rrich at openjdk.org  Wed Oct  8 07:52:10 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 8 Oct 2025 07:52:10 GMT
Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers
 [v5]
In-Reply-To: <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
 <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
Message-ID: <Fq7_KQWC-xCZcvr56EXyk9mKZ0BEKotr3E-EpDinRtE=.59a17728-8f4f-4437-9208-86c487dea620@github.com>

On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage.
>
> Martin Doerr 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 remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Move nmethod entry barrier code up in the signal handler.
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - 8334247: [PPC64] Consider trap based nmethod entry barriers

Changes look good to me.
Cheers, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24135#pullrequestreview-3313447297

From egahlin at openjdk.org  Wed Oct  8 07:53:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Oct 2025 07:53:13 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <dXSTy7hJzjv6dFvbWn4SXPv-ubWDZDphvcRttF7m34s=.2f070fec-99a8-4c4f-a1bf-8f40c23539b6@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
 <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>
 <dqI2FH-UmyiZUAH9hFDg3Jkomf_mw2kC8B-foyVcgwI=.e471efee-2c83-4ebc-a343-7df70229ad18@github.com>
 <dXSTy7hJzjv6dFvbWn4SXPv-ubWDZDphvcRttF7m34s=.2f070fec-99a8-4c4f-a1bf-8f40c23539b6@github.com>
Message-ID: <z-DOT9hI6IX5Wac1-PSf2HvTSYd15P0JO06z4kk_y3E=.12f80743-04fd-4742-939b-e702aedcea20@github.com>

On Wed, 8 Oct 2025 06:50:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> BTW I assume that "hwThreads" is the number of logical processors - right?
>> 
>> Yes
>
>> Perhaps better stated on the cores field:
> 
> Thanks for your comment! I added that sentence to `description` attribute in `Field` element.
> After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip)
> 
> 
> $ jfr metadata --events jdk.CPUInformation /tmp/test.jfr
> @Name("jdk.CPUInformation")
> @Category({"Operating System", "Processor"})
> @Label("CPU Information")
> @Description("Characteristics and descriptions of the processor(s) the JVM is running on")
> class CPUInformation extends jdk.jfr.Event {
>   @Label("Start Time")
>   @Timestamp("TICKS")
>   long startTime;
> 
>   @Label("Type")
>   String cpu;
> 
>   @Label("Description")
>   String description;
> 
>   @Unsigned
>   @Label("Sockets")
>   int sockets;
> 
>   @Unsigned
>   @Label("Cores")
>   @Description("Approximation on a hybrid CPU")
>   int cores;
> 
>   @Unsigned
>   @Label("Hardware Threads")
>   int hwThreads;
> }

Metadata looks good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412915309

From shade at openjdk.org  Wed Oct  8 07:57:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 07:57:21 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v5]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <_WiiM55zCjaRP4gs5c8S20Pwrotj0YNY6P7adF2XxyE=.fa5243d3-1432-4975-b6ab-bfb2fcdeb044@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  A bit more verbose

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/5f4a13a4..c7b06625

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

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

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

From shade at openjdk.org  Wed Oct  8 08:02:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 08:02:13 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v5]
In-Reply-To: <NZe971yV2E5KK5HmmoNziCeu-Jp_KlxWKjBb-5-sOgw=.53a4b31e-1370-4950-82ea-954e0089e499@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
 <NZe971yV2E5KK5HmmoNziCeu-Jp_KlxWKjBb-5-sOgw=.53a4b31e-1370-4950-82ea-954e0089e499@github.com>
Message-ID: <WddYKKHX-1pmslNHp3tb7ZGWYqdRlDLzXqCRTw3ZxFE=.42417519-a5a3-4dea-a123-6cee2abc9a98@github.com>

On Wed, 8 Oct 2025 07:31:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 348:
>> 
>>> 346:   _nof_threads_hit_polling_page = 0;
>>> 347: 
>>> 348:   log_debug(safepoint)("Safepoint synchronization initiated using %s wait barrier. (%d threads)", _wait_barrier->description(), nof_threads);
>> 
>> I don't see the point in moving this partially into `SafepointTracing::begin` but losing the information as to how many threads are being handled.
>
> I went back and forth on this myself yesterday, but settled on this variant, because:
> 
>  1. Completeness: the older placing was IMO too late. I think the logging statement is currently there to capture the total number of threads, which you can only reliably get after taking a `Threads_lock`. But in doing so we miss the time we took to take a `Threads_lock` itself, not to mention `Universe::safepoint_synchronize_begin()` that coordinates with GC. Both are parts of safepoint sync, IMO.
>  2. Usefulness: the number of total threads makes little sense for arming, since it is likely the majority of non-runnable threads would never actually reach the wait barrier. The number of threads, including the number of runnable threads we actually handled, is printed in `SafepointTracing::end()`. The minor problem with that: in debugging, vm op might have crashed before reaching the end of safepoint.
>  3. Consistency: all logging statements of the same "level" are in `SafepointTracing`. 
>   
> So, to make this even more complete, I added another tracing log right before arming, and before after the initial filtering, where we know exactly how many runnable and total threads we are dealing with.
> 
> It would be like this:
> 
> 
> [5448421640ns] Safepoint synchronization begins
> [5448472227ns] Suspending GC threads 
> [5448489199ns] Blocking threads from starting/exiting
> [5448504629ns] Arming futex wait barrier
> [5448520860ns] Setting thread local yield flag for threads
> [5448541169ns] 26 total threads, waiting for 15 threads to block
> [5448557199ns] Checking thread status
> ...
> [5448597837ns] Waiting for 15 threads to block 
> ...

Ohhhh, the one thing that is now obvious from these logs is that we take a relatively large hit on suspending GC threads _before_ we even start blocking the Java threads. We should actually announce the safepoint and then suspend GC threads, so that we can make Java threads and GC threads suspend concurrently. Filed: [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412942016

From dholmes at openjdk.org  Wed Oct  8 08:05:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Oct 2025 08:05:28 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v7]
In-Reply-To: <kXGecXvBw8ECiEuQx83C4RZVR6UvjkCvPatiK69Yj58=.1a532532-1e84-4934-898c-d935dba1f56f@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <kXGecXvBw8ECiEuQx83C4RZVR6UvjkCvPatiK69Yj58=.1a532532-1e84-4934-898c-d935dba1f56f@github.com>
Message-ID: <vm5ps6o3oVoH885Q9WUxRwN5B3z9CVZNbM-L_V0iCM8=.94f41baa-6288-44ca-86f1-75f19d25a91e@github.com>

On Wed, 8 Oct 2025 06:53:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add description attribute to Field

If @egahlin is happy with the JFR side then nothing further from me.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27080#pullrequestreview-3313499645

From jbechberger at openjdk.org  Wed Oct  8 08:07:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 8 Oct 2025 08:07:00 GMT
Subject: Integrated: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <9lF5MKUxf3lTZV9yUPqQx47DRn6zZCEnWSGy6Ld2uyo=.1d778c1e-44ae-405a-9395-d4cc93edb072@github.com>

On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

This pull request has now been integrated.

Changeset: d27649fe
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d27649fe22a5bed9db72ac6c2595ac91f1fa28f8
Stats:     138 lines in 6 files changed: 47 ins; 46 del; 45 mod

8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing

Reviewed-by: dholmes, apangin

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

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

From alanb at openjdk.org  Wed Oct  8 08:08:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Oct 2025 08:08:05 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <VuK3AaZ6zIZmNgnGWk0ydc9wEazGvyHdfWiDVFeurHs=.514d7ab3-2811-4764-99a6-9ca95b20de1b@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
 <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
 <VuK3AaZ6zIZmNgnGWk0ydc9wEazGvyHdfWiDVFeurHs=.514d7ab3-2811-4764-99a6-9ca95b20de1b@github.com>
Message-ID: <BcSiADOz3PuL2aGThKS0UTlFlTZjXwpzNpFyuztnB8k=.49fc6743-ef25-46ec-8432-903deed615a5@github.com>

On Tue, 7 Oct 2025 00:44:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.
> 
> @AlanBateman yes that is exactly what I am suggesting. Thanks

I discussed this with Ron. Mutating final fields from native code isn't core to this JEP.  A fatal error would be better but we are okay with it initially being a warning instead. So we'll update that section of the JEP, and today the addition to jniCheck to use ReportJNIWarning instead of ReportJNIFatalError.

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3380229466

From alanb at openjdk.org  Wed Oct  8 08:15:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Oct 2025 08:15:08 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - Add testUnreflectExpectingWarning
 - Merge branch 'master' into JDK-8353835
 - Add test for -Xlog:jni=debug
 - Merge branch 'master' into JDK-8353835
 - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=07
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From shade at openjdk.org  Wed Oct  8 08:16:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 08:16:53 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v5]
In-Reply-To: <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
Message-ID: <MHrZoyWiKnmNNKuufHj5w8EdCsBYASMVdKtN24UlxVI=.0af680e4-bd65-4409-91af-a3dcbe6ef384@github.com>

On Wed, 8 Oct 2025 05:32:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A bit more verbose
>
> src/hotspot/share/runtime/safepoint.cpp line 169:
> 
>> 167:     LogStream ls(lt);
>> 168:     cur_state->print_on(&ls);
>> 169:   }
> 
> Why is this not useful for debugging? I can understand you might not need it for your profiling but UL is primarily about debugging assistance.

I reasoned it is way too noisy to be useful even for debugging. 

Note this is `thread_not_running()` checker, which is called from two places in `SafepointSynchronize::synchronize_threads`: initial filtering and on-going checks for state changes. In well-behaved applications most of the threads are actually not running, blocked somewhere in idle thread pool. So prnting this from the initial filtering dumps info on potentially thousands of threads we do not care about 99.9% of the time.

I argued to myself that what we really care about are the threads that are _transiting_ from runnable to blocked. So the new `log_trace(safepoint)` statements are in caller code that uses this `thread_not_running()` checker, and is able to print exactly what they see. "thread is now blocked", for example.

I don't think there are useful bits in `TSS`, really. We can amend trace logs to pull some of that, if you want. Look what it prints now:


[792737314ns] Thread: 0x0000785db85bf4c0  [0x214944] State: _running _at_poll_safepoint 0
[792737594ns]    JavaThread state: _thread_in_Java
[792738025ns] Thread: 0x0000785db85c08e0  [0x214945] State: _running _at_poll_safepoint 1
[792738246ns]    JavaThread state: _thread_in_vm

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2412981865

From aph at openjdk.org  Wed Oct  8 08:24:25 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 8 Oct 2025 08:24:25 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <s1F_fxBsa8_eSfKddYNT7ocheRZUtvyUiqofPF26dGA=.525ebf4f-c970-4ba4-af37-52e9e0ac49e3@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
 <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>
 <j1NaPSjsjshdV2H4OonSfJyOCLj5NlHhV7NJOvmYkFc=.61a64d9a-fb53-4cce-a453-3c35fe1c6e6c@github.com>
 <s1F_fxBsa8_eSfKddYNT7ocheRZUtvyUiqofPF26dGA=.525ebf4f-c970-4ba4-af37-52e9e0ac49e3@github.com>
Message-ID: <rPopQ-xO5_n9S-KZx7QjPfY9RfSAW3fjvn3rjZ5W8x4=.79653c45-0496-472b-ac39-802ce2234e13@github.com>

On Tue, 7 Oct 2025 17:09:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> There are some rules about not calling the Standard C++ libraries in the Guidelines, but given that this one only prevents the compiler from moving things around and does not generate any code, I don't think that really applies. More legalisticaily-minded people might disagree, but I prefer portable code.
>
> That does require including `<atomic>`, which seems not ideal in globalDefinitions. Additionally `<atomic>` will likely eventually include `<stdatomic.h>` which defines `memory_order` as well. So I think we will have to live with what is currently here.

I just looked, and all of the fields in `JavaFrameAnchor` are `volatile`, so we don't need a compiler barrier on the compilers we use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2413005929

From azafari at openjdk.org  Wed Oct  8 08:32:34 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 8 Oct 2025 08:32:34 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <jsShxguBAG7oDcQgEi4aXSTuVtsg2qtegr96pDw4NRg=.e16de8c5-9ab1-445b-b44b-acf948ce6318@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

Dear @dholmes-ora, other reviewers want to receive more comments here. Would you please step in. TIA

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3380352929

From shade at openjdk.org  Wed Oct  8 08:36:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 08:36:33 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v6]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <JGk5JkT9o5-ac5irH7lhcZPqd1KmEYdjYTkzeq8thPM=.d0aafe71-1ae6-45a0-afd7-f7fd20bec482@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Put polling exception tracing back with minor reformat
 - Touchups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/c7b06625..945d612a

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

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27673/head:pull/27673

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

From shade at openjdk.org  Wed Oct  8 08:36:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 08:36:35 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v6]
In-Reply-To: <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
Message-ID: <yD1Zh4u7vJ5G-kh50WKXMx9dcqz1SDeoj3OeG5NTsGs=.e342c8b2-f5fb-4c77-9981-863783b27feb@github.com>

On Wed, 8 Oct 2025 05:44:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Put polling exception tracing back with minor reformat
>>  - Touchups
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 683:
> 
>> 681:                        INTPTR_FORMAT ", stub =" INTPTR_FORMAT,
>> 682:                        at_poll_return ? "return" : "loop",
>> 683:                        (intptr_t)pc, (intptr_t)stub);
> 
> Again this seems useful for debugging.

Yes, that makes sense. I initially swatted it away as noise, but it is also a useful debugging/profiling breadcrumb. I put it back, but polished the message a bit, so it fits the whole logging more appropriately. Like this:


[762208335ns] Waiting for 10 threads to block
[762218525ns] Polling page exception: thread = 0x000076b7e458a400, pc = 0x000076b7d3d47167 (loop), stub = 0x000076b7d37851e0
[762220869ns] Polling page exception: thread = 0x000076b7e45810b0, pc = 0x000076b7d3d46de9 (loop), stub = 0x000076b7d37851e0
[762220969ns] Polling page exception: thread = 0x000076b7e4587470, pc = 0x000076b7d3d46de9 (loop), stub = 0x000076b7d37851e0
[762221240ns] Polling page exception: thread = 0x000076b7e45860c0, pc = 0x000076b7d3d46de9 (loop), stub = 0x000076b7d37851e0
[762229325ns] Blocking thread 0x000076b7e458a400
[762229466ns] Blocking thread 0x000076b7e45860c0
[762230628ns] Polling page exception: thread = 0x000076b7e458b8d0, pc = 0x000076b7d3d47167 (loop), stub = 0x000076b7d37851e0
[762220859ns] Polling page exception: thread = 0x000076b7e4584d20, pc = 0x000076b7d3d46de9 (loop), stub = 0x000076b7d37851e0
[762232441ns] Polling page exception: thread = 0x000076b7e457fe30, pc = 0x000076b7d3d46de9 (loop), stub = 0x000076b7d37851e0
[762233403ns] Blocking thread 0x000076b7e45810b0
[762236649ns] Blocking thread 0x000076b7e458b8d0
[762237561ns] Blocking thread 0x000076b7e4587470

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2413042577

From lkorinth at openjdk.org  Wed Oct  8 09:03:41 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 09:03:41 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
Message-ID: <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>

On Tue, 7 Oct 2025 09:34:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ram_limit_set to has_ram_limit

src/hotspot/share/utilities/globalDefinitions.hpp line 1112:

> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
> 1111: }
> 1112: 

Maybe something more generic like this:

// return the value of B clamped by the numeric limits of S, casted to S
template<class S, class B>
S clamp_into_from(B value) {
  static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
  static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
  B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
  return static_cast<S>(v);
}

and place it after clamp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413130935

From dbriemann at openjdk.org  Wed Oct  8 09:18:43 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 8 Oct 2025 09:18:43 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc
Message-ID: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>

Also refactor so that linux and aix use the same code for ppc.

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

Commit messages:
 - minor fixes
 - fix copyright headers
 - 8307495: Specialize atomic bitset functions for aix-ppc

Changes: https://git.openjdk.org/jdk/pull/27650/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307495
  Stats: 1536 lines in 6 files changed: 665 ins; 854 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27650/head:pull/27650

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

From lkorinth at openjdk.org  Wed Oct  8 09:49:29 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 09:49:29 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
 <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
Message-ID: <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>

On Wed, 8 Oct 2025 09:00:39 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename ram_limit_set to has_ram_limit
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 1112:
> 
>> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
>> 1111: }
>> 1112: 
> 
> Maybe something more generic like this:
> 
> // return the value of B clamped by the numeric limits of S, casted to S
> template<class S, class B>
> S clamp_into_from(B value) {
>   static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
>   static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
>   B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
>   return static_cast<S>(v);
> }
> 
> and place it after clamp?

I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413258617

From ysuenaga at openjdk.org  Wed Oct  8 09:50:27 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 8 Oct 2025 09:50:27 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v5]
In-Reply-To: <z-DOT9hI6IX5Wac1-PSf2HvTSYd15P0JO06z4kk_y3E=.12f80743-04fd-4742-939b-e702aedcea20@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <fHMTdDrysTpUz4GfQVAY0vQ8Vjhg6z-Xaq_RNlvgXVk=.d2599bc3-52bd-4ff9-9707-e83ffbd58d9c@github.com>
 <J_bkv5gprLK3EqxeqCshE08ujc0q9ckoJZFe2ZN7xn8=.3cfb7b87-873f-4a7c-b9c0-fdc572cc67ac@github.com>
 <dqI2FH-UmyiZUAH9hFDg3Jkomf_mw2kC8B-foyVcgwI=.e471efee-2c83-4ebc-a343-7df70229ad18@github.com>
 <dXSTy7hJzjv6dFvbWn4SXPv-ubWDZDphvcRttF7m34s=.2f070fec-99a8-4c4f-a1bf-8f40c23539b6@github.com>
 <z-DOT9hI6IX5Wac1-PSf2HvTSYd15P0JO06z4kk_y3E=.12f80743-04fd-4742-939b-e702aedcea20@github.com>
Message-ID: <Pv4_3Qf0N-nknd8PaK5UnVgG-SWy4DK35dlSmY2a-3k=.a84bdb16-f528-46d2-bbf3-407d59ad81a2@github.com>

On Wed, 8 Oct 2025 07:50:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> Perhaps better stated on the cores field:
>> 
>> Thanks for your comment! I added that sentence to `description` attribute in `Field` element.
>> After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip)
>> 
>> 
>> $ jfr metadata --events jdk.CPUInformation /tmp/test.jfr
>> @Name("jdk.CPUInformation")
>> @Category({"Operating System", "Processor"})
>> @Label("CPU Information")
>> @Description("Characteristics and descriptions of the processor(s) the JVM is running on")
>> class CPUInformation extends jdk.jfr.Event {
>>   @Label("Start Time")
>>   @Timestamp("TICKS")
>>   long startTime;
>> 
>>   @Label("Type")
>>   String cpu;
>> 
>>   @Label("Description")
>>   String description;
>> 
>>   @Unsigned
>>   @Label("Sockets")
>>   int sockets;
>> 
>>   @Unsigned
>>   @Label("Cores")
>>   @Description("Approximation on a hybrid CPU")
>>   int cores;
>> 
>>   @Unsigned
>>   @Label("Hardware Threads")
>>   int hwThreads;
>> }
>
> Metadata looks good

@egahlin Can you approve this PR? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2413260517

From jsikstro at openjdk.org  Wed Oct  8 09:57:38 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 09:57:38 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Make limit_by_size_t_max to a static function in arguments.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/c6e585e2..b46d124e

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

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

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

From jsikstro at openjdk.org  Wed Oct  8 09:57:39 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 09:57:39 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
 <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
 <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>
Message-ID: <w3K3h5-_C-l38fBsFOoP1eUgJ2Rg-lV-h8Y3_PnF69U=.fe62b273-e210-4890-ae8b-1ff1dbc033bc@github.com>

On Wed, 8 Oct 2025 09:47:02 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 1112:
>> 
>>> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
>>> 1111: }
>>> 1112: 
>> 
>> Maybe something more generic like this:
>> 
>> // return the value of B clamped by the numeric limits of S, casted to S
>> template<class S, class B>
>> S clamp_into_from(B value) {
>>   static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
>>   static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
>>   B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
>>   return static_cast<S>(v);
>> }
>> 
>> and place it after clamp?
>
> I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp.

I agree, let's make it local to arguments.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413274164

From mdoerr at openjdk.org  Wed Oct  8 10:38:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Oct 2025 10:38:20 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <bA-KW4vWgZ93IejqXM-KeOJ3E1uBcNGO2uQAYruFTZ4=.5e314dc1-09b8-40a4-a147-b0427b5dd32d@github.com>

On Mon, 6 Oct 2025 15:16:26 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Also refactor so that linux and aix use the same code for ppc.

Very nice! I really like this change!

Thanks for refactoring and using single inline assembler code for all PPC64 platforms!
That should also help the BSD port.

The merged atomicAccess_ppc looks good. You have removed Power7 code from AIX which was forgotten.
You have also added back the missing "simple guard" in `PlatformCmpxchg<1>` which got lost on linux. That may be helpful to avoid some performance issues.
I guess we should consider a backport, later.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 250:

> 248: 
> 249:   // Using 32 bit internally.
> 250:   unsigned int old_value, loaded_value;

`loaded_value` seems to be unused.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 414:

> 412:       "   and     %[result], %[old_value], %[bits]    \n"
> 413:       "   stwcx.  %[result], 0, %[dest]    \n"
> 414:       "   bne-    1b            \n"

Maybe use uniform indentation for the "\n" as for other atomics? (optional)

src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp line 27:

> 25: 
> 26: #ifndef OS_CPU_AIX_PPC_ATOMICACCESS_AIX_PPC_HPP
> 27: #define OS_CPU_AIX_PPC_ATOMICACCESS_AIX_PPC_HPP

Maybe remove these guards? The ones in the new file should be sufficient. (The same for the other files.)

src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp line 30:

> 28: 
> 29: // Included in atomicAccess.hpp header file.
> 30: 

Maybe add comment like "We use inline assembler which is shared for several PPC64 platforms."

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

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3314146500
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413378586
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413384929
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413392885
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413396328

From dbriemann at openjdk.org  Wed Oct  8 11:23:05 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 8 Oct 2025 11:23:05 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc
In-Reply-To: <bA-KW4vWgZ93IejqXM-KeOJ3E1uBcNGO2uQAYruFTZ4=.5e314dc1-09b8-40a4-a147-b0427b5dd32d@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <bA-KW4vWgZ93IejqXM-KeOJ3E1uBcNGO2uQAYruFTZ4=.5e314dc1-09b8-40a4-a147-b0427b5dd32d@github.com>
Message-ID: <rYmUTSK6U1bbFHXQ788smuJIV-z27F7dVrtXAY375EI=.42e3d81f-76dc-46b3-9f67-8f709160d5e4@github.com>

On Wed, 8 Oct 2025 10:28:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Also refactor so that linux and aix use the same code for ppc.
>
> src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp line 27:
> 
>> 25: 
>> 26: #ifndef OS_CPU_AIX_PPC_ATOMICACCESS_AIX_PPC_HPP
>> 27: #define OS_CPU_AIX_PPC_ATOMICACCESS_AIX_PPC_HPP
> 
> Maybe remove these guards? The ones in the new file should be sufficient. (The same for the other files.)

As long as no one is adding platform_cpu specific functions removing should be fine.

> src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp line 30:
> 
>> 28: 
>> 29: // Included in atomicAccess.hpp header file.
>> 30: 
> 
> Maybe add comment like "We use inline assembler which is shared for several PPC64 platforms."

Agree.. good time to update the comment and make it more precise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413522665
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2413523675

From ayang at openjdk.org  Wed Oct  8 11:25:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:25:05 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6]
In-Reply-To: <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@github.com>
Message-ID: <-jc1OS_5p7LgxFY_YEeH_mHtBjGCFVrjiZ8uza8sWL8=.a6c5b1c8-79ed-4c6e-8ba2-03e18ee3dc77@github.com>

On Wed, 8 Oct 2025 09:57:38 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make limit_by_size_t_max to a static function in arguments.cpp

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 1510:

> 1508: static const size_t DefaultHeapBaseMinAddress = HeapBaseMinAddress;
> 1509: 
> 1510: static size_t limit_by_size_t_max(uint64_t value) {

I wonder if `clamp_by_size_t_max` sounds better. Up to you.

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

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314359536
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413529193

From jsikstro at openjdk.org  Wed Oct  8 11:32:44 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 11:32:44 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v7]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename limit_by_size_t_max to clamp_by_size_t_max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/b46d124e..47163464

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

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

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

From dbriemann at openjdk.org  Wed Oct  8 11:37:49 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 8 Oct 2025 11:37:49 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v2]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <Xq2fibC7xBBWPnBZ-hahYxTTkLEeF0ZefENDEzSpBOY=.e7fef905-c8c6-4ad2-bbd4-6ec2ead89f72@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with two additional commits since the last revision:

 - remove unneeded header guards
 - remove unused var, beautify code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/e91818ad..abf0a4f0

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

  Stats: 66 lines in 5 files changed: 0 ins; 25 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/27650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27650/head:pull/27650

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

From lkorinth at openjdk.org  Wed Oct  8 11:45:06 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 11:45:06 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v7]
In-Reply-To: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
Message-ID: <vzI8qkPsy51s_tH6Nd23IHgETBBFPUfYngsFZiY579I=.2a7be23b-a580-4fbe-8910-e02e09ec924a@github.com>

On Wed, 8 Oct 2025 11:32:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename limit_by_size_t_max to clamp_by_size_t_max

Looks very good to me.

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314426587

From jwaters at openjdk.org  Wed Oct  8 12:00:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Oct 2025 12:00:13 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_info>`, along with updates to use them.

Did you mean type_traits?

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3381173911

From cnorrbin at openjdk.org  Wed Oct  8 12:04:18 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 8 Oct 2025 12:04:18 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <BHFyRbkCc2gOMjej5z_0K0IyVqW9WNMWgChavqxckaM=.24aa671d-62eb-499e-a348-d0ac356b41ab@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <LN65GTKbNwzDKvxBGkpbDxEdtQI-H_r-8rUnZc3agw8=.4b9aae89-9f2f-4e65-86ab-a4cf5b3b517b@github.com>
 <SnfomxaUjXZwS-BUEA44E7_1x6Q2TFPFDAWxXgFGST4=.06e8964b-34ce-41ed-b492-02f7aaeae8e0@github.com>
 <KTQ9ZY-H51_DB9fg8yi1nFrueNF7GM3pEUeqHVeWJTQ=.acb5bd3c-0e85-4aac-9e94-5f4b7b4f7bad@github.com>
 <R2la5XahUigPOTo6MHY5r17IOwq15a_WQw1Dciy9kw4=.b76d5d30-89c5-47c6-952a-1ca0a3023688@github.com>
 <BHFyRbkCc2gOMjej5z_0K0IyVqW9WNMWgChavqxckaM=.24aa671d-62eb-499e-a348-d0ac356b41ab@github.com>
Message-ID: <Ys7lTm6PXdgFI4-setKvJ0kMDX0DVDvJCGE7zeuJjbA=.4a276f04-2878-431e-8e6b-31a948e9b266@github.com>

On Wed, 8 Oct 2025 04:53:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't like the naming "machine_" here - yes naming is hard and subjective - these "machine" API's are reporting whatever the operating system is exposing to the process.

I'm open to changing the naming to make it more clear which value is accessed. Could maybe prefix them with `os_` instead. That could however look a bit weird with a double `os::os_`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3381182076

From jwaters at openjdk.org  Wed Oct  8 12:06:45 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Oct 2025 12:06:45 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters 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 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3b8c255b...9d05cb8e

Paging with the mailing list bridge to restart discussion, which I need in order to be able to continue working on this

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3381196846

From duke at openjdk.org  Wed Oct  8 12:16:32 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 8 Oct 2025 12:16:32 GMT
Subject: Integrated: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3
 cores
In-Reply-To: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
References: <mycQSWk-zkawP6DJpv9P1iWsGCFwWO-CbEN66GXA3Lg=.6720e844-265b-4b95-bd89-29b3e65d2a2c@github.com>
Message-ID: <IIdX-Ohe9l788CPEr6Y1obil1enNHDtUGnsPM5Z-tfE=.8aefac6b-308e-41a6-be54-26b524428f12@github.com>

On Fri, 8 Aug 2025 14:50:13 GMT, Ruben <duke at openjdk.org> wrote:

> For Neoverse N1, N2, V1, and V2, the following JVM flags are set:
>  - UseSIMDForMemoryOps=true
>  - OnSpinWaitInst=isb
>  - OnSpinWaitInstCount=1
>  - AlwaysMergeDMB=false
> 
> Additionally, for Neoverse V1 and V2 only, these flags are set:
>  - UseCryptoPmullForCRC32=true
>  - CodeEntryAlignment=32
> 
> Set the same flags for Neoverse N3 and V3, respectively.

This pull request has now been integrated.

Changeset: 23fcbb0b
Author:    Ruben Ayrapetyan <ruben.ayrapetyan at arm.com>
Committer: Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23fcbb0badbef6d22f63ca6c5b26b0693002592c
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores

Reviewed-by: eastigeevich, aph

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

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

From jcking at openjdk.org  Wed Oct  8 12:31:39 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Oct 2025 12:31:39 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v6]
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <HDev0Ot_UAnPpufdHocg7kbU9uSFHzjQsYmmT3bZCRY=.303df056-8858-425f-82c5-5c3c8b5fc5af@github.com>

> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.

Justin King has updated the pull request incrementally with eight additional commits since the last revision:

 - JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers
   
   Signed-off-by: Justin King <jcking at google.com>
 - Revert "JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers"
   
   This reverts commit 462c63e588ebf0dcd478b5347684ccb6c2438686.
 - Revert "Update comments"
   
   This reverts commit a0058eb4405a9afb0db80d9838e0657f725c9a15.
 - Revert "Rename ACGT -> AGCT"
   
   This reverts commit a141449425a72a4095b9740e28c758cb295c9352.
 - Revert "Remove barriers and just fix program order for sp store in MacroAssembler"
   
   This reverts commit 253417f98e7d5680a3ad6f8561b198fc0ae3b141.
 - Revert "Add comment to JavaFrameAnchor regarding no need for fencing"
   
   This reverts commit 016769dfe4272d7cb37d46524f32e9f7a4887b11.
 - Revert "Move compiler_barrier() to globalDefinitions.hpp and use it"
   
   This reverts commit 6dd80d947a343ad6c45d1738614643f7013afcbc.
 - Revert "Add back header inclusion"
   
   This reverts commit 7dc3313c9fd6a4f2739c39dc4d9d075103894aa9.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27645/files
  - new: https://git.openjdk.org/jdk/pull/27645/files/7dc3313c..b0f22bab

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

  Stats: 59 lines in 8 files changed: 17 ins; 34 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27645/head:pull/27645

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

From jcking at openjdk.org  Wed Oct  8 12:31:40 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Oct 2025 12:31:40 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v4]
In-Reply-To: <Vn8G1oqk9ic0cmonQP2FjEp-ilM1iQlT3-y8tAjpC7A=.200da6a4-7ad5-4675-9e70-48c713d455ee@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <WviU_eGj9satCbfoJTKxrkcPQ9ahFKyu7jfqPoCFfnk=.ffdb604b-5bca-4ac2-b2f7-8b84ec6b35a1@github.com>
 <yGhv1EizxO7jJMR7WYdWBu-pLVB_9KKUFQiM-l9hkAc=.ca9d6e21-327d-4aa3-8815-4f4dbcbebb53@github.com>
 <XTkmae7BFlwck7FmgVC4xu-af9BWuzBMCvjB-KB1QUY=.95629e5e-6657-41d4-ad61-6ed3f3c538dd@github.com>
 <5zp2DW3Dxpfi1AkzodWNMS1hq_dgejRK2IztXht7rN0=.240f8764-5dbc-4f62-801f-628220ec4e4f@github.com>
 <Vn8G1oqk9ic0cmonQP2FjEp-ilM1iQlT3-y8tAjpC7A=.200da6a4-7ad5-4675-9e70-48c713d455ee@github.com>
Message-ID: <cJ4VCIeM59V3efHGAvpA7etUBBj7XeeufCSYYicQHc8=.98fb91a9-b43e-4c15-a76c-1fd2a57533ff@github.com>

On Tue, 7 Oct 2025 21:03:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> > I don't think copy() is ever called. Can we remove it?
>>> 
>>> Sure.
>> 
>> Ah no. `copy()` is called after the anchor is constructed.
>
> I missed that because I had commented out the JavaFrameAnchor(JavaFrameAnchor *src) ctor, thinking it was the only use, and it still builds.
> 
> I tried to research what this comment is about:
>     // Hack Alert: Temporary bugfix for 4717480/4721647
> and my conclusion is that it seems to be left over from an earlier safepoint implementation where the VM thread could look at the anchor of other threads while they were still running.  I don't think we do that anymore.

Deleted the now defunct comment, I believe you are correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2413691928

From jcking at openjdk.org  Wed Oct  8 12:31:41 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Oct 2025 12:31:41 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v5]
In-Reply-To: <rPopQ-xO5_n9S-KZx7QjPfY9RfSAW3fjvn3rjZ5W8x4=.79653c45-0496-472b-ac39-802ce2234e13@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <bR5LibGmSHL7RmatVfIUj1mhUmvcYdvGJvfGzoQFeEg=.594d098e-dfe5-420c-966f-a72cca460e23@github.com>
 <QBKFNCADS2j3lP9pm5fsEdyLF-xZ30vr7R7Rd29Kv7E=.b36c166f-28c3-4c4c-9abb-f7dbaeebe937@github.com>
 <j1NaPSjsjshdV2H4OonSfJyOCLj5NlHhV7NJOvmYkFc=.61a64d9a-fb53-4cce-a453-3c35fe1c6e6c@github.com>
 <s1F_fxBsa8_eSfKddYNT7ocheRZUtvyUiqofPF26dGA=.525ebf4f-c970-4ba4-af37-52e9e0ac49e3@github.com>
 <rPopQ-xO5_n9S-KZx7QjPfY9RfSAW3fjvn3rjZ5W8x4=.79653c45-0496-472b-ac39-802ce2234e13@github.com>
Message-ID: <p3v4a3MCXZ7KMDsOW7DbQa1-zblUZWZ7Hf-dvNBvEMs=.1b21c93b-ad9d-4c02-843f-d888ad740c33@github.com>

On Wed, 8 Oct 2025 08:21:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> That does require including `<atomic>`, which seems not ideal in globalDefinitions. Additionally `<atomic>` will likely eventually include `<stdatomic.h>` which defines `memory_order` as well. So I think we will have to live with what is currently here.
>
> I just looked, and all of the fields in `JavaFrameAnchor` are `volatile`, so we don't need a compiler barrier on the compilers we use.

Reverted and deleted the now defunct comment pointed out by @dean-long . Only left fixing the store order in MacroAssembler and the comment in JavaFrameAnchor explaining why no hardware barriers are necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27645#discussion_r2413691111

From dbriemann at openjdk.org  Wed Oct  8 12:41:44 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 8 Oct 2025 12:41:44 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v3]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <jsdvamH0yoMRHg5tt2mAakMbnxE93mJhw-i12PrlHQU=.762786da-1949-4ece-a57e-eb50acb5a4a0@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  more formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/abf0a4f0..6d5bb4e2

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

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

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

From dbriemann at openjdk.org  Wed Oct  8 12:55:03 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 8 Oct 2025 12:55:03 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v4]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <tL-Atm3bfG_y0MjYvR_Ov-j7SOcEL2HjU_mKUBmkPF4=.903cfcc4-a167-4a82-ab30-633dc26f37b2@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  replace zero register by immediate 0 value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/6d5bb4e2..a1252228

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

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

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

From kbarrett at openjdk.org  Wed Oct  8 13:12:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:12:26 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>
Message-ID: <xWgQdxXIbiOaMamOA3VrUSOQrboSIXCvA6fq29bW0yk=.8772d6bf-8649-42be-9a3b-2ba185c67d60@github.com>

On Wed, 8 Oct 2025 11:56:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> > `<type_info>`, along with updates to use them.
> 
> Did you mean type_traits?

Oops! Yes. Fixing description...

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3381469837

From ayang at openjdk.org  Wed Oct  8 13:14:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 13:14:35 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v7]
In-Reply-To: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
Message-ID: <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>

On Wed, 8 Oct 2025 11:32:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
>> 
>> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
>> 
>> Testing:
>> * Oracle's tier1-8 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename limit_by_size_t_max to clamp_by_size_t_max

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314754064

From adinn at openjdk.org  Wed Oct  8 13:15:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 8 Oct 2025 13:15:37 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v3]
In-Reply-To: <JCMZgFjLeTJHTPNZ8GohiE569q8GO49B297a6EAJi8s=.6b023a94-a61c-4952-8bf5-146968d3e608@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <JCMZgFjLeTJHTPNZ8GohiE569q8GO49B297a6EAJi8s=.6b023a94-a61c-4952-8bf5-146968d3e608@github.com>
Message-ID: <iBYamin3X-6WzwhkcNxqCGIdT-kVXntYAzq1N54SPUY=.0e1435ee-4c45-41eb-ab20-912924ffe544@github.com>

On Tue, 7 Oct 2025 19:05:09 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for s390
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

x86- and aarch64-specific changes look fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3381484807

From kbarrett at openjdk.org  Wed Oct  8 13:25:58 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:25:58 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
Message-ID: <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>

On Wed, 8 Oct 2025 07:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> src/hotspot/share/utilities/tuple.hpp line 2:
> 
>> 1: /*
>> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> So we have our own tuple ...

We have our own baby partial tuple. What's there is more like a heterogeneous
array with compile-time indexing. It's used for one thing, and provides just
enough functionality for that use. I'm not entirely convinced it's the right
tool for the job, though I haven't taken the time to work out alternatives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2413850653

From jsikstro at openjdk.org  Wed Oct  8 13:31:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 13:31:25 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v8]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <BuvaA-UpQQXmiDgKc7lhM6T5C4btYD6QLW7-L-Xw6NM=.7e1851db-60d6-4d9d-9bf2-855ae89867d9@github.com>

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
 - Rename limit_by_size_t_max to clamp_by_size_t_max
 - Make limit_by_size_t_max to a static function in arguments.cpp
 - Rename ram_limit_set to has_ram_limit
 - Revert MaxRAM default removals, defer to future enhancement
 - Namings and comment
 - 8367413: Refactor types in Arguments::set_heap_size()
 - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
 - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
   
   This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
 - Revert "size_t casts for 32-bit part of test_arguments.cpp"
   
   This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7

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

Changes: https://git.openjdk.org/jdk/pull/27224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=07
  Stats: 73 lines in 1 file changed: 18 ins; 6 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

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

From asmehra at openjdk.org  Wed Oct  8 13:44:25 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Oct 2025 13:44:25 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Add support for riscv
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/0ef8bddc..73bc815f

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

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

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

From asmehra at openjdk.org  Wed Oct  8 13:44:26 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Oct 2025 13:44:26 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <YX9K0p98JWJ-pIE96Ec0zdF3z2LRCxQ9CoaHMrySeAo=.c4ca9c30-ffcd-4622-9933-6434d17798b0@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
 <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
 <Iu-81c4fMv0IU9QUicQVlgfLGS7vhipRBmP-ABJpPjo=.41996e36-8481-4942-8627-a17d7d1eebbd@github.com>
 <YX9K0p98JWJ-pIE96Ec0zdF3z2LRCxQ9CoaHMrySeAo=.c4ca9c30-ffcd-4622-9933-6434d17798b0@github.com>
Message-ID: <iVNQwnKxdtkJAysME84lsXqwgkqbbChMvpE75EoDpcY=.4e722cf1-8c2a-4944-b31a-19675e610695@github.com>

On Wed, 8 Oct 2025 03:27:14 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> clinit_barrier implements a fast path check, so clinit_barrier_fast_path maybe a more accurate variant.
>> 
>> yes, `clinit_barrier_fast_path` is better.
>
> @ashu-mehra
> Hi, Thanks for the ping! And here is the riscv-specific changes:
> [27676-riscv.diff.txt](https://github.com/user-attachments/files/22758069/27676-riscv.diff.txt)
> `hotspot:tier1` and `hotspot_runtime` passed with fastdebug build on linux-riscv64.

@RealFYang thanks for the patch. I added it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3381597325

From asmehra at openjdk.org  Wed Oct  8 13:44:28 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Oct 2025 13:44:28 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v3]
In-Reply-To: <iBYamin3X-6WzwhkcNxqCGIdT-kVXntYAzq1N54SPUY=.0e1435ee-4c45-41eb-ab20-912924ffe544@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <JCMZgFjLeTJHTPNZ8GohiE569q8GO49B297a6EAJi8s=.6b023a94-a61c-4952-8bf5-146968d3e608@github.com>
 <iBYamin3X-6WzwhkcNxqCGIdT-kVXntYAzq1N54SPUY=.0e1435ee-4c45-41eb-ab20-912924ffe544@github.com>
Message-ID: <eEBNTmx1uJ1FZiT5b7TtEykslQOQLgM2A85MlNlTlYY=.693c7f7e-8482-48f8-bff6-bfc5892f8578@github.com>

On Wed, 8 Oct 2025 13:12:27 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> x86- and aarch64-specific changes look fine to me.

@adinn thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3381599374

From kbarrett at openjdk.org  Wed Oct  8 13:51:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:51:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
Message-ID: <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>

On Wed, 8 Oct 2025 07:04:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 1658:
> 
>> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
>> 1657: class is preferred to a tuple.
>> 1658: 
> 
> I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.
> 
> I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.

I have a different take on the distinction between forbidden and undecided. I
think of forbidden features as being those where there are good arguments
against. Whereas I think of undecided as perhaps having wishy washy arguments
in either direction, or even not seriously thought about. But good arguments
against can be overcome by better arguments in favor.

But I can see how someone else might take that distinction differently.

I also admit to being somewhat biased against tuple in particular. I've seen
a few pretty terrible uses... one was even my fault!

So okay, I'll recategorize tuple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2413928370

From aph at openjdk.org  Wed Oct  8 14:14:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 8 Oct 2025 14:14:30 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v6]
In-Reply-To: <HDev0Ot_UAnPpufdHocg7kbU9uSFHzjQsYmmT3bZCRY=.303df056-8858-425f-82c5-5c3c8b5fc5af@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <HDev0Ot_UAnPpufdHocg7kbU9uSFHzjQsYmmT3bZCRY=.303df056-8858-425f-82c5-5c3c8b5fc5af@github.com>
Message-ID: <BJWYpxhkm1BAhgcqqAL07hU7OkEMSXEK1C2EHFv2uss=.199ca052-f3fe-4324-82e7-51af126e2eee@github.com>

On Wed, 8 Oct 2025 12:31:39 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Revert "JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers"
>    
>    This reverts commit 462c63e588ebf0dcd478b5347684ccb6c2438686.
>  - Revert "Update comments"
>    
>    This reverts commit a0058eb4405a9afb0db80d9838e0657f725c9a15.
>  - Revert "Rename ACGT -> AGCT"
>    
>    This reverts commit a141449425a72a4095b9740e28c758cb295c9352.
>  - Revert "Remove barriers and just fix program order for sp store in MacroAssembler"
>    
>    This reverts commit 253417f98e7d5680a3ad6f8561b198fc0ae3b141.
>  - Revert "Add comment to JavaFrameAnchor regarding no need for fencing"
>    
>    This reverts commit 016769dfe4272d7cb37d46524f32e9f7a4887b11.
>  - Revert "Move compiler_barrier() to globalDefinitions.hpp and use it"
>    
>    This reverts commit 6dd80d947a343ad6c45d1738614643f7013afcbc.
>  - Revert "Add back header inclusion"
>    
>    This reverts commit 7dc3313c9fd6a4f2739c39dc4d9d075103894aa9.

Phew. Thank you for your patience.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27645#pullrequestreview-3315023695

From tschatzl at openjdk.org  Wed Oct  8 14:24:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 14:24:03 GMT
Subject: RFR: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
Message-ID: <7v5S0BxHxHnGL2FjldX-4eN-d7T-IFwRUBUNR0V3uy0=.0bf6fe46-9ba1-4e9c-b803-2e5447164461@github.com>

On Mon, 6 Oct 2025 12:20:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
> 
> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27644#pullrequestreview-3315062162

From fandreuzzi at openjdk.org  Wed Oct  8 14:24:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 14:24:04 GMT
Subject: Integrated: 8369178: G1: Use NMethodMarkingScope and
 ThreadsClaimTokenScope in G1RootProcessor
In-Reply-To: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
References: <IvI8Rfd05I2bY7873kBuu9WE1a5loR2YuICFBwl-nOk=.f38c15e5-b17b-4a13-b219-f1d00cf2605c@github.com>
Message-ID: <gcdV8tyaKiT40udUJokpKWjebAPQ-HCfGLcWlUiDPoU=.87c05e13-3d71-4403-b0bb-4279a3074430@github.com>

On Mon, 6 Oct 2025 12:20:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` and `MarkingNMethodClosure` in `G1RootProcessor ` to be more precise with what is needed and why.
> 
> - `MarkingNMethodClosure` is used in `G1FullGCMarkTask`, so we also need `NMethodMarkingScope`.
> - `active_workers ` is guaranteed to be `> 0`
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 927aa3f8
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/927aa3f8da34fb71b692661bebb89d20bfa85648
Stats:     53 lines in 8 files changed: 7 ins; 39 del; 7 mod

8369178: G1: Use NMethodMarkingScope and ThreadsClaimTokenScope in G1RootProcessor

Reviewed-by: ayang, tschatzl

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

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

From mdoerr at openjdk.org  Wed Oct  8 14:55:01 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Oct 2025 14:55:01 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
Message-ID: <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>

On Wed, 8 Oct 2025 13:44:25 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for riscv
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Thanks for the ping! PPC64 implementation:

diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
index 7431f77aeff..373dc24a62f 100644
--- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
+++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
@@ -2179,17 +2179,11 @@ void TemplateTable::_return(TosState state) {
 //   - Rscratch
 void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rcache, Register Rscratch) {
   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
+
   Label Lresolved, Ldone, L_clinit_barrier_slow;
   Register Rindex = Rscratch;
 
   Bytecodes::Code code = bytecode();
-  switch (code) {
-    case Bytecodes::_nofast_getfield: code = Bytecodes::_getfield; break;
-    case Bytecodes::_nofast_putfield: code = Bytecodes::_putfield; break;
-    default:
-      break;
-  }
-
   const int bytecode_offset = (byte_no == f1_byte) ? in_bytes(ResolvedMethodEntry::bytecode1_offset())
                                                    : in_bytes(ResolvedMethodEntry::bytecode2_offset());
   __ load_method_entry(Rcache, Rindex);
@@ -2201,10 +2195,9 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
 
   // Class initialization barrier slow path lands here as well.
   __ bind(L_clinit_barrier_slow);
-
   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
   __ li(R4_ARG2, code);
-  __ call_VM(noreg, entry, R4_ARG2, true);
+  __ call_VM(noreg, entry, R4_ARG2);
 
   // Update registers with resolved info.
   __ load_method_entry(Rcache, Rindex);
@@ -2226,12 +2219,10 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
   __ bind(Ldone);
 }
 
-void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
-                                            Register Rcache,
-                                            Register index) {
+void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcache, Register index) {
   assert_different_registers(Rcache, index);
 
-  Label resolved;
+  Label Lresolved, Ldone, L_clinit_barrier_slow;
 
   Bytecodes::Code code = bytecode();
   switch (code) {
@@ -2246,19 +2237,34 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
                                          : in_bytes(ResolvedFieldEntry::put_code_offset());
   __ lbz(R0, code_offset, Rcache);
   __ cmpwi(CR0, R0, (int)code); // have we resolved this bytecode?
-  __ beq(CR0, resolved);
+  __ beq(CR0, Lresolved);
 
   // resolve first time through
+  // Class initialization barrier slow path lands here as well.
+  __ bind(L_clinit_barrier_slow);
   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
-  __ li(R4_ARG2, (int)code);
+  __ li(R4_ARG2, code);
   __ call_VM(noreg, entry, R4_ARG2);
 
   // Update registers with resolved info
   __ load_field_entry(Rcache, index);
-  __ bind(resolved);
+  __ b(Ldone);
 
-  // Use acquire semantics for the bytecode (see ResolvedFieldEntry::fill_in()).
+  __ bind(Lresolved);
   __ isync(); // Order load wrt. succeeding loads.
+
+  if (VM_Version::supports_fast_class_init_checks() &&
+      (bytecode() == Bytecodes::_getstatic || bytecode() == Bytecodes::_putstatic)) {
+    const Register field_holder = R4_ARG2;
+
+    // InterpreterRuntime::resolve_get_put sets field_holder and finally release-stores put_code.
+    // We have seen the released put_code above and will read the corresponding field_holder and init_state
+    // (ordered by compare-branch-isync).
+    __ ld(field_holder, ResolvedFieldEntry::field_holder_offset(), Rcache);
+    __ clinit_barrier(field_holder, R16_thread, /* L_fast_path=*/nullptr , &L_clinit_barrier_slow);
+  }
+
+  __ bind(Ldone);
 }
 
 void TemplateTable::load_resolved_field_entry(Register obj,


I've made `resolve_cache_and_index_for_method` and `resolve_cache_and_index_for_field` more uniform and added a comment.

I've seen the discussion about the reexecution of the clinit barrier. My proposal avoids it by jumping over it. Is that better or at least less confusing? If nobody likes it and we want to have the platforms more similar, I can remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3381944631

From mdoerr at openjdk.org  Wed Oct  8 15:34:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Oct 2025 15:34:30 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v4]
In-Reply-To: <tL-Atm3bfG_y0MjYvR_Ov-j7SOcEL2HjU_mKUBmkPF4=.903cfcc4-a167-4a82-ab30-633dc26f37b2@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <tL-Atm3bfG_y0MjYvR_Ov-j7SOcEL2HjU_mKUBmkPF4=.903cfcc4-a167-4a82-ab30-633dc26f37b2@github.com>
Message-ID: <KksiDE9WyCBjbiEJ9n4f8v4_CUQ0vQ-xHzwNNWk5EUc=.148ec3a8-130e-42fd-a16b-489d9d84cc9f@github.com>

On Wed, 8 Oct 2025 12:55:03 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace zero register by immediate 0 value

Thanks for cleaning this up and making the inline assembler code more uniform. You could also replace the "%0", "%1", ... in `add_then_fetch` (optional). LGTM either way.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3315423924

From asmehra at openjdk.org  Wed Oct  8 15:39:50 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Oct 2025 15:39:50 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
Message-ID: <a70cfi4qdXz2ageu56LR-Yucx2xhlZCQLFOgGTuCQw8=.d6afcb25-0d9e-4c3f-a433-009a80fe72c8@github.com>

On Wed, 8 Oct 2025 14:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> My proposal avoids it by jumping over it. Is that better or at least less confusing? 

I think it makes sense. On returning from `resolve_from_cache` the class must have been initialized. So the fast path check can be skipped. Do you agree with this change? @iwanowww

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3382151682

From eastigeevich at openjdk.org  Wed Oct  8 15:58:28 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 8 Oct 2025 15:58:28 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
Message-ID: <evsWitfNkRYUJEa_kksJ9aqJ6rZecvEWOvCrpaTsUfw=.1b0262e8-a28e-461b-a1cf-d6fbba588084@github.com>

On Thu, 14 Aug 2025 15:41:36 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
>> 
>> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
>> 
>> This has passed tier1-3 and jcstress testing on AArch64.
>
> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>  - remove implementation-dependent logic from emit_shared_trampolines()
>  - cleanup: update copyright headers
>  - Make the value type of the dictionary a struct instead of Pair typedef
>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>  - Merge branch 'master'
>  - Address review comments from @theRealAph and @eastig
>    - use relocInfo::relocType instead of TrampolineCallKind
>    - move rtype from keys to values; reduce the footprint of the patch
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables
>  - 8359359: AArch64: share trampolines between static calls to the same method
>    
>    Modify the C2 compiler to share trampoline stubs between static calls
>    that resolve to the same callee method. Since the relocation target for
>    all static calls is initially set to the static call resolver stub, the
>    call's target alone cannot be used to distinguish between different
>    static method calls. Instead, trampoline stubs should be shared based
>    on the actual callee.
>    
>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>    trampolines among static calls. However, due to imprecise log analysis,
>    the test currently passes even when trampolines are not shared.
>    Additionally, comments within the test suggest ambiguity regarding
>    whether it was intended to assess trampoline sharing for static calls
>    or runtime calls. To address these issues and eliminate ambiguity, this
>    patch renames and updates the existing test. Furthermore, a new test is
>    introduced, using the existing one as a foundation, to accurately
>    evaluate trampoline sharing for both static and runtime calls.

src/hotspot/cpu/aarch64/codeBuffer_aarch64.cpp line 62:

> 60:     assert(cb->stubs()->remaining() >= MacroAssembler::max_trampoline_stub_size(), "pre-allocated trampolines");
> 61:     address dest = value.dest;
> 62:     LinkedListIterator<int> it(value.offsets.head());

It looks like we have missed an assert here when we were writing this code.
It's worth to add an assert: `assert(!value.offsets.is_empty(), "must have offsets of call sites")`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414339735

From eastigeevich at openjdk.org  Wed Oct  8 16:05:25 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 8 Oct 2025 16:05:25 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
Message-ID: <VAIlgrpsyng8nOzhUTaV0C9A_1arm39f6P5QQVzLHcw=.a8824b3e-bfe9-4679-b464-33780e5b0750@github.com>

On Thu, 14 Aug 2025 15:41:36 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
>> 
>> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
>> 
>> This has passed tier1-3 and jcstress testing on AArch64.
>
> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>  - remove implementation-dependent logic from emit_shared_trampolines()
>  - cleanup: update copyright headers
>  - Make the value type of the dictionary a struct instead of Pair typedef
>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>  - Merge branch 'master'
>  - Address review comments from @theRealAph and @eastig
>    - use relocInfo::relocType instead of TrampolineCallKind
>    - move rtype from keys to values; reduce the footprint of the patch
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables
>  - 8359359: AArch64: share trampolines between static calls to the same method
>    
>    Modify the C2 compiler to share trampoline stubs between static calls
>    that resolve to the same callee method. Since the relocation target for
>    all static calls is initially set to the static call resolver stub, the
>    call's target alone cannot be used to distinguish between different
>    static method calls. Instead, trampoline stubs should be shared based
>    on the actual callee.
>    
>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>    trampolines among static calls. However, due to imprecise log analysis,
>    the test currently passes even when trampolines are not shared.
>    Additionally, comments within the test suggest ambiguity regarding
>    whether it was intended to assess trampoline sharing for static calls
>    or runtime calls. To address these issues and eliminate ambiguity, this
>    patch renames and updates the existing test. Furthermore, a new test is
>    introduced, using the existing one as a foundation, to accurately
>    evaluate trampoline sharing for both static and runtime calls.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1337:

> 1335:   // - relocInfo::static_call_type
> 1336:   // - relocInfo::virtual_call_type
> 1337:   // Trampolines may be emitted immediately or deferred until stub finalization,

"... until stub" -> "until CodeBuffer"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414359813

From eastigeevich at openjdk.org  Wed Oct  8 16:48:48 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 8 Oct 2025 16:48:48 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
Message-ID: <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>

On Thu, 14 Aug 2025 15:41:36 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
>> 
>> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
>> 
>> This has passed tier1-3 and jcstress testing on AArch64.
>
> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>  - remove implementation-dependent logic from emit_shared_trampolines()
>  - cleanup: update copyright headers
>  - Make the value type of the dictionary a struct instead of Pair typedef
>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>  - Merge branch 'master'
>  - Address review comments from @theRealAph and @eastig
>    - use relocInfo::relocType instead of TrampolineCallKind
>    - move rtype from keys to values; reduce the footprint of the patch
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables
>  - 8359359: AArch64: share trampolines between static calls to the same method
>    
>    Modify the C2 compiler to share trampoline stubs between static calls
>    that resolve to the same callee method. Since the relocation target for
>    all static calls is initially set to the static call resolver stub, the
>    call's target alone cannot be used to distinguish between different
>    static method calls. Instead, trampoline stubs should be shared based
>    on the actual callee.
>    
>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>    trampolines among static calls. However, due to imprecise log analysis,
>    the test currently passes even when trampolines are not shared.
>    Additionally, comments within the test suggest ambiguity regarding
>    whether it was intended to assess trampoline sharing for static calls
>    or runtime calls. To address these issues and eliminate ambiguity, this
>    patch renames and updates the existing test. Furthermore, a new test is
>    introduced, using the existing one as a foundation, to accurately
>    evaluate trampoline sharing for both static and runtime calls.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 910:

> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");
> 909:         code()->share_trampoline_for(entry.target(), entry.target(), offset());
> 910:       } else if (entry.rspec().type() == relocInfo::static_call_type && callee != nullptr) {

I think we should require `callee` to non-null for `relocInfo::static_call_type`. Otherwise this will hide bugs, when it's been intended to share but forgotten to provide `callee`.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1339:

> 1337:   // Trampolines may be emitted immediately or deferred until stub finalization,
> 1338:   // enabling reuse across call sites to reduce code size.
> 1339:   // Runtime call trampolines are shared based on the entry value.

... on entry value -> ... on entry target

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414459526
PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414463714

From eastigeevich at openjdk.org  Wed Oct  8 16:48:49 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 8 Oct 2025 16:48:49 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
Message-ID: <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>

On Wed, 8 Oct 2025 16:44:25 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>>  - remove implementation-dependent logic from emit_shared_trampolines()
>>  - cleanup: update copyright headers
>>  - Make the value type of the dictionary a struct instead of Pair typedef
>>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>>  - Merge branch 'master'
>>  - Address review comments from @theRealAph and @eastig
>>    - use relocInfo::relocType instead of TrampolineCallKind
>>    - move rtype from keys to values; reduce the footprint of the patch
>>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>>  - Combine the two shared trampoline request hash tables
>>  - 8359359: AArch64: share trampolines between static calls to the same method
>>    
>>    Modify the C2 compiler to share trampoline stubs between static calls
>>    that resolve to the same callee method. Since the relocation target for
>>    all static calls is initially set to the static call resolver stub, the
>>    call's target alone cannot be used to distinguish between different
>>    static method calls. Instead, trampoline stubs should be shared based
>>    on the actual callee.
>>    
>>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>>    trampolines among static calls. However, due to imprecise log analysis,
>>    the test currently passes even when trampolines are not shared.
>>    Additionally, comments within the test suggest ambiguity regarding
>>    whether it was intended to assess trampoline sharing for static calls
>>    or runtime calls. To address these issues and eliminate ambiguity, this
>>    patch renames and updates the existing test. Furthermore, a new test is
>>    introduced, using the existing one as a foundation, to accurately
>>    evaluate trampoline sharing for both static and runtime calls.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 910:
> 
>> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");
>> 909:         code()->share_trampoline_for(entry.target(), entry.target(), offset());
>> 910:       } else if (entry.rspec().type() == relocInfo::static_call_type && callee != nullptr) {
> 
> I think we should require `callee` to non-null for `relocInfo::static_call_type`. Otherwise this will hide bugs, when it's been intended to share but forgotten to provide `callee`.

We need to convert the check `callee != nullptr` into an assert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414461373

From sgehwolf at openjdk.org  Wed Oct  8 16:56:39 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 Oct 2025 16:56:39 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
Message-ID: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>

Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.

Updating both tests fix the problems.

**Testing:**
- [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
- [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.

Thanks,
Severin

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

Commit messages:
 - 8369441: Two container tests fail after JDK-8292984

Changes: https://git.openjdk.org/jdk/pull/27699/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369441
  Stats: 21 lines in 2 files changed: 3 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27699/head:pull/27699

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

From sgehwolf at openjdk.org  Wed Oct  8 16:56:40 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 Oct 2025 16:56:40 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <-8mDhq_4MwPeX5jtrtHbBa2L0LMdXR_bTjwvDvy5Lqw=.65d30d84-6a63-4129-9390-75c1cc541d05@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

Passed: containers/cgroup/CgroupSubsystemFactory.java
Passed: containers/cgroup/TestContainerized.java
Passed: containers/docker/DockerBasicTest.java
Passed: containers/docker/ShareTmpDir.java
Passed: containers/docker/TestContainerInfo.java
Passed: containers/docker/TestCPUAwareness.java
Passed: containers/docker/TestCPUSets.java
Passed: containers/docker/TestJcmd.java
Passed: containers/docker/TestJcmdWithSideCar.java
Passed: containers/docker/TestJFREvents.java
Passed: containers/docker/TestJFRNetworkEvents.java
Passed: containers/docker/TestJFRWithJMX.java
Passed: containers/docker/TestLimitsUpdating.java
Passed: containers/docker/TestMemoryAwareness.java
Passed: containers/docker/TestMemoryWithCgroupV1.java
Passed: containers/docker/TestMemoryWithSubgroups.java
Passed: containers/docker/TestMisc.java
Passed: containers/docker/TestPids.java
Passed: containers/systemd/SystemdMemoryAwarenessTest.java
Test results: passed: 19

@caspernorrbin Could you please help review this? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3382427362
PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3382435867

From eastigeevich at openjdk.org  Wed Oct  8 17:10:14 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 8 Oct 2025 17:10:14 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
Message-ID: <IpgrWBdQPAhdGSgG13iKtKwyzBA-lPu7hjLVqppyDdY=.0be7ab07-5c33-42e5-ac04-91726a7d863e@github.com>

On Thu, 14 Aug 2025 15:41:36 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
>> 
>> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
>> 
>> This has passed tier1-3 and jcstress testing on AArch64.
>
> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>  - remove implementation-dependent logic from emit_shared_trampolines()
>  - cleanup: update copyright headers
>  - Make the value type of the dictionary a struct instead of Pair typedef
>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>  - Merge branch 'master'
>  - Address review comments from @theRealAph and @eastig
>    - use relocInfo::relocType instead of TrampolineCallKind
>    - move rtype from keys to values; reduce the footprint of the patch
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables
>  - 8359359: AArch64: share trampolines between static calls to the same method
>    
>    Modify the C2 compiler to share trampoline stubs between static calls
>    that resolve to the same callee method. Since the relocation target for
>    all static calls is initially set to the static call resolver stub, the
>    call's target alone cannot be used to distinguish between different
>    static method calls. Instead, trampoline stubs should be shared based
>    on the actual callee.
>    
>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>    trampolines among static calls. However, due to imprecise log analysis,
>    the test currently passes even when trampolines are not shared.
>    Additionally, comments within the test suggest ambiguity regarding
>    whether it was intended to assess trampoline sharing for static calls
>    or runtime calls. To address these issues and eliminate ambiguity, this
>    patch renames and updates the existing test. Furthermore, a new test is
>    introduced, using the existing one as a foundation, to accurately
>    evaluate trampoline sharing for both static and runtime calls.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 908:

> 906:       // code during its branch shortening phase.
> 907:       if (entry.rspec().type() == relocInfo::runtime_call_type) {
> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");

`assert(callee == nullptr, "Runtime calls must not have Method");`

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1340:

> 1338:   // enabling reuse across call sites to reduce code size.
> 1339:   // Runtime call trampolines are shared based on the entry value.
> 1340:   // Static call trampolines are shared by callee if it's not nullptr.

Maybe instead of two comment lines above, this would be better:

// Parameters:
//    entry - the type of the call and the call target address.
//    callee - Method which is destination of this call. Runtime calls must have it nullptr because they don't have Method representing them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414510305
PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2414507580

From jrose at openjdk.org  Wed Oct  8 19:02:44 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 8 Oct 2025 19:02:44 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

I like where this is going.  Thanks for putting in the hard work to make it happen.

doc/hotspot-style.md line 629:

> 627: occur. The C++98/03 `std::allocator` class is too limited to support our
> 628: usage. But changes to the allocator concept in more recent Standards removed
> 629: some of the limitations, supporting statefull allocators. HotSpot may, in the

s/statefull/stateful/

doc/hotspot-style.md line 647:

> 645: using those names easier, since the qualifiers don't need to be included. But
> 646: there are reasons not to do that.
> 647: 

s/reasons/several reasons/ (to better tee up the following bullet list)

doc/hotspot-style.md line 651:

> 649:     headers may be included, adding to the list of names being used. Also,
> 650:     future versions of the Standard Library may add currently unknown names to
> 651:     the headers already being included.

Maybe mention the `assert` macro at the end of the bullet, if there is no other example of a previous name collision:

> ?already being included.  (We already have a conflict from the HotSpot `assert` macro, although in that case the `std::` prefix is not applicable.)

doc/hotspot-style.md line 1971:

> 1969: 
> 1970: * `<system_error>`
> 1971: 

To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:

"HotSpot has its own timing support APIs."
"Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
"HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
"HotSpot has its own mechanisms for managing errors."

src/hotspot/share/code/relocInfo.cpp line 29:

> 27: #include "code/nmethod.hpp"
> 28: #include "code/relocInfo.hpp"
> 29: #include "cppstdlib/type_traits.hpp"

(I really, really like this scheme of wrapper headers for std stuff.  Thanks Kim!)

src/hotspot/share/cppstdlib/cstddef.hpp line 34:

> 32: // * std::max_align_t, std::nullptr_t
> 33: // * size_t (preferred) and std::size_t
> 34: // * ptrdiff_t (preferred) and std::ptrdiff_t

Are we 100% sure that `size_t` and `ptrdiff_t` will always be the `std` versions, on all platforms?
If not, uses of `std::size_t` and `std::ptrdiff_t` might turn out to be portability problems.

?Should I worry that `std::size_t` and `size_t` might be different types on some weirdo platform??

Maybe we should do a static-assert that those two names refer to the same type.
Then we can prove that the `std::` prefix will never cause the meaning of `size_t` to shift, on any platform.
I'm being a little paranoid here about possible failure modes specifically for `size_t`,
specifically because `size_t` is so pervasive and sensitive to type bugs.

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

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3315881937
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414655528
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414658231
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414716232
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414719117
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414738762
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414746409

From jrose at openjdk.org  Wed Oct  8 19:02:45 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 8 Oct 2025 19:02:45 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
Message-ID: <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>

On Wed, 8 Oct 2025 13:48:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 1658:
>> 
>>> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
>>> 1657: class is preferred to a tuple.
>>> 1658: 
>> 
>> I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.
>> 
>> I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.
>
> I have a different take on the distinction between forbidden and undecided. I
> think of forbidden features as being those where there are good arguments
> against. Whereas I think of undecided as perhaps having wishy washy arguments
> in either direction, or even not seriously thought about. But good arguments
> against can be overcome by better arguments in favor.
> 
> But I can see how someone else might take that distinction differently.
> 
> I also admit to being somewhat biased against tuple in particular. I've seen
> a few pretty terrible uses... one was even my fault!
> 
> So okay, I'll recategorize tuple.

I'm OK with cracking the door open on tuple, but I have to say I do like API-specific names very much.  (And `fst`/`snd` or whatever are not API specific; they are tuple-specific!)  So the guidance that steers folks towards name-based techniques, instead of positional techniques, is still sound.

I even like out-args, personally, in cases where the out-arg is for a return value that is clearly secondary to the main return value.  Example:  Main value is boolean, and out-arg is some hint about why the main value is what it is, like a position.  The out-arg can also be optional if a null pointer is tolerated (explicitly documented as such, of course), which is useful when the out-arg costs extra to compute.  (A separate boolean arg is OK for such uses also, but null pointers are so darn useful as optionality sentinels!)  Note that our TRAPS/THREAD macro system can be viewed as a giant set of out-args.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414737272

From kvn at openjdk.org  Wed Oct  8 19:21:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 8 Oct 2025 19:21:27 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
 <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
Message-ID: <6MwBlxzXOSumikJlhWS62V8JA1pqx05YoV2AxemI4XU=.5e6f579d-5967-4d52-afe2-30a402526a7f@github.com>

On Tue, 7 Oct 2025 19:02:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> First, what do you mean "blocks"? It wait something with lock?
>> 
>>> Second, my question was that slow path in clinit_barrier will jump to L_clinit_barrier_slow which is before clinit_barrier there are no branch there so after call_VM we again will call clinit_barrier? what I am missing?
>> 
>> `clinit_barrier` itself doesn't block. Its a quick check for class fully initialized or the current thread is the init thread. If not, then it jumps to the slow path. In this case slow path is the call to `InterpreterRuntime::resolve_from_cache` which may initialize the klass or get blocked if the klass is being initialized by another thread.
>> After returning it again executes `clinit_barrier`. But this time the class should have initialized, so it just falls through.
>> 
>> Also, I think `clinit_barrier` is not a very accurate name because it doesn't cause initialization of the klass. I think `fast_clinit_check` better conveys what it is doing, but that renaming can be done later if required.
>
>> After returning it again executes clinit_barrier. But this time the class should have initialized, so it just falls through.
> 
> There are no guarantees that the class is initialized. But the only case when it doesn't hold is when the class is being initialized and current thread is initializing one. So, it is guaranteed that slow path is taken at most once. 
> 
>> I think fast_clinit_check better conveys what it is doing
> 
> `clinit_barrier` implements a fast path check, so `clinit_barrier_fast_path` maybe a more accurate variant.

@iwanowww  I see next changes in Leyden repo only for aarch64. Do we need it?


diff --git a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
index 2ccde98d98d..6fbe6a3a89d 100644
--- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
@@ -352,6 +352,18 @@ void TemplateTable::ldc(LdcType type)
   __ cmp(r3, (u1)JVM_CONSTANT_Class);
   __ br(Assembler::NE, notClass);

+  __ load_resolved_klass_at_offset(r2, r1, r3, rscratch1); // kills r3=tag
+
+  __ cmp(r3, zr); // resolved_klass ?= null
+  __ br(Assembler::EQ, call_ldc);
+
+  const int mirror_offset = in_bytes(Klass::java_mirror_offset());
+  __ ldr(r3, Address(r3, mirror_offset));
+  __ resolve_oop_handle(r3, rscratch1, rscratch2);
+  __ push_ptr(r3);
+
+  __ b(Done);
+
   __ bind(call_ldc);
   __ mov(c_rarg1, is_ldc_wide(type) ? 1 : 0);
   call_VM(r0, CAST_FROM_FN_PTR(address, InterpreterRuntime::ldc), c_rarg1);

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3382890408

From vlivanov at openjdk.org  Wed Oct  8 19:42:37 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 8 Oct 2025 19:42:37 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
Message-ID: <t418ED5OgCf8rO0__y40mgcQ0TtP6beUdNRopKXk9BE=.509b3cc8-f5db-4782-9edb-cee42eb647f2@github.com>

On Wed, 8 Oct 2025 14:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for riscv
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Thanks for the ping! PPC64 implementation:
> 
> diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> index 7431f77aeff..373dc24a62f 100644
> --- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> +++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> @@ -2179,17 +2179,11 @@ void TemplateTable::_return(TosState state) {
>  //   - Rscratch
>  void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rcache, Register Rscratch) {
>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
> +
>    Label Lresolved, Ldone, L_clinit_barrier_slow;
>    Register Rindex = Rscratch;
>  
>    Bytecodes::Code code = bytecode();
> -  switch (code) {
> -    case Bytecodes::_nofast_getfield: code = Bytecodes::_getfield; break;
> -    case Bytecodes::_nofast_putfield: code = Bytecodes::_putfield; break;
> -    default:
> -      break;
> -  }
> -
>    const int bytecode_offset = (byte_no == f1_byte) ? in_bytes(ResolvedMethodEntry::bytecode1_offset())
>                                                     : in_bytes(ResolvedMethodEntry::bytecode2_offset());
>    __ load_method_entry(Rcache, Rindex);
> @@ -2201,10 +2195,9 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>  
>    // Class initialization barrier slow path lands here as well.
>    __ bind(L_clinit_barrier_slow);
> -
>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>    __ li(R4_ARG2, code);
> -  __ call_VM(noreg, entry, R4_ARG2, true);
> +  __ call_VM(noreg, entry, R4_ARG2);
>  
>    // Update registers with resolved info.
>    __ load_method_entry(Rcache, Rindex);
> @@ -2226,12 +2219,10 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>    __ bind(Ldone);
>  }
>  
> -void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
> -                                            Register Rcache,
> -                                            Register index) {
> +void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcache, Register index) {
>    assert_different_registers(Rcache, index);
>  
> -  Label resolved;
> +  Label Lresolved, Ldone, L_clinit_barrier_slow;
>  
>    Bytecodes::Code code = bytecode();
>    switch (code) {
> @@ -2246,19 +2237,34 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>                                           : in_bytes(ResolvedFieldEntry::put_code_offset());
>    __ lbz(R0, code_offset, Rcache);
>    __ cmpwi(CR0, R0, (int)code); // have we resolved th...

@TheRealMDoerr with your patch `isync` is bypassed after `InterpreterRuntime::resolve_from_cache` call. Is it intentional?

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3382963607

From vlivanov at openjdk.org  Wed Oct  8 19:42:38 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 8 Oct 2025 19:42:38 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <6MwBlxzXOSumikJlhWS62V8JA1pqx05YoV2AxemI4XU=.5e6f579d-5967-4d52-afe2-30a402526a7f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <bPuA5u6Hox8Wkeunj6vzogQGLJZ-1994bNLqM1PNe3Q=.d2b293fd-8079-484f-9807-4a5da265f71d@github.com>
 <ODy4L1h6FJdlozEV-F7LguChbXR7CssmouGSPVvPXzk=.f1f22015-1aec-4959-abd1-68e3a1a02114@github.com>
 <ciKFZS1ZNW1sqisVrcasXINeYN36ft6fp09iJz_jy5g=.942bada2-b12d-49bb-b433-82a91567680a@github.com>
 <OPvkK1CZHIeU8Vq34Pq-sRmtwjQGxvr94qY_BnP625g=.c43e4fe4-dba9-40e5-bd92-a52c4dd85005@github.com>
 <Q6x-V9VSL-invMsx1jLx89VptNK3p82q-OK_VlFl05k=.3fa6db0c-4061-4865-86d3-80a8f1c062e5@github.com>
 <6MwBlxzXOSumikJlhWS62V8JA1pqx05YoV2AxemI4XU=.5e6f579d-5967-4d52-afe2-30a402526a7f@github.com>
Message-ID: <Um875WFL3pU9DfkvwraLKjfom7DTubkS8sy5EKF-JyY=.a9cf0817-1e6e-4295-9d21-095cd4d1f2c3@github.com>

On Wed, 8 Oct 2025 19:19:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> After returning it again executes clinit_barrier. But this time the class should have initialized, so it just falls through.
>> 
>> There are no guarantees that the class is initialized. But the only case when it doesn't hold is when the class is being initialized and current thread is initializing one. So, it is guaranteed that slow path is taken at most once. 
>> 
>>> I think fast_clinit_check better conveys what it is doing
>> 
>> `clinit_barrier` implements a fast path check, so `clinit_barrier_fast_path` maybe a more accurate variant.
>
> @iwanowww  I see next changes in Leyden repo only for aarch64. Do we need it?
> 
> 
> diff --git a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
> index 2ccde98d98d..6fbe6a3a89d 100644
> --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
> +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
> @@ -352,6 +352,18 @@ void TemplateTable::ldc(LdcType type)
>    __ cmp(r3, (u1)JVM_CONSTANT_Class);
>    __ br(Assembler::NE, notClass);
> 
> +  __ load_resolved_klass_at_offset(r2, r1, r3, rscratch1); // kills r3=tag
> +
> +  __ cmp(r3, zr); // resolved_klass ?= null
> +  __ br(Assembler::EQ, call_ldc);
> +
> +  const int mirror_offset = in_bytes(Klass::java_mirror_offset());
> +  __ ldr(r3, Address(r3, mirror_offset));
> +  __ resolve_oop_handle(r3, rscratch1, rscratch2);
> +  __ push_ptr(r3);
> +
> +  __ b(Done);
> +
>    __ bind(call_ldc);
>    __ mov(c_rarg1, is_ldc_wide(type) ? 1 : 0);
>    call_VM(r0, CAST_FROM_FN_PTR(address, InterpreterRuntime::ldc), c_rarg1);

@vnkozlov it is an unrelated change in Leyden to support pre-resolved CP entries for ldc bytecode (to save on `InterpreterRuntime::ldc` calls into interpreter runtime).

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3382972475

From vlivanov at openjdk.org  Wed Oct  8 19:45:31 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 8 Oct 2025 19:45:31 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <a70cfi4qdXz2ageu56LR-Yucx2xhlZCQLFOgGTuCQw8=.d6afcb25-0d9e-4c3f-a433-009a80fe72c8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <a70cfi4qdXz2ageu56LR-Yucx2xhlZCQLFOgGTuCQw8=.d6afcb25-0d9e-4c3f-a433-009a80fe72c8@github.com>
Message-ID: <sqDmiXFnu8xAe864MVJthP10edSqDiYBnp1joTJ7kRY=.8c27e8bf-6ed4-4aca-9d10-4c54be0d5bef@github.com>

On Wed, 8 Oct 2025 15:37:14 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> My proposal avoids it by jumping over it. Is that better or at least less confusing?

@TheRealMDoerr it looks fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3382982996

From sspitsyn at openjdk.org  Wed Oct  8 20:17:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:17:27 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
 <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
Message-ID: <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>

On Fri, 19 Sep 2025 11:47:50 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?

It depends. And no, it is not always 'human' level (debuggers, etc). It is used by profilers as well especially via Instrumentation API. And yes, JVMTI is that it's less performance sensitive than the usual JVM. However, it'd be nice to improve its performance, not degrade. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3383072852

From sspitsyn at openjdk.org  Wed Oct  8 20:30:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:30:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <np8mKw3qDSuT-S_1viDlLak4nnMnMrwuUmB6pkQg_B8=.7796826e-53b4-4224-8e10-9592750f1dcf@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <np8mKw3qDSuT-S_1viDlLak4nnMnMrwuUmB6pkQg_B8=.7796826e-53b4-4224-8e10-9592750f1dcf@github.com>
Message-ID: <UdEhW7UANuwDJTqRrQ1yEITHW26u-TVX5G5LL9inQdc=.e921d84c-f2dd-4215-b7a6-754a13800edf@github.com>

On Thu, 25 Sep 2025 12:10:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.hpp line 116:
>> 
>>> 114:     return _argument_count;
>>> 115:   }
>>> 116:   int argument(int n) const {
>> 
>> Q: Why was the function name changed?
>
> I think `argument_index` sounds a bit misleading, "the nth argument" makes more sense imo. Yes, I introduced the original name :-).

Why do you think the `argument_index` sounds a bit misleading? It is a CP index, is not it?
In opposite, the name `argument` is confusing. I'm suggesting to restore the function name.
Additionally, it is not easy to review relatively big refactoring, so it makes sense to avoid unnecessary renaming if possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414959885

From sspitsyn at openjdk.org  Wed Oct  8 20:36:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:36:25 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <kyvxF6Ha8z3b-U7Gl6pDr3c5NVzPD_zyrxaNN0BnGJ8=.d1d31984-8494-4164-9298-afae1d3c2bc3@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
 <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>
 <ju_FTYh8VnnpzfIabA-d2eBiydCuMc6Oa9okVz6k55U=.f0911423-85ee-4db7-a8a2-17aa0a91a91f@github.com>
 <kyvxF6Ha8z3b-U7Gl6pDr3c5NVzPD_zyrxaNN0BnGJ8=.d1d31984-8494-4164-9298-afae1d3c2bc3@github.com>
Message-ID: <dbp7OplmRrOf546hnE6RCLyFexZSGq2ztrBzdNailDM=.ab4fd1d8-d3bd-4dd7-a34e-be72cb4b6c98@github.com>

On Fri, 26 Sep 2025 10:17:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Why not? This PR is introducing these two classes. It is better to do in a simplified form. :)
>
> It's only introducing the BSMAttributeEntries class, the other one is pre-existing. I don't want the PR to get stuck on whether or not to do a rename of something previously determined to be fine.

Okay then. I agree, it is not a good idea to rename pre-existing identifiers in this PR. But naming consistency is still important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414971254

From kvn at openjdk.org  Wed Oct  8 21:54:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 8 Oct 2025 21:54:08 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
Message-ID: <vjdafDFxKd2rEZVqhC6IT_npMV8EtJVU7uuMvDaglYc=.2de99ba4-e9bc-447c-8e55-e24e6c8aae69@github.com>

On Wed, 8 Oct 2025 13:44:25 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for riscv
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

My testing finally finished.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3316630369

From sspitsyn at openjdk.org  Wed Oct  8 22:25:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 22:25:15 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
Message-ID: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>

On Wed, 8 Oct 2025 07:43:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Changes requested by sspitsyn (Reviewer).

src/hotspot/share/classfile/classFileParser.cpp line 3342:

> 3340: 
> 3341:     BSMAttributeEntry* entry = iter.reserve_new_entry(bootstrap_method_ref, num_bootstrap_arguments);
> 3342:     guarantee_property(entry != nullptr, "Invalid BootstrapMethods num_bootstrap_methods. The total amount of space reserved for the BootstrapMethod attribute was not sufficient", CHECK);

Nit: This line is too big. It is a good idea to split the message. Also, would it better to move this guaranty for `nullptr` into the `reserve_new_entry()`?

src/hotspot/share/classfile/classFileParser.cpp line 3345:

> 3343: 
> 3344:     for (int argi = 0; argi < num_bootstrap_arguments; argi++) {
> 3345:       const u2 bootstrap_argument_index = cfs->get_u2_fast();

Nit: There is no need to rename `argument_index` to `bootstrap_argument_index`. It makes it harder to review. In this specific context it is clear that the argument index is a bootstrap method argument index.

src/hotspot/share/oops/bsmAttribute.hpp line 97:

> 95:     int _cur_offset;
> 96:     // Current unused offset into BSMAEs bsm-data array
> 97:     int _cur_array;

Nit: The declarations at lines 95, 97 will be more readable if comments above declarations trail declarations. The comment should not start with capital.

src/hotspot/share/oops/bsmAttribute.hpp line 120:

> 118:   Array<u2>* _bootstrap_methods;
> 119: 
> 120:   // Copy the first num_entries into iter

Nit: Dot is absent at the end of comment.

src/hotspot/share/oops/bsmAttribute.inline.hpp line 34:

> 32:       _cur_array + BSMAttributeEntry::u2s_required(argc) > insert_into->bootstrap_methods()->length()) {
> 33:     return nullptr;
> 34:   }

Nit: This check needs a comment. Also, I'd suggest to add a guarantee here instead of returning `nullptr`.

src/hotspot/share/oops/bsmAttribute.inline.hpp line 35:

> 33:     return nullptr;
> 34:   }
> 35:   insert_into->_offsets->at_put(_cur_offset, _cur_array);

Q: Can `insert_into->_offsets` be `nullptr` here? Should we add an assert?

src/hotspot/share/oops/constantPool.cpp line 1626:

> 1624: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
> 1625:                                  const constantPoolHandle& to_cp,
> 1626:                                  TRAPS) {

Nit: Indent is not right.

src/hotspot/share/oops/constantPool.hpp line 94:

> 92:   InstanceKlass*       _pool_holder; // the corresponding class
> 93: 
> 94:   BSMAttributeEntries _bsmaentries;

Nit: Suggestion to rename: `_bsmaentries` => `_bsm_entries`.

src/hotspot/share/oops/constantPool.inline.hpp line 90:

> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
> 89: }
> 90: 

Nit: Is this really needed?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 682:

> 680:   const int new_bs_i = _bsmae_iter.current_offset();
> 681:   BSMAttributeEntry* new_bsme =
> 682:     _bsmae_iter.reserve_new_entry(new_ref_i, old_bsme->argument_count());

Nit: There is not check for `new_bsme == nullptr`.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3316437973
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414977385
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415001187
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415015413
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415020512
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415042398
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415048756
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415138981
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415149935
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415151472
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415039223

From dlong at openjdk.org  Wed Oct  8 22:48:10 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 22:48:10 GMT
Subject: RFR: 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers
 and wrong store order in MacroAssembler [v6]
In-Reply-To: <HDev0Ot_UAnPpufdHocg7kbU9uSFHzjQsYmmT3bZCRY=.303df056-8858-425f-82c5-5c3c8b5fc5af@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
 <HDev0Ot_UAnPpufdHocg7kbU9uSFHzjQsYmmT3bZCRY=.303df056-8858-425f-82c5-5c3c8b5fc5af@github.com>
Message-ID: <v7yiiGIsdXCSqA35y_SxRhypgxFm7Tjuyo_atM7u5VU=.f3ba8813-f143-4d40-8827-34f267b45702@github.com>

On Wed, 8 Oct 2025 12:31:39 GMT, Justin King <jcking at openjdk.org> wrote:

>> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.
>
> Justin King has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Revert "JDK-8369190: JavaFrameAnchor on AArch64 appears to be missing barriers"
>    
>    This reverts commit 462c63e588ebf0dcd478b5347684ccb6c2438686.
>  - Revert "Update comments"
>    
>    This reverts commit a0058eb4405a9afb0db80d9838e0657f725c9a15.
>  - Revert "Rename ACGT -> AGCT"
>    
>    This reverts commit a141449425a72a4095b9740e28c758cb295c9352.
>  - Revert "Remove barriers and just fix program order for sp store in MacroAssembler"
>    
>    This reverts commit 253417f98e7d5680a3ad6f8561b198fc0ae3b141.
>  - Revert "Add comment to JavaFrameAnchor regarding no need for fencing"
>    
>    This reverts commit 016769dfe4272d7cb37d46524f32e9f7a4887b11.
>  - Revert "Move compiler_barrier() to globalDefinitions.hpp and use it"
>    
>    This reverts commit 6dd80d947a343ad6c45d1738614643f7013afcbc.
>  - Revert "Add back header inclusion"
>    
>    This reverts commit 7dc3313c9fd6a4f2739c39dc4d9d075103894aa9.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27645#pullrequestreview-3316723095

From dlong at openjdk.org  Wed Oct  8 22:50:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 22:50:03 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v2]
In-Reply-To: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
Message-ID: <UNjXoCzt9h1vv_SB_BgOl7Rm8smVpjtcVxilP6v6nf4=.61cc6d66-39c6-40f7-a68c-1c437fc249b9@github.com>

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

Dean Long has updated the pull request incrementally with two additional commits since the last revision:

 - test C1 and C2 separately, fix -Xcomp slowdown
 - add pseudo-code, remove unnecessary nop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27683/files
  - new: https://git.openjdk.org/jdk/pull/27683/files/adda0184..5d6bcc17

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

  Stats: 25 lines in 3 files changed: 21 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27683/head:pull/27683

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

From dlong at openjdk.org  Wed Oct  8 23:08:25 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 23:08:25 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v3]
In-Reply-To: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
Message-ID: <s0TsKYEh_ba5s2qMLa6QTJf5NVM-3HKJFf5UN85icbs=.24ee1042-5fe0-4ee4-8858-05e8fb8742b8@github.com>

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  possible fix for zero build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27683/files
  - new: https://git.openjdk.org/jdk/pull/27683/files/5d6bcc17..5236804b

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

  Stats: 8 lines in 3 files changed: 5 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27683/head:pull/27683

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

From dlong at openjdk.org  Wed Oct  8 23:17:40 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 23:17:40 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
Message-ID: <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  Delete test/hotspot/jtreg/compiler/exceptions/a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27683/files
  - new: https://git.openjdk.org/jdk/pull/27683/files/5236804b..9f70a47b

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

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

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

From dlong at openjdk.org  Wed Oct  8 23:17:42 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 8 Oct 2025 23:17:42 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <cOnK1dVTqQK0y0q3trfrr7zmhyS30lRusyPV1ZA6d3w=.df24534e-6f42-416e-8c13-8a55a7225708@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
 <cOnK1dVTqQK0y0q3trfrr7zmhyS30lRusyPV1ZA6d3w=.df24534e-6f42-416e-8c13-8a55a7225708@github.com>
Message-ID: <eg48SjIIEG-ZWRrtdrJfx8u2xW3USoliLKGq7BcAFeQ=.76b6c8c8-6d14-4513-b23c-707be300de2e@github.com>

On Wed, 8 Oct 2025 05:56:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete test/hotspot/jtreg/compiler/exceptions/a
>
> test/hotspot/jtreg/compiler/exceptions/TestAccessErrorInCatch.java line 30:
> 
>> 28:  *
>> 29:  * @compile IllegalAccessInCatch.jasm
>> 30:  * @run main/othervm -Xbatch TestAccessErrorInCatch
> 
> Should this test be disabled if explicit compilation directives (e.g. `-Xcomp`) are being passed in?

The test will still pass with -Xcomp but run slower than necessary.  I added -XX:CompileCommand=compileonly to fix this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27683#discussion_r2415215842

From kbarrett at openjdk.org  Thu Oct  9 00:55:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 00:55:10 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <0_An3HGn6Xd-zcB-53QaFn5tfq7u4CFIQAr1srQAjOY=.bf4127ac-a6c4-4c42-a9e4-ae24df62bfe3@github.com>

On Wed, 8 Oct 2025 18:12:44 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 629:
> 
>> 627: occur. The C++98/03 `std::allocator` class is too limited to support our
>> 628: usage. But changes to the allocator concept in more recent Standards removed
>> 629: some of the limitations, supporting statefull allocators. HotSpot may, in the
> 
> s/statefull/stateful/

Fixed locally for next push.

> doc/hotspot-style.md line 647:
> 
>> 645: using those names easier, since the qualifiers don't need to be included. But
>> 646: there are reasons not to do that.
>> 647: 
> 
> s/reasons/several reasons/ (to better tee up the following bullet list)

Fixed locally for next push.

> doc/hotspot-style.md line 651:
> 
>> 649:     headers may be included, adding to the list of names being used. Also,
>> 650:     future versions of the Standard Library may add currently unknown names to
>> 651:     the headers already being included.
> 
> Maybe mention the `assert` macro at the end of the bullet, if there is no other example of a previous name collision:
> 
>> ?already being included.  (We already have a conflict from the HotSpot `assert` macro, although in that case the `std::` prefix is not applicable.)

There aren't any previous examples because we don't have any examples of doing
this thing that we're warning against (`using` a namespace).  `assert` is a
different problem, unrelated to namespaces. (Remember that one of the usual
knocks against macros is that they don't respect namespaces.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313253
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313425
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313670

From dholmes at openjdk.org  Thu Oct  9 02:03:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:03:16 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

Sorry @afshin-zafari but this PR has me quite confused. The code changes do not reflect the PR description. The PR description does not obviously connect to the JBS problem statement. And the code changes in the PR seem unrelated to the value of aligned_heap_base_min_address as referenced in JBS.

And the cast changes in memoryReserver.cpp seem completely unrelated.

That said, I do not know how all of these heap variables interact and relate, so you really need the GC folk to understand and approve this.

src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:

> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
> 288:   if (value + MaxHeapSize < MaxHeapSize) { // overflow

Sorry I am struggling to see how this check differs in practice to the existing check:

(value > (max_uintx - MaxHeapSize))

Further, the comment before the new check seems to relate to the existing check.

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

PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3316975754
PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2415374984

From dholmes at openjdk.org  Thu Oct  9 02:08:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:08:07 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <BcSiADOz3PuL2aGThKS0UTlFlTZjXwpzNpFyuztnB8k=.49fc6743-ef25-46ec-8432-903deed615a5@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
 <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
 <VuK3AaZ6zIZmNgnGWk0ydc9wEazGvyHdfWiDVFeurHs=.514d7ab3-2811-4764-99a6-9ca95b20de1b@github.com>
 <BcSiADOz3PuL2aGThKS0UTlFlTZjXwpzNpFyuztnB8k=.49fc6743-ef25-46ec-8432-903deed615a5@github.com>
Message-ID: <dIvZ3g5gD63kYKL0ztB_2Sh8CLSsnzDJ8zvtlAgd3EY=.2757ef4f-189b-47b9-b69f-01892376f4db@github.com>

On Wed, 8 Oct 2025 08:05:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.
> > 
> > 
> > @AlanBateman yes that is exactly what I am suggesting. Thanks
> 
> I discussed this with Ron. Mutating final fields from native code isn't core to this JEP. A fatal error would be better but we are okay with it initially being a warning instead. So we'll update that section of the JEP, and change the addition to jniCheck to use ReportJNIWarning instead of ReportJNIFatalError.

Thank you @AlanBateman and @pron !

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3383789373

From dholmes at openjdk.org  Thu Oct  9 02:34:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:34:08 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
 <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
Message-ID: <BRPHw7jOeGJ-W7mzOKHIDRWUVpqXUPca3c-QA9naihA=.320147bf-027c-4d76-bb04-7123381bfa9a@github.com>

On Wed, 8 Oct 2025 23:17:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete test/hotspot/jtreg/compiler/exceptions/a

Thanks for the test adjustments. Sorry I can't review the main fix though.

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

PR Review: https://git.openjdk.org/jdk/pull/27683#pullrequestreview-3317023660

From dholmes at openjdk.org  Thu Oct  9 02:48:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:48:02 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

Ignoring the name for now, I think having three sets of methods is confusing - how will anyone know whether they should be using `os::free_memory` or `os::machine_free_memory`? The former says nothing about containers.

IIUC the problem you are trying to resolve is that some existing `os::xxx` return values that account for containers and you would like to know the non-container limits. Does that happen often enough that we need 3 complete sets of API method's, or can we augment the problematic methods with a default parameter `bool ignoreContainers = false` so you can ask for the non-container version?

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

PR Review: https://git.openjdk.org/jdk/pull/27646#pullrequestreview-3317041634

From dholmes at openjdk.org  Thu Oct  9 02:51:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:51:03 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <xXfdVMCDfePMHu0YWoh-JSkzrSYZa1lHQDg5JvczZ5g=.25d441f5-6f87-4e31-ac91-00437d823701@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

By the way it keeps getting mentioned that only Linux has container support, but we have started augmenting some of the Windows `os::xxx` functions to account for Windows Jobs (which can restrict available resources similarly to containers).

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3383855204

From dholmes at openjdk.org  Thu Oct  9 02:56:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:56:12 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <Bc-AJ9ooqAz_9t6yBmHCwBLVbBuHyB3ttwZQAvx7IIE=.f4aef02c-27ef-4a81-89fd-263640cea3d7@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

Also I think this might need to account for the changes to `Arguments::set_heap_size` being done in https://github.com/openjdk/jdk/pull/27224

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3383863313

From kbarrett at openjdk.org  Thu Oct  9 03:04:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 03:04:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>

On Wed, 8 Oct 2025 18:40:01 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 1971:
> 
>> 1969: 
>> 1970: * `<system_error>`
>> 1971: 
> 
> To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:
> 
> "HotSpot has its own timing support APIs."
> "Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
> "HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
> "HotSpot has its own mechanisms for managing errors."

I'll add some stuff to the PR change.

> "HotSpot has its own timing support APIs."

The argument for chrono is that our existing APIs aren't serving us well.
chrono provides strong type safety. We've had multiple cases of mistakes like
a double seconds being treated as double millis or vice versa, and other
similar errors. But it would be a large effort to adopt chrono. And we'd need
to decide whether to use the predefined clocks or hook up chrono to our
clocks. It may be that using the predefined clocks is fine, but it's a
question that needs careful study.

> "Initializer lists are an advanced C++ API feature which have surprising
> interactions with other initialization syntaxes in use in HotSpot."

I think the trailing "in use in HotSpot" can be dropped from that. Mostly I
think they are fine, but the potential ambiguity between some forms of direct
initialization and initializer list initialization, and the resolution of that
ambiguity, is unfortunate.

> "HotSpot uses floating point numbers ..."

Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also
fixed (though parameterized) precision. It's not a general purpose rational
arithmetic facility. My understanding is that it started life as a detail of
chrono, and was extracted and promoted to a public facility in the belief that
it has broader utility.

> "HotSpot has its own mechanisms for managing errors."

Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc
mechanisms. There's a bunch of discussion happening around that topic lately.
I don't think we've coalesced around any particular approach yet. And even
once we decided on something it's likely to take quite a while for rollout to
really make use of whatever we settle on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415447980

From kbarrett at openjdk.org  Thu Oct  9 03:37:05 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 03:37:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <7WSKAc7KY9uAmaHcNeZoYVFqQ-0Ekq16_W4-BonyR1I=.5b14e9f6-cce5-4993-8d03-a382044b5806@github.com>

On Wed, 8 Oct 2025 18:52:20 GMT, John R Rose <jrose at openjdk.org> wrote:

> Are we 100% sure ...

Yes.

> Should I worry ...

No.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2340r0.html
Clarifying the status of the "C headers"

On the basis of that paper, C++23 undeprecated the C headers (they'd been
deprecated since C++98) and gave them their own section in the main body of
the standard, rather than being relegated to an appendix.

The guidance is that a C++ source file should only include C headers if the
file also needs to be valid C source. I'm planning to nudge us in that
direction, except by using our own wrapper headers, like cppstdlib/cstddef.hpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415481626

From kbarrett at openjdk.org  Thu Oct  9 04:07:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 04:07:02 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - jrose comments
 - move tuple to undecided category

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27601/files
  - new: https://git.openjdk.org/jdk/pull/27601/files/98e7ccbb..c886ec36

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

  Stats: 78 lines in 2 files changed: 55 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From dholmes at openjdk.org  Thu Oct  9 04:43:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 04:43:19 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v6]
In-Reply-To: <MHrZoyWiKnmNNKuufHj5w8EdCsBYASMVdKtN24UlxVI=.0af680e4-bd65-4409-91af-a3dcbe6ef384@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
 <MHrZoyWiKnmNNKuufHj5w8EdCsBYASMVdKtN24UlxVI=.0af680e4-bd65-4409-91af-a3dcbe6ef384@github.com>
Message-ID: <4TSsGtXYZV6_pKLIEvaEXQx8wLyVNjMzkm3FHUo1l4A=.c5ca9788-6837-4318-9631-b90c8204b5df@github.com>

On Wed, 8 Oct 2025 08:13:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 169:
>> 
>>> 167:     LogStream ls(lt);
>>> 168:     cur_state->print_on(&ls);
>>> 169:   }
>> 
>> Why is this not useful for debugging? I can understand you might not need it for your profiling but UL is primarily about debugging assistance.
>
> I reasoned it is way too noisy to be useful even for debugging. 
> 
> Note this is `thread_not_running()` checker, which is called from two places in `SafepointSynchronize::synchronize_threads`: initial filtering and on-going checks for state changes. In well-behaved applications most of the threads are actually not running, blocked somewhere in idle thread pool. So prnting this from the initial filtering dumps info on potentially thousands of threads we do not care about 99.9% of the time.
> 
> I argued to myself that what we really care about are the threads that are _transiting_ from runnable to blocked. So the new `log_trace(safepoint)` statements are in caller code that uses this `thread_not_running()` checker, and is able to print exactly what they see. "thread is now blocked", for example.
> 
> I don't think there are useful bits in `TSS`, really. We can amend trace logs to pull some of that, if you want. Look what it prints in current mainline:
> 
> 
> [792737314ns] Thread: 0x0000785db85bf4c0  [0x214944] State: _running _at_poll_safepoint 0
> [792737594ns]    JavaThread state: _thread_in_Java
> [792738025ns] Thread: 0x0000785db85c08e0  [0x214945] State: _running _at_poll_safepoint 1
> [792738246ns]    JavaThread state: _thread_in_vm

I thought it was intended to report which threads still running - i.e. are not reaching the safepoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2415550637

From dholmes at openjdk.org  Thu Oct  9 04:47:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 04:47:08 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v6]
In-Reply-To: <JGk5JkT9o5-ac5irH7lhcZPqd1KmEYdjYTkzeq8thPM=.d0aafe71-1ae6-45a0-afd7-f7fd20bec482@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <JGk5JkT9o5-ac5irH7lhcZPqd1KmEYdjYTkzeq8thPM=.d0aafe71-1ae6-45a0-afd7-f7fd20bec482@github.com>
Message-ID: <IZTj4kMziVg4qfF4_leq-kn3_QDgUxs1bEZ6wQct1UU=.376e17a0-143d-4152-8e3e-ff548e1bab91@github.com>

On Wed, 8 Oct 2025 08:36:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Put polling exception tracing back with minor reformat
>  - Touchups

Still one query on the removed part, but okay, seems reasonable.

I seemed to recall that once-upon-a-time we had TraceTimers(?) to gather the interesting elapsed time and other stats for safepoints.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27673#pullrequestreview-3317206045

From aboldtch at openjdk.org  Thu Oct  9 06:05:42 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 06:05:42 GMT
Subject: RFR: 8369466: Rdtsc: Adapt do_time_measurements to allow for
 non-JavaThreads
Message-ID: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>

Currently `Rdtsc::initialize` may be called from the first ElapsedCounter now call. Currently this happens at different points during bootstrapping depending on what subsystem is active like JFR, which GC etc.

The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.

It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.

Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.

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

Commit messages:
 - 8369466: Rdtsc: Adapt do_time_measurements to allow for non-JavaThreads

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

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

From aboldtch at openjdk.org  Thu Oct  9 06:07:34 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 06:07:34 GMT
Subject: RFR: 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version
 stub area
Message-ID: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>

Currently these stubs are created in `Rdtsc::initialize` which may be called from the first ElapsedCounter now call. This causes problems with lock ranks as we may be holding a lock while taking time, because we need to lock the code cache to create a stub.

I suggest we move the `getCPUIDBrandString_stub` next to the other `VM_Version` stubs and generate them together. This is done at the earliest point we can, right after the CodeCache system has been initialized.

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

Commit messages:
 - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Changes: https://git.openjdk.org/jdk/pull/27711/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27711&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369468
  Stats: 29 lines in 3 files changed: 4 ins; 24 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27711.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27711/head:pull/27711

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

From aboldtch at openjdk.org  Thu Oct  9 06:25:36 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 06:25:36 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
Message-ID: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>

The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
However the current implementation does not do this correctly in all places, where it does:

  static bool initialized = false;
  if (!initialized) {
    ...
    initialized = true;
  }

It should do

static bool initialized = initialize_impl(); // Do the logic inside a function call

to guarantee that initialize is only called once.

We have observed this from some GC threads if we start using Ticks to early.

The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.

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

Depends on: https://git.openjdk.org/jdk/pull/27711

Commit messages:
 - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize

Changes: https://git.openjdk.org/jdk/pull/27712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369469
  Stats: 65 lines in 4 files changed: 25 ins; 17 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/27712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27712/head:pull/27712

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

From aboldtch at openjdk.org  Thu Oct  9 06:37:45 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 06:37:45 GMT
Subject: RFR: 8369467: Rdtsc: Avoid initialize_elapsed_counter when
 UseFastUnorderedTimeStamps will be disabled
Message-ID: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>

The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.

I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.

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

Depends on: https://git.openjdk.org/jdk/pull/27712

Commit messages:
 - 8369467: Rdtsc: Avoid initialize_elapsed_counter when UseFastUnorderedTimeStamps will be disabled

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

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

From mli at openjdk.org  Thu Oct  9 08:10:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 08:10:18 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <MSBpil5SJHsM4Gt9tYAlLzrzfOifYrrE5pKWsZzuICI=.a82a1cf8-c077-443b-a4da-82abcc074220@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
 <MSBpil5SJHsM4Gt9tYAlLzrzfOifYrrE5pKWsZzuICI=.a82a1cf8-c077-443b-a4da-82abcc074220@github.com>
Message-ID: <2kflAS5_PEsIE-83SwwD6Jgd5NSQ5MjWH-rvUucI7FA=.26670029-8b92-41f7-b739-1daff6cad0da@github.com>

On Wed, 8 Oct 2025 07:01:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?
>> 
>> I think this should be in another pr.
>> 
>>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?
>> 
>> If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.
>> 
>>> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>>> Can we agree to one consistent way?
>> 
>> As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.
>
> @Hamlin-Li : Can we remove the `non_ext_` name prefix for non-extension features and maybe the `enabled()` check as well as we previously discussed?

Sure, seems the prefix does not help reading the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2415922614

From cnorrbin at openjdk.org  Thu Oct  9 08:17:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Oct 2025 08:17:44 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <1vO3JgxDzxUaQ7IYAAeo3Bt5VaNAdRwxCXrgchDlKjk=.babddb6c-566b-4a69-bf77-67b0e709ed5c@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

Looks good. Thank's for catching this!

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

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27699#pullrequestreview-3317727019

From jsikstro at openjdk.org  Thu Oct  9 08:21:01 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 9 Oct 2025 08:21:01 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v8]
In-Reply-To: <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
 <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>
Message-ID: <PzNRah3SAKayRFZjLY7SHIiUf6gpbZ2vCnjr5aQ-qBs=.1dfd6464-cfca-403d-abff-886f9d900962@github.com>

On Wed, 8 Oct 2025 13:11:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
>>  - Rename limit_by_size_t_max to clamp_by_size_t_max
>>  - Make limit_by_size_t_max to a static function in arguments.cpp
>>  - Rename ram_limit_set to has_ram_limit
>>  - Revert MaxRAM default removals, defer to future enhancement
>>  - Namings and comment
>>  - 8367413: Refactor types in Arguments::set_heap_size()
>>  - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
>>  - Revert "8367413: Use size_t instead of julong in runtime/arguments.cpp"
>>    
>>    This reverts commit 35c6057a4b5f0e478f3e703f6fa14b137cd73ca8.
>>  - Revert "size_t casts for 32-bit part of test_arguments.cpp"
>>    
>>    This reverts commit dba2ab4699b9295ba406abf174a7829600ce8625.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7
>
> Marked as reviewed by ayang (Reviewer).

For sanity I reran tier1-4, which looks good. Thank you for the reviews @albertnetymk and @lkorinth.

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

PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3384683108

From jsikstro at openjdk.org  Thu Oct  9 08:21:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 9 Oct 2025 08:21:03 GMT
Subject: Integrated: 8367413: Fix potential truncation error in
 Arguments::set_heap_size()
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <WxRAtaIFey0xGsVPIK_6KApML94nDIK293-n7LAGdeI=.1c7b512a-949b-47a7-8a7e-9c243a0c5748@github.com>

On Thu, 11 Sep 2025 12:39:18 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> There are several integer types used when setting the heap size ergonomically in `Arguments::set_heap_size()`, such as julong, uint64_t and size_t. It's not clear if this code works as intended on a 32-bit VM with more than 4GB physical memory. There might be issues when converting to/from size_t and uint64_t that we don't handle properly. I suggest we should be more robust and have more control over transitions between potentially smaller types. 
> 
> Additionally, I've gone ahead and added comments which I think makes it easier to understand what's going on in this function. I've tried my best to leave the existing behavior unchanged, apart from type conversion.
> 
> Testing:
> * Oracle's tier1-8 on all Oracle supported platforms

This pull request has now been integrated.

Changeset: af2fbd5a
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af2fbd5a7182cabdd88764b5653d2ce666f05d70
Stats:     73 lines in 1 file changed: 18 ins; 6 del; 49 mod

8367413: Fix potential truncation error in Arguments::set_heap_size()

Reviewed-by: ayang, lkorinth

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

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

From sgehwolf at openjdk.org  Thu Oct  9 08:37:16 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Oct 2025 08:37:16 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

@MBaesken Could I ask for your review as well, please? Asking you since you've touched the test in the past year as well. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3384753109

From mli at openjdk.org  Thu Oct  9 08:37:35 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 08:37:35 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v5]
In-Reply-To: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
Message-ID: <4fRM76zFQ7o3zDqVZ__J485lsG-QMB0S8kS5_qZD-CQ=.e2e2ca49-73e8-4fb1-9bfd-5a916518a8a2@github.com>

> Hi,
> Can you help to review the patch?
> 
> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
> 
> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
> 
> Thanks!

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  revert name from non_ext_xxx

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27562/files
  - new: https://git.openjdk.org/jdk/pull/27562/files/92d1bb5e..f2cc974e

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

  Stats: 38 lines in 6 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/27562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27562/head:pull/27562

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

From mli at openjdk.org  Thu Oct  9 08:37:36 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 08:37:36 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <2kflAS5_PEsIE-83SwwD6Jgd5NSQ5MjWH-rvUucI7FA=.26670029-8b92-41f7-b739-1daff6cad0da@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
 <MSBpil5SJHsM4Gt9tYAlLzrzfOifYrrE5pKWsZzuICI=.a82a1cf8-c077-443b-a4da-82abcc074220@github.com>
 <2kflAS5_PEsIE-83SwwD6Jgd5NSQ5MjWH-rvUucI7FA=.26670029-8b92-41f7-b739-1daff6cad0da@github.com>
Message-ID: <eYoJYgXHbCiSckPgU075FN3OwaEPk5beBBCDMpTKqH0=.b4d2bf70-c90d-4a09-98f5-4d9533e62e8a@github.com>

On Thu, 9 Oct 2025 08:07:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li : Can we remove the `non_ext_` name prefix for non-extension features and maybe the `enabled()` check as well as we previously discussed?
>
> Sure, seems the prefix does not help reading the code.

> It doesn't seem to be necessary to have a enabled() check for non-extension features like zicboz_block_size, mvendorid, etc. So we might want to remove this check and give these features a default value (maybe -1 as suggested by @Hamlin-Li).

I can refactor this in another pr. In this one, I'll just focus on 2 simple things: reorder, and move comments close to feature declaration.
Same as the consistent interface of VM_Version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2415984981

From mli at openjdk.org  Thu Oct  9 08:37:37 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 08:37:37 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <eYoJYgXHbCiSckPgU075FN3OwaEPk5beBBCDMpTKqH0=.b4d2bf70-c90d-4a09-98f5-4d9533e62e8a@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <FWuAo42nXSqNLWTrcpXz40bseIaAl0npZbeaQXnQjRU=.69d5caed-a601-4536-b637-f6676628d24b@github.com>
 <JA-4ZmOSrl1DaNLSE4d7LQWiHmYKsgVQqWY4Jamy2Cc=.e793da0a-e6fe-4dca-9346-27de6b1eee56@github.com>
 <d5HaXNsxT6Cb-jmr0I-rPvmkYvcJLYp2nHxQIOz7UOM=.6bd1135d-23b8-4c4c-ba43-2c503a8f2612@github.com>
 <Hg0bVD0tKdqDntW2wazAYn4y6Qb94CFPLJCP1TfZSGo=.2f72e814-7aeb-4f84-b6b5-fb87fe937e0d@github.com>
 <6nP9SMa1v3HFzFdZGfvDF9uVRf9pI2a5JLx7ZZ7w4ZA=.f0a18123-27cc-49af-a321-b4ce5ec21633@github.com>
 <MSBpil5SJHsM4Gt9tYAlLzrzfOifYrrE5pKWsZzuICI=.a82a1cf8-c077-443b-a4da-82abcc074220@github.com>
 <2kflAS5_PEsIE-83SwwD6Jgd5NSQ5MjWH-rvUucI7FA=.26670029-8b92-41f7-b739-1daff6cad0da@github.com>
 <eYoJYgXHbCiSckPgU075FN3OwaEPk5beBBCDMpTKqH0=.b4d2bf70-c90d-4a09-98f5-4d9533e62e8a@github.com>
Message-ID: <qsCkTGHMOAbEIKJs5gQhk0dHA6lf8Vfp2yROxC2UaMk=.30a9e37c-772f-41e2-889e-8a7fa6022388@github.com>

On Thu, 9 Oct 2025 08:31:35 GMT, Hamlin Li <mli at openjdk.org> wrote:

> It doesn't seem to be necessary to have a enabled() check for non-extension features like zicboz_block_size, mvendorid, etc. So we might want to remove this check and give these features a default value (maybe -1 as suggested by @Hamlin-Li).

I can refactor this in another pr. In this one, I'll just focus on 2 simple things: reorder, and move comments close to feature declaration.
Same as the consistent interface of VM_Version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2415989071

From mdoerr at openjdk.org  Thu Oct  9 08:38:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Oct 2025 08:38:30 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
Message-ID: <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>

On Wed, 8 Oct 2025 14:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for riscv
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Thanks for the ping! PPC64 implementation:
> 
> diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> index 7431f77aeff..373dc24a62f 100644
> --- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> +++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> @@ -2179,17 +2179,11 @@ void TemplateTable::_return(TosState state) {
>  //   - Rscratch
>  void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rcache, Register Rscratch) {
>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
> +
>    Label Lresolved, Ldone, L_clinit_barrier_slow;
>    Register Rindex = Rscratch;
>  
>    Bytecodes::Code code = bytecode();
> -  switch (code) {
> -    case Bytecodes::_nofast_getfield: code = Bytecodes::_getfield; break;
> -    case Bytecodes::_nofast_putfield: code = Bytecodes::_putfield; break;
> -    default:
> -      break;
> -  }
> -
>    const int bytecode_offset = (byte_no == f1_byte) ? in_bytes(ResolvedMethodEntry::bytecode1_offset())
>                                                     : in_bytes(ResolvedMethodEntry::bytecode2_offset());
>    __ load_method_entry(Rcache, Rindex);
> @@ -2201,10 +2195,9 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>  
>    // Class initialization barrier slow path lands here as well.
>    __ bind(L_clinit_barrier_slow);
> -
>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>    __ li(R4_ARG2, code);
> -  __ call_VM(noreg, entry, R4_ARG2, true);
> +  __ call_VM(noreg, entry, R4_ARG2);
>  
>    // Update registers with resolved info.
>    __ load_method_entry(Rcache, Rindex);
> @@ -2226,12 +2219,10 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>    __ bind(Ldone);
>  }
>  
> -void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
> -                                            Register Rcache,
> -                                            Register index) {
> +void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcache, Register index) {
>    assert_different_registers(Rcache, index);
>  
> -  Label resolved;
> +  Label Lresolved, Ldone, L_clinit_barrier_slow;
>  
>    Bytecodes::Code code = bytecode();
>    switch (code) {
> @@ -2246,19 +2237,34 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>                                           : in_bytes(ResolvedFieldEntry::put_code_offset());
>    __ lbz(R0, code_offset, Rcache);
>    __ cmpwi(CR0, R0, (int)code); // have we resolved th...

> @TheRealMDoerr with your patch `isync` is bypassed after `InterpreterRuntime::resolve_from_cache` call. Is it intentional?

Thanks for pointing this out. It is ok because the same thread has performed the resolution. So, no need for a memory barrier in this case because we didn't read values written by another thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3384753480

From kbarrett at openjdk.org  Thu Oct  9 08:40:32 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 08:40:32 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>
Message-ID: <W9GSUFyS3jp9I3nMSOOtzUGAdhrdYixTqSa0ticwJBs=.0a3cbc0e-3ee0-4538-af6e-8927c5c5e691@github.com>

On Wed, 8 Oct 2025 13:23:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/tuple.hpp line 2:
>> 
>>> 1: /*
>>> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> So we have our own tuple ...
>
> We have our own baby partial tuple. What's there is more like a heterogeneous
> array with compile-time indexing. It's used for one thing, and provides just
> enough functionality for that use. I'm not entirely convinced it's the right
> tool for the job, though I haven't taken the time to work out alternatives.

I looked at the use of Tuple<...>. I think using named structs with named
members would be an improvement. Eliminates questions like is src element 0
and dst element 1, or is it the other way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416001474

From shade at openjdk.org  Thu Oct  9 08:41:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 08:41:46 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v6]
In-Reply-To: <4TSsGtXYZV6_pKLIEvaEXQx8wLyVNjMzkm3FHUo1l4A=.c5ca9788-6837-4318-9631-b90c8204b5df@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <vLTj-xe64R-2QRySitLlf3AE7997fMgYHjCnH8wFWD4=.9cfeb090-1fc8-42c2-8703-9eb8083b2e35@github.com>
 <obe-XcZrE6Z-oEIiHH2u8Qa2B-fWd3vxmsYdG_tRisU=.7fe33592-fa1c-46c0-950d-0ff9a23477e5@github.com>
 <MHrZoyWiKnmNNKuufHj5w8EdCsBYASMVdKtN24UlxVI=.0af680e4-bd65-4409-91af-a3dcbe6ef384@github.com>
 <4TSsGtXYZV6_pKLIEvaEXQx8wLyVNjMzkm3FHUo1l4A=.c5ca9788-6837-4318-9631-b90c8204b5df@github.com>
Message-ID: <kLCnF2vWz2rI5PDQWwuIORUlaM5FxIF-uiPSXEw_KSg=.1c09bb0f-ba2d-44b3-bb5b-087e5e0d129c@github.com>

On Thu, 9 Oct 2025 04:40:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I reasoned it is way too noisy to be useful even for debugging. 
>> 
>> Note this is `thread_not_running()` checker, which is called from two places in `SafepointSynchronize::synchronize_threads`: initial filtering and on-going checks for state changes. In well-behaved applications most of the threads are actually not running, blocked somewhere in idle thread pool. So prnting this from the initial filtering dumps info on potentially thousands of threads we do not care about 99.9% of the time.
>> 
>> I argued to myself that what we really care about are the threads that are _transiting_ from runnable to blocked. So the new `log_trace(safepoint)` statements are in caller code that uses this `thread_not_running()` checker, and is able to print exactly what they see. "thread is now blocked", for example.
>> 
>> I don't think there are useful bits in `TSS`, really. We can amend trace logs to pull some of that, if you want. Look what it prints in current mainline:
>> 
>> 
>> [792737314ns] Thread: 0x0000785db85bf4c0  [0x214944] State: _running _at_poll_safepoint 0
>> [792737594ns]    JavaThread state: _thread_in_Java
>> [792738025ns] Thread: 0x0000785db85c08e0  [0x214945] State: _running _at_poll_safepoint 1
>> [792738246ns]    JavaThread state: _thread_in_vm
>
> I thought it was intended to report which threads still running - i.e. are not reaching the safepoint.

Yes, I think so. This PR moves the logging in the code that _calls_ `thread_not_running()`, so that it give us a more useful messages on what we expected to see: still running, now blocked, etc. So it is only half  removed: it gets pulled to callers that we care about.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27673#discussion_r2416000769

From shade at openjdk.org  Thu Oct  9 08:44:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 08:44:14 GMT
Subject: RFR: 8369442: ExitOnOutOfMemoryError should exit more gracefully
Message-ID: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>

See RFE for more discussion. It seems we have a leeway in defining what "exit" means for `-XX:+ExitOnOutOfMemoryError`, and this PR does it more akin to `JVM_Halt`, rather than abrupt `os::_exit`. This gives VM a chance to shutdown some of its subsystems gracefully.

Comments welcome!

Additional testing:
 - [x] Linux x86_64 server fastdebug, `tier1`
 - [ ] Linux x86_64 server fastdebug, `all`

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Thu Oct  9 08:55:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 08:55:44 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v7]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Do not bother changing the existing logging wording for "initiated"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/945d612a..cccd8a32

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

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

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

From dzhang at openjdk.org  Thu Oct  9 09:04:35 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 9 Oct 2025 09:04:35 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v3]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang 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 three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
 - Add supports_misaligned_vector_accesses
 - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/a36d5f8f..f22e9493

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

  Stats: 15635 lines in 616 files changed: 9174 ins; 3163 del; 3298 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

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

From dzhang at openjdk.org  Thu Oct  9 09:04:37 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 9 Oct 2025 09:04:37 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v2]
In-Reply-To: <g3TfjC6tkceZHPvPJYdY9v-g6BnPuvjN_ylT6khDPIs=.1b671290-aaa7-44c8-b194-eeef99154949@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <g3TfjC6tkceZHPvPJYdY9v-g6BnPuvjN_ylT6khDPIs=.1b671290-aaa7-44c8-b194-eeef99154949@github.com>
Message-ID: <hfKsYRFLEaXGDvaKw3hbNcIXB75QZWnlvz5SlcOmDFY=.faad6a62-7d75-4056-90b0-a30c80867d7e@github.com>

On Tue, 30 Sep 2025 03:01:10 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch? Thanks!
>> 
>> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
>> 
>> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
>> 
>> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
>> 
>> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
>> 
>> We can check the status of EnableVectorSupport as follows:
>> 
>> On k1
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [0.737s][info][compilation] EnableVectorSupport=false
>> [0.738s][info][compilation] EnableVectorReboxing=false
>> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
>> 
>> On qemu
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [3.048s][info][compilation] EnableVectorSupport=true
>> [3.050s][info][compilation] EnableVectorReboxing=true
>> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
>> 
>> 
>> ### Test (fastdebug)
>> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1
>
> Dingli Zhang 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 one additional commit since the last revision:
> 
>   8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

> I'm not quite sure, but seems this is not an issue only on riscv? It might be better to get more attention from other developers working on other platforms, could you modify the subject of this bug/pr? Sorry for previous suggestion to change the subject name.

Hi, @Hamlin-Li  Sorry for the late reply. I have modified this check following the suggestion of @iwanowww.


> BTW, I see more tests using jdk.incubator.vector besides of tests under test/hotspot/jtreg/compiler/vectorapi, like this test. Could they also face the similar issue?

I don't think they will have similar issues. If they do IR test on places where jdk.incubator.vector is used,
it would be caught by my local tier1-tier3 tests on linux-riscv64 RVV platform with fastdebug build.

> `AlignVector` doesn't look appropriate here (and in other places). If hardware doesn't support misaligned vector accesses, then there shouldn't be a way to set `AlignVector = false`. The JVM should issue a warning and unconditionally set both `EnableVectorSupport = false` and `AlignVector = true` irrespective of what is specified on the command line.

Hi @iwanowww  Make sense. I have added checking for that in my latest commit. Please take another look.

> Also, the problem is not specific to C2. There are vectorized VM stubs which can be affected by absence of hardware misaligned vector access support.
>
> I suggest to introduce a cross-platform `VM_Version::supports_misaligned_vector_accesses()` which affects `AlignVector`, `EnableVectorSupport`, `AvoidUnalignedAccesses` (maybe even supersedes it?), and eventually all usages of vector memory accesses in VM code.
>

Good suggestion. I have modified accordingly.
At the RISC-V Linux kernel level, there is a distinguishment for support for misaligned vector and scalar access.
Check the hwprobe linux syscall (`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` vs `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`) [1].
We set `AlignVector` and `EnableVectorSupport` to `true` and `false` respectively if we don't have fast misaligned vector access.
And we set `AvoidUnalignedAccesses` and `UseUnalignedAccesses` to `true` and `false` respectively if we don't have fast misaligned scalar access.

[1] https://docs.kernel.org/arch/riscv/hwprobe.html

> Speaking of aligned/misaligned vector accesses, does RISC-V distinguish them on ISA level (with different instructions)? If that's the case, then it makes sense to add asserts in corresponding Assembler/MacroAssembler methods.

No. There is not such a distinguish from the RISC-V Vector Spec.

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

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3384847342
PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3384857124

From shade at openjdk.org  Thu Oct  9 09:05:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 09:05:58 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v7]
In-Reply-To: <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
Message-ID: <ipOil8rvm0s0WMJ_g3O_3-8yIQ6fh2oJ8DR2CE8cTGc=.2ce7d792-f7b7-4cfd-a40a-79b245407829@github.com>

On Thu, 9 Oct 2025 08:55:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not bother changing the existing logging wording for "initiated"

Hey @robehn -- you improved/used this kind of logging the last time. How does it this PR look to you?

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3384878502

From stefank at openjdk.org  Thu Oct  9 09:15:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Oct 2025 09:15:33 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <4uDJA25Pz-Sxiy9kAtbOnUDSqe9h7b47d5AFYDv_ipQ=.e7d5060f-5261-4d77-8a9c-bfb75cdbbea8@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3317964481

From mgronlun at openjdk.org  Thu Oct  9 09:28:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Oct 2025 09:28:08 GMT
Subject: RFR: 8369467: Rdtsc: Avoid initialize_elapsed_counter when
 UseFastUnorderedTimeStamps will be disabled
In-Reply-To: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
Message-ID: <Qf1WtfFHsQmMPN8B1aeYimhum-buH3sHUrObxBtyPeI=.beb60293-05ca-49e5-a3e6-50394a1739fa@github.com>

On Thu, 9 Oct 2025 06:31:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
> 
> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.

Hi Axel,

The else branch for VM_Version::supports_tscinv_ext(), i.e., the do_time_measurements() loop, is unreliable and should be removed. 

Rdtsc should only be used when INV_TSC is reported by the HW.

Can you remove that piece, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/27713#issuecomment-3384966128

From mgronlun at openjdk.org  Thu Oct  9 09:29:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Oct 2025 09:29:58 GMT
Subject: RFR: 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version
 stub area
In-Reply-To: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
References: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
Message-ID: <VVoiMcqqca68XM5pI0UZAp9xxND_vd8BQpzSP-9kXUM=.0f31f20f-e878-419a-8982-8aba44cc76ca@github.com>

On Thu, 9 Oct 2025 05:59:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently these stubs are created in `Rdtsc::initialize` which may be called from the first ElapsedCounter now call. This causes problems with lock ranks as we may be holding a lock while taking time, because we need to lock the code cache to create a stub.
> 
> I suggest we move the `getCPUIDBrandString_stub` next to the other `VM_Version` stubs and generate them together. This is done at the earliest point we can, right after the CodeCache system has been initialized.

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27711#pullrequestreview-3318017979

From mgronlun at openjdk.org  Thu Oct  9 09:31:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Oct 2025 09:31:49 GMT
Subject: RFR: 8369466: Rdtsc: Adapt do_time_measurements to allow for
 non-JavaThreads
In-Reply-To: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
References: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
Message-ID: <cguz-o5W1-ZDAwGNyjLjrvsNj1OtWQkW5m92k90DyHo=.d3efa388-bb42-41f3-b899-e9cb4a1cc08a@github.com>

On Thu, 9 Oct 2025 05:59:23 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently `Rdtsc::initialize` may be called from the first ElapsedCounter now call. Currently this happens at different points during bootstrapping depending on what subsystem is active like JFR, which GC etc.
> 
> The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.
> 
> It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.
> 
> Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.

Remove do_time_measurements(), please. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27710#issuecomment-3384977173

From dbriemann at openjdk.org  Thu Oct  9 09:36:20 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Thu, 9 Oct 2025 09:36:20 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v5]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <e2fMPl8UA6nzZfIPkY13G4FoAIzX3qLJBZtGT5qSGzU=.73610b68-4966-4a81-9c22-338da9860962@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  beautify add_then_fetch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/a1252228..9aa64ff9

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

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

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

From aboldtch at openjdk.org  Thu Oct  9 10:06:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 10:06:03 GMT
Subject: RFR: 8369467: Rdtsc: Avoid initialize_elapsed_counter when
 UseFastUnorderedTimeStamps will be disabled
In-Reply-To: <Qf1WtfFHsQmMPN8B1aeYimhum-buH3sHUrObxBtyPeI=.beb60293-05ca-49e5-a3e6-50394a1739fa@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <Qf1WtfFHsQmMPN8B1aeYimhum-buH3sHUrObxBtyPeI=.beb60293-05ca-49e5-a3e6-50394a1739fa@github.com>
Message-ID: <1G6QVEhVgPOB6d7TH8r9I0M5wG8ol9D_-jh7FbHDz4w=.e6684fd7-67d7-4fd1-9e7f-fe3dc1482211@github.com>

On Thu, 9 Oct 2025 09:25:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Hi Axel,
> 
> The else branch for VM_Version::supports_tscinv_ext(), i.e., the do_time_measurements() loop, is unreliable and should be removed.
> 
> Rdtsc should only be used when INV_TSC is reported by the HW.
> 
> Can you remove that piece, please?

That would be even better. It was my suggestion / question in #27710:
> Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.

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

PR Comment: https://git.openjdk.org/jdk/pull/27713#issuecomment-3385117563

From duke at openjdk.org  Thu Oct  9 11:08:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 9 Oct 2025 11:08:04 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <oXzhqZKUqdw8fRdoRBOAZ74YGC2pZ0SX7UgqaPGz94g=.10b90d7e-ff79-42fc-9f89-b6a77f8f0490@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Thanks all for your suggestions. I have updated the CSR to align with the discussion in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3385342335

From fweimer at openjdk.org  Thu Oct  9 11:30:19 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Thu, 9 Oct 2025 11:30:19 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

doc/hotspot-style.md line 567:

> 565: 
> 566: Functions that may throw exceptions must not be used.  This is in accordance
> 567: with the HotSpot policy of [not using exceptions](#error-handling).

In the GCC implementation, destructor registration may throw `__gnu_cxx::recursive_init_error` (via the `__cxa_guard_acquire` Itanium ABI function). Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416467456

From rehn at openjdk.org  Thu Oct  9 11:30:27 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Oct 2025 11:30:27 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v7]
In-Reply-To: <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
Message-ID: <z_-jm0fSJDgBpnGCObz9_6UQfRgS9pAOp2pnJoRUEG4=.3f84d5a1-df8c-4915-b1b2-3af0b6e3c4f5@github.com>

On Thu, 9 Oct 2025 08:55:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not bother changing the existing logging wording for "initiated"

Marked as reviewed by rehn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27673#pullrequestreview-3318501678

From rehn at openjdk.org  Thu Oct  9 11:30:29 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Oct 2025 11:30:29 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v7]
In-Reply-To: <ipOil8rvm0s0WMJ_g3O_3-8yIQ6fh2oJ8DR2CE8cTGc=.2ce7d792-f7b7-4cfd-a40a-79b245407829@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
 <ipOil8rvm0s0WMJ_g3O_3-8yIQ6fh2oJ8DR2CE8cTGc=.2ce7d792-f7b7-4cfd-a40a-79b245407829@github.com>
Message-ID: <CMMAculIFEU8TwFl8TmrLDyx2DaWnyPwvkkqRlh8Qm0=.57f50a20-d075-4d4c-9ba4-62bef0667ea8@github.com>

On Thu, 9 Oct 2025 09:03:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Hey @robehn -- you improved/used this kind of logging the last time. How does it this PR look to you?

Yea, I get what you are doing, it looks good.

But two comments, a bit OT:
1: As you have located the interesting sections, it would be nice if we could make use of them as general trace points.
   Meaning it would be nice if e.g. JFR could share these locations.
2: We log threads a bit different, it would be nice if there was thread formatter, so all threads comes out identically.
  And for a real user TID (threads PID in linux) is the identifier which is useful, as you can e.g. attach perf to that tid/pid.
  The logging of pointers to Thread is only useful to seperate them.

Hence please log TID (linux thread pid), so one can do perf record --pid "TID" or nice or what you need.
Now if that should be done in a completely different PR, maybe addressing 2 or here I'm unsure of, so I'll approve as is and let you guys think about it or ignore :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3385419548

From aboldtch at openjdk.org  Thu Oct  9 11:40:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 11:40:02 GMT
Subject: RFR: 8369467: Rdtsc: Avoid initialize_elapsed_counter when
 UseFastUnorderedTimeStamps will be disabled [v2]
In-Reply-To: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
Message-ID: <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>

> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
> 
> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Rdtsc: Remove experimental support for non invariant tsc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27713/files
  - new: https://git.openjdk.org/jdk/pull/27713/files/64299f8c..203e865e

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

  Stats: 114 lines in 2 files changed: 3 ins; 96 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27713/head:pull/27713

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

From aboldtch at openjdk.org  Thu Oct  9 11:44:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 11:44:05 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v2]
In-Reply-To: <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
Message-ID: <l3CCCXi0PIg0p7Ej9f0uT8qs9WVpcAJlF-zbW4VkbIA=.1a351a01-95b2-482d-81c1-e10c12d499b2@github.com>

On Thu, 9 Oct 2025 11:40:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
>> 
>> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rdtsc: Remove experimental support for non invariant tsc

Pushed a patch which removes the ability for `UseFastUnorderedTimeStamps` to override disabling rdtsc when it is not invariant.

However there is now a small mismatch with what the flag says it does vs what it can do. 
The only thing it now can do is disable rdtsc on systems with invariant tsc. It might be that we should remove this flag and introduce a new one where the behaviour of disabling rdtsc is more obvious. 

But not sure what we would prefer to do here w.r.t. the advance VM option `UseFastUnorderedTimeStamps`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27713#issuecomment-3385481907

From aboldtch at openjdk.org  Thu Oct  9 11:46:21 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 11:46:21 GMT
Subject: RFR: 8369466: Rdtsc: Adapt do_time_measurements to allow for
 non-JavaThreads
In-Reply-To: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
References: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
Message-ID: <vB_HAXF7qZ-DFSi-IgFHdhfZAOqTe7njOWTrJQgjnEs=.e0833244-e5a1-43f9-8a68-99cf55362c3d@github.com>

On Thu, 9 Oct 2025 05:59:23 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently `Rdtsc::initialize` may be called from the first ElapsedCounter now call. Currently this happens at different points during bootstrapping depending on what subsystem is active like JFR, which GC etc.
> 
> The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.
> 
> It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.
> 
> Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.

Closing this after discussion in #27713 where we decided to remove this feature altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/27710#issuecomment-3385489173

From aboldtch at openjdk.org  Thu Oct  9 11:46:22 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 9 Oct 2025 11:46:22 GMT
Subject: Withdrawn: 8369466: Rdtsc: Adapt do_time_measurements to allow for
 non-JavaThreads
In-Reply-To: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
References: <PDicStezzAhWceZ2ulbhaekzeMgI9vKeliaxx3UpYIA=.f2737276-bd96-4a56-b3d6-ad56dfce7c5e@github.com>
Message-ID: <SgETE1BpkViANsmEVSkARIbavUGOcMpHg1iIJn5qryM=.80d58a05-257c-40a0-9ef0-f693564c6946@github.com>

On Thu, 9 Oct 2025 05:59:23 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently `Rdtsc::initialize` may be called from the first ElapsedCounter now call. Currently this happens at different points during bootstrapping depending on what subsystem is active like JFR, which GC etc.
> 
> The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.
> 
> It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.
> 
> Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Thu Oct  9 12:02:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 9 Oct 2025 12:02:22 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>
Message-ID: <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>

On Thu, 9 Oct 2025 08:34:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> @MBaesken Could I ask for your review as well, please? Asking you since you've touched the test in the past year as well. Thanks!


I put it into our build/test queue to see what happens.
The change looks okay to me , but you probably have to adjust the COPYRIGHT year info of the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3385542432

From mgronlun at openjdk.org  Thu Oct  9 12:08:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Oct 2025 12:08:10 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v2]
In-Reply-To: <l3CCCXi0PIg0p7Ej9f0uT8qs9WVpcAJlF-zbW4VkbIA=.1a351a01-95b2-482d-81c1-e10c12d499b2@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
 <l3CCCXi0PIg0p7Ej9f0uT8qs9WVpcAJlF-zbW4VkbIA=.1a351a01-95b2-482d-81c1-e10c12d499b2@github.com>
Message-ID: <WFvrpv7wPrzBGofNYfKaWJNV9l9qTA0g4oiaAK2GIBU=.e21f89be-297f-4d42-b547-99a3e9df6fc7@github.com>

On Thu, 9 Oct 2025 11:41:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Pushed a patch which removes the ability for `UseFastUnorderedTimeStamps` to override disabling rdtsc when it is not invariant.
> 
> However there is now a small mismatch with what the flag says it does vs what it can do. The only thing it now can do is disable rdtsc on systems with invariant tsc. It might be that we should remove this flag and introduce a new one where the behaviour of disabling rdtsc is more obvious.
> 
> But not sure what we would prefer to do here w.r.t. the advance VM option `UseFastUnorderedTimeStamps`.

The UseFastUnorderedTimeStamps is EXPERIMENTAL with the following description:

"Use platform unstable time where supported for timestamps only"

The "where supported" conditional allows us to make this change. I prefer to see it only as an opt-out flag, as rdtsc is not to be relied on directly. Also, the only user of rdtsc is, or at least has been and should be, JFR. We have talked about introducing a JFR-specific flag for this support. You can leave that concern for now; we can take on the deprecation when we decide on the JFR-specific solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/27713#issuecomment-3385553122

From sgehwolf at openjdk.org  Thu Oct  9 12:08:07 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Oct 2025 12:08:07 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>
 <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>
Message-ID: <Mj2J1utvYblxpkjIXAuAFq9vkszBB8l6Q8U6pj0dJpM=.6011f284-920e-4954-acfb-9ec58dff95d2@github.com>

On Thu, 9 Oct 2025 11:59:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I put it into our build/test queue to see what happens.

Unless you manually run them, you won't see a difference as both are in the [ProblemList](https://github.com/openjdk/jdk/blob/7e3e55a576b24ae704395b01a15c363ce6e28cae/test/hotspot/jtreg/ProblemList.txt#L127-L128). I still run them regularly and don't see the problems as described in the problem-listed bugs since they cover important cases when changes are being done in the container area.

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3385563563

From mgronlun at openjdk.org  Thu Oct  9 12:08:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Oct 2025 12:08:08 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v2]
In-Reply-To: <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
Message-ID: <Mp30Yme9p5jqH7pFeonh6Vq2rKdzMCR7IU38MtPIfYQ=.57548513-0a9e-44c2-92de-ce0ee10e0cda@github.com>

On Thu, 9 Oct 2025 11:40:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
>> 
>> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rdtsc: Remove experimental support for non invariant tsc

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27713#pullrequestreview-3318641269

From mbaesken at openjdk.org  Thu Oct  9 12:13:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 9 Oct 2025 12:13:15 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <A-Vo_-Hxtw7mo_l3EXiwX5gwqphGyOxbwDEa-LSp9xE=.15059056-2d24-4304-817b-dd6dffb109b1@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27699#pullrequestreview-3318651669

From sgehwolf at openjdk.org  Thu Oct  9 12:13:17 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Oct 2025 12:13:17 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>
 <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>
Message-ID: <RI3LBUyncnr0s0vadXS97T3uTZK8sgv8pYHak4bs-Sk=.6637ccc6-27fc-4b89-be7e-39e391ac19a2@github.com>

On Thu, 9 Oct 2025 11:59:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The change looks okay to me , but you probably have to adjust the COPYRIGHT year info of the tests.

Thanks, I'll update the years.

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3385582710

From shade at openjdk.org  Thu Oct  9 12:18:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 12:18:23 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v8]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <91Im78zN5OoJFw0FulCEH0gU6cmEd5ky4HxvNuaS8Eg=.fc2e8e77-de29-42ad-a290-228b867f1bc9@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev 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 10 additional commits since the last revision:

 - Thread PIDs in logs
 - Merge branch 'master' into JDK-8369283-safepoint-logs
 - Do not bother changing the existing logging wording for "initiated"
 - Put polling exception tracing back with minor reformat
 - Touchups
 - A bit more verbose
 - Rethink safepoint sync logging
 - Update src/hotspot/share/runtime/safepoint.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Cannot allocate for Thread::name + adjust debug levels
 - Work

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/cccd8a32..80ec06a3

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

  Stats: 5929 lines in 148 files changed: 4393 ins; 839 del; 697 mod
  Patch: https://git.openjdk.org/jdk/pull/27673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27673/head:pull/27673

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

From shade at openjdk.org  Thu Oct  9 12:18:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 12:18:24 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v7]
In-Reply-To: <CMMAculIFEU8TwFl8TmrLDyx2DaWnyPwvkkqRlh8Qm0=.57f50a20-d075-4d4c-9ba4-62bef0667ea8@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <PwcxTVOKqMAdA-Dff96bWd-MwDiQKmvV-_zEFlbuVLs=.caf4754f-5f2e-407c-b80d-a8dcfbb1cbdd@github.com>
 <ipOil8rvm0s0WMJ_g3O_3-8yIQ6fh2oJ8DR2CE8cTGc=.2ce7d792-f7b7-4cfd-a40a-79b245407829@github.com>
 <CMMAculIFEU8TwFl8TmrLDyx2DaWnyPwvkkqRlh8Qm0=.57f50a20-d075-4d4c-9ba4-62bef0667ea8@github.com>
Message-ID: <3c38vCcMgXsg9LFvXbKdgTSxXJcRetHEUQzBAZz46sA=.4d4b4aff-71fe-486e-a613-7762db848758@github.com>

On Thu, 9 Oct 2025 11:27:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hence please log TID (linux thread pid), so one can do perf record --pid "TID" or nice or what you need.

Right! In the initial version of the patch, I printed thread names as external identifiers. Then I realized you cannot touch the names, because they can allocate, so I removed that part. But that also loses any external ident for threads. I now pushed the commit that prints the thread TIDs. Updated log snippet here: https://github.com/openjdk/jdk/pull/27673#issuecomment-3376730861

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3385590821

From kbarrett at openjdk.org  Thu Oct  9 12:18:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 12:18:38 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
 <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
Message-ID: <6u0Ia6A2xQnv51Ti0Jchg6rnncfRRvtK5oGS963CeIA=.bc9c1481-60ad-443d-923b-dc86277dbb14@github.com>

On Thu, 9 Oct 2025 11:27:26 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - jrose comments
>>  - move tuple to undecided category
>
> doc/hotspot-style.md line 567:
> 
>> 565: 
>> 566: Functions that may throw exceptions must not be used.  This is in accordance
>> 567: with the HotSpot policy of [not using exceptions](#error-handling).
> 
> In the GCC implementation, destructor registration may throw `__gnu_cxx::recursive_init_error` (via the `__cxa_guard_acquire` Itanium ABI function). Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

We (you and me, @fweimer-rh) discussed this a couple of years ago:
https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/082324.html

Quoting from here:
https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/083142.html

"
Empirically, a recursive initialization attempt doesn't make any attempt to
throw. Rather, it blocks forever waiting for a futex signal from a thread that
succeeds in the initialization. Which of course will never come.

And that makes sense, now that I've looked at the code.

In __cxa_guard_acquire, with _GLIBCXX_USE_FUTEX, if the guard indicates
initialization hasn't yet been completed, then it goes into a while loop.
This while loop tries to claim initialization.  Failing that, it checks
whether initialization is complete.  Failing that, it does a SYS_futex
syscall, waiting for some other thread to perform the initialization.  There's
nothing there to check for recursion.

throw_recursive_init_exception is only called if single-threaded (either by
configuration or at runtime).
"

It doesn't look like there have been any relevant changes in that area since
then. So I think there is still not a problem here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416593903

From cnorrbin at openjdk.org  Thu Oct  9 13:03:18 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Oct 2025 13:03:18 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
Message-ID: <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>

On Thu, 9 Oct 2025 02:45:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>Ignoring the name for now, I think having three sets of methods is confusing - how will anyone know whether they should be using `os::free_memory` or `os::machine_free_memory`? The former says nothing about containers.
>
>IIUC the problem you are trying to resolve is that some existing `os::xxx` return values that account for containers and you would like to know the non-container limits. Does that happen often enough that we need 3 complete sets of API method's, or can we augment the problematic methods with a default parameter `bool ignoreContainers = false` so you can ask for the non-container version?

The goal isn't just to expose some os values when we happen to be running in a container, it's to make both numbers, the OS view and the cgroup limit accessible at the same time. Each has its own use-cases, and a single method with a default `bool ignoreContainers = ` doesn't really solve that.

To me it seems that the issue is really about clarity and confusion. While having 3 sets of APIs could be a lot, it is needed if we want to keep current behaviour and still allow access to the values separately. A solution to help with clarity could be:

os::free_memory() -> Default combined value for those that don't care where the value originated.
os::Machine::free_memory() - > For those that want the machine/os value.
os::Container::free_memory() -> For those that want the container value.
``` 
This separates the APIs into different classes, and each class could have accompanied text to explain its use. This makes the top level `os::free_memory()` the obvious default to use for most use cases that don't care if we are running in a container or not, while allowing container aware code that does care to get a more detailed view for the container view and machine view specifically.

>By the way it keeps getting mentioned that only Linux has container support, but we have started augmenting some of the Windows `os::xxx` functions to account for Windows Jobs (which can restrict available resources similarly to containers).

Currently, our container logic is linked to the Linux cgroup model, so when the code asks "am I in a container?" it really means "am I running under cgroups?". With the API split I'm proposing, that tight coupling disappears. cgroup support would simply be one of the platform-specific implementations of `Container::`, not the definition of a container.  That would make it easier to expand on Windows Job Objects (or any other resource-constraining framework) later on.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3385762961

From roland at openjdk.org  Thu Oct  9 13:25:27 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 9 Oct 2025 13:25:27 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal
Message-ID: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>

This change refactor code that's similar for LShiftINode and
LShiftLNode into shared methods. I also added extra test cases to
cover all transformations.

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

Commit messages:
 - more
 - more
 - more
 - more
 - more
 - fix

Changes: https://git.openjdk.org/jdk/pull/27725/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369167
  Stats: 625 lines in 6 files changed: 368 ins; 170 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/27725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27725/head:pull/27725

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

From jcking at openjdk.org  Thu Oct  9 13:33:02 2025
From: jcking at openjdk.org (Justin King)
Date: Thu, 9 Oct 2025 13:33:02 GMT
Subject: Integrated: 8369190: JavaFrameAnchor on AArch64 has unnecessary
 barriers and wrong store order in MacroAssembler
In-Reply-To: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
References: <Gbq1pTykRzakb5QKMB8qEpUlQ-5YmwTL7nsCxQ-17zM=.b927cb01-751f-4567-9ac1-f60199d549f0@github.com>
Message-ID: <T9TIpfl81itbAtYkQv8Yd5pJf3fF_sbz-6NhuePi_pE=.f6b33ec8-7149-4cfd-9724-b2b57682f29b@github.com>

On Mon, 6 Oct 2025 12:35:44 GMT, Justin King <jcking at openjdk.org> wrote:

> Remove unnecessary release barriers in `JavaFrameAnchor::{copy,clear}` and fix `MacroAssembler::set_last_Java_frame` to set `sp` last as expected by the profiler.

This pull request has now been integrated.

Changeset: fd296774
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd29677479797956e0d205b5ce6e7cb9ad407bd1
Stats:     18 lines in 2 files changed: 8 ins; 9 del; 1 mod

8369190: JavaFrameAnchor on AArch64 has unnecessary barriers and wrong store order in MacroAssembler

Reviewed-by: aph, dlong

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

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

From syan at openjdk.org  Thu Oct  9 13:36:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 13:36:02 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <0RXWsgk6JS8n0ZYFpLA2kzPOOvb0oRQJkcgMzl-bVtc=.f55772e6-2a43-4f7f-8c9f-0c6d2d99fbdf@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

The proposed patch works for me.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27699#pullrequestreview-3319007437

From shade at openjdk.org  Thu Oct  9 13:40:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 13:40:29 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v9]
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Missing include header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27673/files
  - new: https://git.openjdk.org/jdk/pull/27673/files/80ec06a3..fbb5686b

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

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

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

From kevinw at openjdk.org  Thu Oct  9 14:02:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Oct 2025 14:02:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Questions that this change brings up to me:

Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area?
If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

How do we make it easy for somebody to add useful features in the right place...

Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.

The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

The originally proposed JavaDoc had some HotSpot-specific terms in it, which maybe did not fit.  But they could still be valid if rephrased as a note of examples of the kinds of things that an implementation may need to do.

I'm wondering if the com.sun.management... interfaces made sense as a way to add features outside of an original JSR spec.  Maybe that was their intent.  But are we still in that world, do we still need to do that?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3386013198

From mdoerr at openjdk.org  Thu Oct  9 14:00:11 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Oct 2025 14:00:11 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v5]
In-Reply-To: <e2fMPl8UA6nzZfIPkY13G4FoAIzX3qLJBZtGT5qSGzU=.73610b68-4966-4a81-9c22-338da9860962@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <e2fMPl8UA6nzZfIPkY13G4FoAIzX3qLJBZtGT5qSGzU=.73610b68-4966-4a81-9c22-338da9860962@github.com>
Message-ID: <xZfRXrDiTRz8HncLxdInaV3T7-9oG3Qtag8zaTeafH0=.6782d935-ea43-4c5b-acb1-0453b922649f@github.com>

On Thu, 9 Oct 2025 09:36:20 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   beautify add_then_fetch

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 246:

> 244:   // the cmpxchg, so it's really a 'fence_cmpxchg_fence' if not
> 245:   // specified otherwise (see atomicAccess.hpp).
> 246: 

I found one more issue: AIX correctly used `const unsigned int masked_compare_val = ((unsigned int)(unsigned char)compare_value)`. Linux (since [JDK-8331859](https://bugs.openjdk.org/browse/JDK-8331859)) and this new implementation misses the cast to unsigned. So, cmpxchg will always fail when `compare_val` is negative because the load instructions use zero extend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2416880657

From fbredberg at openjdk.org  Thu Oct  9 14:06:54 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 9 Oct 2025 14:06:54 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v9]
In-Reply-To: <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
Message-ID: <D4o0s2_JamoDm0YjdlTrApUGtVSAAFn-_avPHejhA6I=.0a6edb63-1f40-48ed-81dd-f47482d1369d@github.com>

On Thu, 9 Oct 2025 13:40:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing include header

Looks good to me.

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

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27673#pullrequestreview-3319161634

From cstein at openjdk.org  Thu Oct  9 14:22:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 9 Oct 2025 14:22:44 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
Message-ID: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>

Please review the change to update to using jtreg `8.1`.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

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

Commit messages:
 - 8369488: Update to use jtreg 8.1

Changes: https://git.openjdk.org/jdk/pull/27719/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27719&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369488
  Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27719/head:pull/27719

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

From fandreuzzi at openjdk.org  Thu Oct  9 14:25:58 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 14:25:58 GMT
Subject: RFR: 8369440: Replace RootResolverMarkScope and
 RootSetClosureMarkScope with NMethodMarkingScope
Message-ID: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>

`RootResolverMarkScope` and `RootSetClosureMarkScope` have equivalent implementations to `NMethodMarkingScope`. They can be replaced to be more clear about what is actually needed.

We can also delete `strongRootsScope.hpp`, this change removes its last usages.

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - sort
 - replace

Changes: https://git.openjdk.org/jdk/pull/27729/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369440
  Stats: 85 lines in 6 files changed: 2 ins; 81 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27729/head:pull/27729

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

From asmehra at openjdk.org  Thu Oct  9 14:29:52 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 14:29:52 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v5]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <usigBSNm126LCCGYofxQsqQUeyaxxOV6gA-sVCn0IdU=.a502b539-8be5-45b8-8930-73eee90a5beb@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:

 - Move fast clinit check before the call to resolve_from_cache()
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Add support for ppc
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/73bc815f..e3553c0f

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

  Stats: 233 lines in 5 files changed: 94 ins; 99 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

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

From asmehra at openjdk.org  Thu Oct  9 14:32:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 14:32:41 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
Message-ID: <dHiBijQwLZmGvNjKhwVELcinVne2E3kvlXrNBORBHF0=.21679461-3037-49b5-a26c-4e224f372634@github.com>

On Thu, 9 Oct 2025 08:35:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thanks for the ping! PPC64 implementation:
>> 
>> diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> index 7431f77aeff..373dc24a62f 100644
>> --- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> +++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> @@ -2179,17 +2179,11 @@ void TemplateTable::_return(TosState state) {
>>  //   - Rscratch
>>  void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rcache, Register Rscratch) {
>>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>> +
>>    Label Lresolved, Ldone, L_clinit_barrier_slow;
>>    Register Rindex = Rscratch;
>>  
>>    Bytecodes::Code code = bytecode();
>> -  switch (code) {
>> -    case Bytecodes::_nofast_getfield: code = Bytecodes::_getfield; break;
>> -    case Bytecodes::_nofast_putfield: code = Bytecodes::_putfield; break;
>> -    default:
>> -      break;
>> -  }
>> -
>>    const int bytecode_offset = (byte_no == f1_byte) ? in_bytes(ResolvedMethodEntry::bytecode1_offset())
>>                                                     : in_bytes(ResolvedMethodEntry::bytecode2_offset());
>>    __ load_method_entry(Rcache, Rindex);
>> @@ -2201,10 +2195,9 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>>  
>>    // Class initialization barrier slow path lands here as well.
>>    __ bind(L_clinit_barrier_slow);
>> -
>>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>>    __ li(R4_ARG2, code);
>> -  __ call_VM(noreg, entry, R4_ARG2, true);
>> +  __ call_VM(noreg, entry, R4_ARG2);
>>  
>>    // Update registers with resolved info.
>>    __ load_method_entry(Rcache, Rindex);
>> @@ -2226,12 +2219,10 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>>    __ bind(Ldone);
>>  }
>>  
>> -void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>> -                                            Register Rcache,
>> -                                            Register index) {
>> +void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcache, Register index) {
>>    assert_different_registers(Rcache, index);
>>  
>> -  Label resolved;
>> +  Label Lresolved, Ldone, L_clinit_barrier_slow;
>>  
>>    Bytecodes::Code code = bytecode();
>>    switch (code) {
>> @@ -2246,19 +2237,34 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>>                                           : in_bytes(ResolvedFieldEntry::put...
>
>> @TheRealMDoerr with your patch `isync` is bypassed after `InterpreterRuntime::resolve_from_cache` call. Is it intentional?
> 
> Thanks for pointing this out. It is ok because the same thread has performed the resolution. So, no need for a memory barrier in this case because we didn't read values written by another thread.
> And even if another thread has done it, we already have enough memory barriers because `resolve_from_cache` contains a thread state switch (at least for PPC64 which uses lwsync).

@TheRealMDoerr thanks for the patch.
In my last commit I have updated the code to move the fast clinit check before the call to `resolve_from_cache`. I felt this simplifies the flow of logic and makes it easier to read. @iwanowww what do you think about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3386155460

From mdoerr at openjdk.org  Thu Oct  9 14:50:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Oct 2025 14:50:53 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
Message-ID: <ce3j04CYCE1M9KXzvg7Yn3ejkeaB9vhjiOojO0rAVxc=.bb6efa54-c600-4274-ad4c-8e40be0d3861@github.com>

On Thu, 9 Oct 2025 08:35:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thanks for the ping! PPC64 implementation:
>> 
>> diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> index 7431f77aeff..373dc24a62f 100644
>> --- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> +++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>> @@ -2179,17 +2179,11 @@ void TemplateTable::_return(TosState state) {
>>  //   - Rscratch
>>  void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rcache, Register Rscratch) {
>>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>> +
>>    Label Lresolved, Ldone, L_clinit_barrier_slow;
>>    Register Rindex = Rscratch;
>>  
>>    Bytecodes::Code code = bytecode();
>> -  switch (code) {
>> -    case Bytecodes::_nofast_getfield: code = Bytecodes::_getfield; break;
>> -    case Bytecodes::_nofast_putfield: code = Bytecodes::_putfield; break;
>> -    default:
>> -      break;
>> -  }
>> -
>>    const int bytecode_offset = (byte_no == f1_byte) ? in_bytes(ResolvedMethodEntry::bytecode1_offset())
>>                                                     : in_bytes(ResolvedMethodEntry::bytecode2_offset());
>>    __ load_method_entry(Rcache, Rindex);
>> @@ -2201,10 +2195,9 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>>  
>>    // Class initialization barrier slow path lands here as well.
>>    __ bind(L_clinit_barrier_slow);
>> -
>>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>>    __ li(R4_ARG2, code);
>> -  __ call_VM(noreg, entry, R4_ARG2, true);
>> +  __ call_VM(noreg, entry, R4_ARG2);
>>  
>>    // Update registers with resolved info.
>>    __ load_method_entry(Rcache, Rindex);
>> @@ -2226,12 +2219,10 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>>    __ bind(Ldone);
>>  }
>>  
>> -void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>> -                                            Register Rcache,
>> -                                            Register index) {
>> +void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcache, Register index) {
>>    assert_different_registers(Rcache, index);
>>  
>> -  Label resolved;
>> +  Label Lresolved, Ldone, L_clinit_barrier_slow;
>>  
>>    Bytecodes::Code code = bytecode();
>>    switch (code) {
>> @@ -2246,19 +2237,34 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>>                                           : in_bytes(ResolvedFieldEntry::put...
>
>> @TheRealMDoerr with your patch `isync` is bypassed after `InterpreterRuntime::resolve_from_cache` call. Is it intentional?
> 
> Thanks for pointing this out. It is ok because the same thread has performed the resolution. So, no need for a memory barrier in this case because we didn't read values written by another thread.
> And even if another thread has done it, we already have enough memory barriers because `resolve_from_cache` contains a thread state switch (at least for PPC64 which uses lwsync).

> @TheRealMDoerr thanks for the patch. In my last commit I have updated the code to move the fast clinit check before the call to `resolve_from_cache`. I felt this simplifies the flow of logic and makes it easier to read. @iwanowww what do you think about this?

That looks better. However, seems like for forgot a small detail (PPC64 example):

diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
index 14fdbfe0884..8657356de4a 100644
--- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
+++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
@@ -2203,6 +2203,8 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
     __ ld(method, in_bytes(ResolvedMethodEntry::method_offset()), Rcache);
     __ load_method_holder(klass, method);
     __ clinit_barrier(klass, R16_thread, &Ldone, /*L_slow_path*/ nullptr);
+  } else {
+    __ b(Ldone);
   }
 
   // Class initialization barrier slow path lands here as well.
@@ -2247,6 +2249,8 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcac
     // (ordered by compare-branch-isync).
     __ ld(field_holder, ResolvedFieldEntry::field_holder_offset(), Rcache);
     __ clinit_barrier(field_holder, R16_thread, &Ldone, /*L_slow_path*/ nullptr);
+  } else {
+    __ b(Ldone);
   }
 
   // resolve first time through

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3386202228

From kvn at openjdk.org  Thu Oct  9 14:54:34 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 9 Oct 2025 14:54:34 GMT
Subject: RFR: 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version
 stub area
In-Reply-To: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
References: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
Message-ID: <n6nXkBnk1WGffQfrS17iWz_ap0qP5xCl_i7GvJAQ93E=.34e777d4-86b1-46c7-b22d-017a93dc841d@github.com>

On Thu, 9 Oct 2025 05:59:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently these stubs are created in `Rdtsc::initialize` which may be called from the first ElapsedCounter now call. This causes problems with lock ranks as we may be holding a lock while taking time, because we need to lock the code cache to create a stub.
> 
> I suggest we move the `getCPUIDBrandString_stub` next to the other `VM_Version` stubs and generate them together. This is done at the earliest point we can, right after the CodeCache system has been initialized.

Looks reasonable.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27711#pullrequestreview-3319382110

From ayang at openjdk.org  Thu Oct  9 15:06:08 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 15:06:08 GMT
Subject: RFR: 8369440: Replace RootResolverMarkScope and
 RootSetClosureMarkScope with NMethodMarkingScope
In-Reply-To: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
Message-ID: <DZnC0cHpilY1agYC-PY9gMywjZSeUl3zjOY1KbGbG-4=.3f211070-4aee-417a-a58c-37af02826f5b@github.com>

On Thu, 9 Oct 2025 14:19:22 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> `RootResolverMarkScope` and `RootSetClosureMarkScope` have equivalent implementations to `NMethodMarkingScope`. They can be replaced to be more clear about what is actually needed.
> 
> We can also delete `strongRootsScope.hpp`, this change removes its last usages.
> 
> Passes tier1 and tier2 (fastdebug).

Preexisting: why the two "*MarkScope" are needed at all? (I can't find the code that actually requires the use of `NMethodMarkingScope`.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27729#issuecomment-3386220428

From asmehra at openjdk.org  Thu Oct  9 15:04:20 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 15:04:20 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <ce3j04CYCE1M9KXzvg7Yn3ejkeaB9vhjiOojO0rAVxc=.bb6efa54-c600-4274-ad4c-8e40be0d3861@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
 <ce3j04CYCE1M9KXzvg7Yn3ejkeaB9vhjiOojO0rAVxc=.bb6efa54-c600-4274-ad4c-8e40be0d3861@github.com>
Message-ID: <O8gwWfCJaBRJNZAHCKriTYZv8jVjL2gZtQ5vbIoAEMM=.0acb5c55-5d4a-4197-a6b5-ab4734d8c799@github.com>

On Thu, 9 Oct 2025 14:48:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> That looks better. However, seems like for forgot a small detail (PPC64 example):

@TheRealMDoerr Right, I missed that path. Thanks for pointing it out.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3386218226

From asmehra at openjdk.org  Thu Oct  9 15:30:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 15:30:56 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <ce3j04CYCE1M9KXzvg7Yn3ejkeaB9vhjiOojO0rAVxc=.bb6efa54-c600-4274-ad4c-8e40be0d3861@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <39gvPknUW65C4zdtKDSnCBl-KEIxQKy7X5vLA6WY_gE=.d20a434c-03f9-4814-97b3-f3b533357517@github.com>
 <ce3j04CYCE1M9KXzvg7Yn3ejkeaB9vhjiOojO0rAVxc=.bb6efa54-c600-4274-ad4c-8e40be0d3861@github.com>
Message-ID: <8_7dPchTHJtCNd-Rvl4SgAiagSHFM_rR0g4f-uRMZ-8=.9fa4d3a8-f0c4-4f99-bcbc-8836e6288a4a@github.com>

On Thu, 9 Oct 2025 14:48:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> @TheRealMDoerr with your patch `isync` is bypassed after `InterpreterRuntime::resolve_from_cache` call. Is it intentional?
>> 
>> Thanks for pointing this out. It is ok because the same thread has performed the resolution. So, no need for a memory barrier in this case because we didn't read values written by another thread.
>> And even if another thread has done it, we already have enough memory barriers because `resolve_from_cache` contains a thread state switch (at least for PPC64 which uses lwsync).
>
>> @TheRealMDoerr thanks for the patch. In my last commit I have updated the code to move the fast clinit check before the call to `resolve_from_cache`. I felt this simplifies the flow of logic and makes it easier to read. @iwanowww what do you think about this?
> 
> That looks better. However, seems like for forgot a small detail (PPC64 example):
> 
> diff --git a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> index 14fdbfe0884..8657356de4a 100644
> --- a/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> +++ b/src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
> @@ -2203,6 +2203,8 @@ void TemplateTable::resolve_cache_and_index_for_method(int byte_no, Register Rca
>      __ ld(method, in_bytes(ResolvedMethodEntry::method_offset()), Rcache);
>      __ load_method_holder(klass, method);
>      __ clinit_barrier(klass, R16_thread, &Ldone, /*L_slow_path*/ nullptr);
> +  } else {
> +    __ b(Ldone);
>    }
>  
>    // Class initialization barrier slow path lands here as well.
> @@ -2247,6 +2249,8 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no, Register Rcac
>      // (ordered by compare-branch-isync).
>      __ ld(field_holder, ResolvedFieldEntry::field_holder_offset(), Rcache);
>      __ clinit_barrier(field_holder, R16_thread, &Ldone, /*L_slow_path*/ nullptr);
> +  } else {
> +    __ b(Ldone);
>    }
>  
>    // resolve first time through

I pushed the commit to add the missing jump as suggested by @TheRealMDoerr but  strangely it is not reflecting in the PR. I can see the commit in my branch here https://github.com/openjdk/jdk/compare/master...ashu-mehra:jdk:fast-clinit-barrier-static-fields. Something amiss here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3386278179

From asmehra at openjdk.org  Thu Oct  9 15:36:05 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 15:36:05 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v6]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <aYfdXmeXoFG-BdfFtnVNb4Rhh8HEYJz2_l62UwMYxeg=.592da0e0-148f-4971-b04d-512cee934ee4@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing branch
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/e3553c0f..cc885f66

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

  Stats: 20 lines in 5 files changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

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

From eosterlund at openjdk.org  Thu Oct  9 15:45:21 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 9 Oct 2025 15:45:21 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching
 with Any GC
Message-ID: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>

This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.

The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.

This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.

The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.

The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.

Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in the archive. I call this iterative materialization, as opposed to traversing materialization used by the application threads if necessary.

Background materialization is performed in batches. Each batch has N roots and the background thread will ensure when processing a batch, that these roots are transitively materialized. In order to help with this, there is a table that for each root index knows the max DFS index transitively reachable. This allows each batch being processed by the background thread to define a range of objects currently being materialized: the first object and the last object of the batch.

This allows cheaper synchronization across threads. Each batch is claimed under a lock, but the actual processing of the batch may be performed without the lock, allowing the application thread(s) to perform traversals concurrently, without stepping on each others toes. When an application thread traverses through a root, for each visited object it can easily determine if this has already been transitively materialized by the background thread (before the current batch range), implying no further traversal is needed, or if the object is ahead of the current batch implying traversal is needed, or if the batch range currently being materialized contains the object, implying we should wait for it to finish. Intersections are rare, and for the most part, they can run independently.

Unlike the mapping solution, the new solution does not dump the entire string table. Instead, interned strings in the archive are marked as interned strings, and the loader knows when unpacking them that the string should be interned. An application thread might call intern before or after, but it does not matter; in both cases all links will be linked to the interned string, whichever one that is.

In order to speed up materialization, before GC is allowed to run, the materialization code maps object indices to objects using raw oops. It also copies archived object payload to the heap object (including object indices in the reference slots), and then fixes up the references in-place. This is only okay before GC is allowed to run. After that point in the bootstrapping, if materialization has not yet completed, a more careful strategy is used where primitive ranges are copied in bulk, but object references are copied one by one, so that the heap object never has its reference fields intermittently containing garbage object indices that can trip up a concurrent GC.

It is not currently intended to remove the previous heap archiving mechanism. Heuristically, we will pick the new mechanism when compressed oops is off. The JDK caches without compressed oops will hence use this new object streaming mechanism, while the other caches will use the old mapping mechanism. The HeapShared class has been used as a common interface between the two heap archive writers and loaders.

A lot of testing has been done with all combinations of GCs, AOTClassLinking, COH, COOPs, streaming/mapping, etc. Existing AOT/CDS tests have been adapted to manage with both heap archiving solutions.

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

Commit messages:
 - whitespace fixes
 - 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365932
  Stats: 8639 lines in 109 files changed: 5870 ins; 2312 del; 457 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From iris at openjdk.org  Thu Oct  9 15:54:33 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 9 Oct 2025 15:54:33 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <ceuIjydNidvKfTEkuljdRLyqX9HRl6AnO6W3P1u7AzI=.7f5521a0-7a2a-480e-a585-01d5987396fe@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319601046

From kvn at openjdk.org  Thu Oct  9 15:54:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 9 Oct 2025 15:54:40 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v6]
In-Reply-To: <aYfdXmeXoFG-BdfFtnVNb4Rhh8HEYJz2_l62UwMYxeg=.592da0e0-148f-4971-b04d-512cee934ee4@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <aYfdXmeXoFG-BdfFtnVNb4Rhh8HEYJz2_l62UwMYxeg=.592da0e0-148f-4971-b04d-512cee934ee4@github.com>
Message-ID: <KOmjbW0LDa7quROmaQpGbQaKmpvxobYzeWm82p0JRTs=.e4177da2-b19f-4d9a-bb74-4050eb559b47@github.com>

On Thu, 9 Oct 2025 15:36:05 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing branch
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2296:

> 2294:   } else {
> 2295:     __ b(Ldone);
> 2296:   }

I don't like 2 branches for non-static case. I suggest to move first branch inside checks:


if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {
    __ br(Assembler::NE, Lclinit_barrier_slow);
    __ ldr(temp, Address(Rcache, in_bytes(ResolvedMethodEntry::method_offset())));
    __ load_method_holder(temp, temp);
    __ clinit_barrier(temp, rscratch1, &Ldone, /*L_slow_path*/ nullptr);
    __ bind(Lclinit_barrier_slow);
  } else {
    __ br(Assembler::EQ, Ldone);
  }

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2348:

> 2346:   } else {
> 2347:     __ b(Ldone);
> 2348:   }

The same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2417222617
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2417223673

From sgehwolf at openjdk.org  Thu Oct  9 16:36:36 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Oct 2025 16:36:36 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <RI3LBUyncnr0s0vadXS97T3uTZK8sgv8pYHak4bs-Sk=.6637ccc6-27fc-4b89-be7e-39e391ac19a2@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <wXtUBpLwV5P8LREVe_XgoxpORuZ6xYyMBUnUTKYHjZU=.34a7a0b9-31a6-42d3-af87-453d8230c28a@github.com>
 <QUPs5wuXd62Rj3_N9E43e17g10SD1FlEcqrp26Bl5Rg=.f5a2b81c-b178-451b-bc08-478f6cc69b53@github.com>
 <RI3LBUyncnr0s0vadXS97T3uTZK8sgv8pYHak4bs-Sk=.6637ccc6-27fc-4b89-be7e-39e391ac19a2@github.com>
Message-ID: <Re9BCfUFgx0TkzbtqyR-FdV10UBkOd0gCDU2sPp_ebk=.3727bd5c-de15-4081-81c5-4bd6223b4eaa@github.com>

On Thu, 9 Oct 2025 12:10:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > The change looks okay to me , but you probably have to adjust the COPYRIGHT year info of the tests.
> 
> Thanks, I'll update the years.

Merged latest master and updated copyright years. Please take another look @MBaesken. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3386625577

From sgehwolf at openjdk.org  Thu Oct  9 16:36:35 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Oct 2025 16:36:35 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984 [v2]
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <RMEAHQ1hPRAeQbzlJNVGy2tyzIklyWuztgZzrSwdBrI=.b5a2d993-a6a7-4f83-b98b-9ef388403163@github.com>

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

Severin Gehwolf 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 three additional commits since the last revision:

 - Fix copyright
 - Merge branch 'master' into jdk-8369441-test-fixes
 - 8369441: Two container tests fail after JDK-8292984

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27699/files
  - new: https://git.openjdk.org/jdk/pull/27699/files/a828c243..e2659fcf

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

  Stats: 6461 lines in 167 files changed: 4868 ins; 860 del; 733 mod
  Patch: https://git.openjdk.org/jdk/pull/27699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27699/head:pull/27699

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

From shade at openjdk.org  Thu Oct  9 16:45:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 16:45:00 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v9]
In-Reply-To: <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
Message-ID: <7deKt1Cg4W148mw8OzqlCDuiaVGYG8SMtnwiz6pvE6E=.be4889af-24e9-4260-a896-4199eb0cbae4@github.com>

On Thu, 9 Oct 2025 13:40:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing include header

For your amusement, this is how a render for some events looks like, using this logging as input. With Shenandoah, so the actual VM work is very small.

Nearly perfect GC pause:
<img width="933" height="940" alt="example-nearly-perfect" src="https://github.com/user-attachments/assets/6f4652cb-df88-4503-8f26-6c3374f7ffae" />

TTSP hiccup:
<img width="1879" height="940" alt="example-ttsp-lag" src="https://github.com/user-attachments/assets/29b09c0e-bd17-4757-95d9-a6efd75e4372" />

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3386663230

From asmehra at openjdk.org  Thu Oct  9 16:23:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 16:23:41 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v6]
In-Reply-To: <KOmjbW0LDa7quROmaQpGbQaKmpvxobYzeWm82p0JRTs=.e4177da2-b19f-4d9a-bb74-4050eb559b47@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <aYfdXmeXoFG-BdfFtnVNb4Rhh8HEYJz2_l62UwMYxeg=.592da0e0-148f-4971-b04d-512cee934ee4@github.com>
 <KOmjbW0LDa7quROmaQpGbQaKmpvxobYzeWm82p0JRTs=.e4177da2-b19f-4d9a-bb74-4050eb559b47@github.com>
Message-ID: <vLEkNr3zsgvrjjxjuYRrRpE75Ui5oTncRzlk9NjTAFc=.13cd9c5a-9a5c-4b9a-a60e-0af348eb47cf@github.com>

On Thu, 9 Oct 2025 15:51:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing branch
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2296:
> 
>> 2294:   } else {
>> 2295:     __ b(Ldone);
>> 2296:   }
> 
> I don't like 2 branches for non-static case. I suggest to move first branch inside checks:
> 
> 
> if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {
>     __ br(Assembler::NE, Lclinit_barrier_slow);
>     __ ldr(temp, Address(Rcache, in_bytes(ResolvedMethodEntry::method_offset())));
>     __ load_method_holder(temp, temp);
>     __ clinit_barrier(temp, rscratch1, &Ldone, /*L_slow_path*/ nullptr);
>     __ bind(Lclinit_barrier_slow);
>   } else {
>     __ br(Assembler::EQ, Ldone);
>   }

I will update all other architectures to have the same construct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2417307426

From jkratochvil at openjdk.org  Thu Oct  9 16:49:49 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 9 Oct 2025 16:49:49 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl [v2]
In-Reply-To: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
Message-ID: <EpZx5Y73hjsFrLOOUhp0H5TpNx0RiwnRlI9yAYw7lYw=.f5de6d23-94e9-43dd-9f77-69a012d9a09e@github.com>

> https://bugs.openjdk.org/browse/JDK-8369021

Jan Kratochvil 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 linkclass
 - Make an alternative fix in compute_enclosing_class
 - Revert "8369021: A crash in ConstantPool::klass_at_impl"
   
   This reverts commit 026fcb1b21729e41524169c7f78855e8794ddae2.
 - 8369021: A crash in ConstantPool::klass_at_impl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27595/files
  - new: https://git.openjdk.org/jdk/pull/27595/files/026fcb1b..b0be560b

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

  Stats: 13515 lines in 520 files changed: 8508 ins; 2694 del; 2313 mod
  Patch: https://git.openjdk.org/jdk/pull/27595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27595/head:pull/27595

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

From jkratochvil at openjdk.org  Thu Oct  9 16:49:51 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 9 Oct 2025 16:49:51 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
Message-ID: <V4rZS1NLmHyGBLuNkm90XJfVmHP22FA7Ll7pJaZ42Uo=.ac66a808-e436-46f4-bd8f-d0e4c932ea61@github.com>

On Wed, 1 Oct 2025 20:21:45 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8369021

So I have moved it to compute_enclosing_class() and it is no longer linking the class. But it is not yet verified with the customer (and I still do not have a reproducer).

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

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3386672276

From jkratochvil at openjdk.org  Thu Oct  9 16:49:50 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 9 Oct 2025 16:49:50 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl
In-Reply-To: <Mh1MUSVHSLjPcHhlxJljSlUvect2q0-vTxf7CNXizTY=.9e56aecc-baf8-47d8-9e41-47bd9abfe86a@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <Mh1MUSVHSLjPcHhlxJljSlUvect2q0-vTxf7CNXizTY=.9e56aecc-baf8-47d8-9e41-47bd9abfe86a@github.com>
Message-ID: <cgKhS7KiXPSOwzJzCQxicDcC2ui9F7c4VjD1xdpgi1E=.759554fb-4047-46e7-8fe1-437d90896dd4@github.com>

On Wed, 1 Oct 2025 21:02:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Can a test case be crafted with `jdk.test.lib.ByteCodeLoader`? I remember a class returned by `ByteCodeLoader.load` static method is loaded but not linked.

Thanks but I think I cannot use that as `-XX:SharedArchiveFile` does not store classes from custom class loaders like `ByteCodeLoader`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3373446939

From mablakatov at openjdk.org  Thu Oct  9 17:00:08 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 9 Oct 2025 17:00:08 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
 <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
Message-ID: <N_BJY0Y4ifl9H1tc-DUAwrttqEV4tt8UUzFzpFvtEqY=.070da7c3-ac0b-4715-86f3-f51fb0b8216d@github.com>

On Wed, 8 Oct 2025 16:45:12 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 910:
>> 
>>> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");
>>> 909:         code()->share_trampoline_for(entry.target(), entry.target(), offset());
>>> 910:       } else if (entry.rspec().type() == relocInfo::static_call_type && callee != nullptr) {
>> 
>> I think we should require `callee` to non-null for `relocInfo::static_call_type`. Otherwise this will hide bugs, when it's been intended to share but forgotten to provide `callee`.
>
> We need to convert the check `callee != nullptr` into an assert.

> Otherwise this will hide bugs, when it's been intended to share but forgotten to provide callee.

I wouldn't call such instances "bugs" as compiled code should still behave correctly even though trampolines aren't shared.

>From a quick glace, strengthening the requirement would require some changes in C1. I'll take a closer look next week.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2417387462

From mablakatov at openjdk.org  Thu Oct  9 17:03:32 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 9 Oct 2025 17:03:32 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <VAIlgrpsyng8nOzhUTaV0C9A_1arm39f6P5QQVzLHcw=.a8824b3e-bfe9-4679-b464-33780e5b0750@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <VAIlgrpsyng8nOzhUTaV0C9A_1arm39f6P5QQVzLHcw=.a8824b3e-bfe9-4679-b464-33780e5b0750@github.com>
Message-ID: <udR4_Zp0x4HM_pCGEgHxbeKIDteQS_u8m1snDE3snVo=.04f42bce-1f43-473e-bf63-14b337f60c4c@github.com>

On Wed, 8 Oct 2025 16:03:02 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>>  - remove implementation-dependent logic from emit_shared_trampolines()
>>  - cleanup: update copyright headers
>>  - Make the value type of the dictionary a struct instead of Pair typedef
>>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>>  - Merge branch 'master'
>>  - Address review comments from @theRealAph and @eastig
>>    - use relocInfo::relocType instead of TrampolineCallKind
>>    - move rtype from keys to values; reduce the footprint of the patch
>>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>>  - Combine the two shared trampoline request hash tables
>>  - 8359359: AArch64: share trampolines between static calls to the same method
>>    
>>    Modify the C2 compiler to share trampoline stubs between static calls
>>    that resolve to the same callee method. Since the relocation target for
>>    all static calls is initially set to the static call resolver stub, the
>>    call's target alone cannot be used to distinguish between different
>>    static method calls. Instead, trampoline stubs should be shared based
>>    on the actual callee.
>>    
>>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>>    trampolines among static calls. However, due to imprecise log analysis,
>>    the test currently passes even when trampolines are not shared.
>>    Additionally, comments within the test suggest ambiguity regarding
>>    whether it was intended to assess trampoline sharing for static calls
>>    or runtime calls. To address these issues and eliminate ambiguity, this
>>    patch renames and updates the existing test. Furthermore, a new test is
>>    introduced, using the existing one as a foundation, to accurately
>>    evaluate trampoline sharing for both static and runtime calls.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1337:
> 
>> 1335:   // - relocInfo::static_call_type
>> 1336:   // - relocInfo::virtual_call_type
>> 1337:   // Trampolines may be emitted immediately or deferred until stub finalization,
> 
> "... until stub" -> "until CodeBuffer"

Well, the state is called `_finalize_stubs` and there's `CodeBuffer::finalize_stubs()` but I can see how "stub" can be confused with non-nmethod runtime stubs, so yeah, I'll reword it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2417401367

From mablakatov at openjdk.org  Thu Oct  9 17:00:05 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 9 Oct 2025 17:00:05 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <IpgrWBdQPAhdGSgG13iKtKwyzBA-lPu7hjLVqppyDdY=.0be7ab07-5c33-42e5-ac04-91726a7d863e@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <IpgrWBdQPAhdGSgG13iKtKwyzBA-lPu7hjLVqppyDdY=.0be7ab07-5c33-42e5-ac04-91726a7d863e@github.com>
Message-ID: <jFo5tsQAFKUR-fBorl9ewqAqCxF2L86cSdY4dSeEtfo=.2d613c6d-98c0-4636-959a-59022df64b00@github.com>

On Wed, 8 Oct 2025 17:07:28 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>>  - remove implementation-dependent logic from emit_shared_trampolines()
>>  - cleanup: update copyright headers
>>  - Make the value type of the dictionary a struct instead of Pair typedef
>>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>>  - Merge branch 'master'
>>  - Address review comments from @theRealAph and @eastig
>>    - use relocInfo::relocType instead of TrampolineCallKind
>>    - move rtype from keys to values; reduce the footprint of the patch
>>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>>  - Combine the two shared trampoline request hash tables
>>  - 8359359: AArch64: share trampolines between static calls to the same method
>>    
>>    Modify the C2 compiler to share trampoline stubs between static calls
>>    that resolve to the same callee method. Since the relocation target for
>>    all static calls is initially set to the static call resolver stub, the
>>    call's target alone cannot be used to distinguish between different
>>    static method calls. Instead, trampoline stubs should be shared based
>>    on the actual callee.
>>    
>>    The `SharedTrampolineTest.java` was designed to verify the sharing of
>>    trampolines among static calls. However, due to imprecise log analysis,
>>    the test currently passes even when trampolines are not shared.
>>    Additionally, comments within the test suggest ambiguity regarding
>>    whether it was intended to assess trampoline sharing for static calls
>>    or runtime calls. To address these issues and eliminate ambiguity, this
>>    patch renames and updates the existing test. Furthermore, a new test is
>>    introduced, using the existing one as a foundation, to accurately
>>    evaluate trampoline sharing for both static and runtime calls.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 908:
> 
>> 906:       // code during its branch shortening phase.
>> 907:       if (entry.rspec().type() == relocInfo::runtime_call_type) {
>> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");
> 
> `assert(callee == nullptr, "Runtime calls must not have Method");`

Sure, this shouldn't be a problem, thanks.

> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1339:
> 
>> 1337:   // Trampolines may be emitted immediately or deferred until stub finalization,
>> 1338:   // enabling reuse across call sites to reduce code size.
>> 1339:   // Runtime call trampolines are shared based on the entry value.
> 
> ... on entry value -> ... on entry target

Here "value" is used as a "value of a parameter". I'll rephrase it so it's less ambiguous , thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2417393474
PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2417392300

From erikj at openjdk.org  Thu Oct  9 17:30:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:30:22 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <O0F-Tt7MbvHPPqYhGN-lcKer75FuHmmBbCP1Ojpb1Tk=.abb8f0d1-0acb-492f-ae75-d9b6deb548a7@github.com>

On Thu, 9 Oct 2025 15:18:16 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Build changes trivially ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3386863791

From erikj at openjdk.org  Thu Oct  9 17:31:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Oct 2025 17:31:20 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <yrNV4JVv9750_c1Q8xvrDuzIP_Ps6A-rGAxbrljRdVE=.8c69f71f-b42e-4d1a-843b-0cff7681d470@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3319953574

From ayang at openjdk.org  Thu Oct  9 18:02:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 18:02:14 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v10]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <PRyBugfW89KkrkVGE-8FS6SgVRhl9ZdeAnCae1NrKBc=.8be95742-6e4a-4fcf-91aa-7914f0ddd0f5@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang 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 14 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - page-size
 - ... and 4 more: https://git.openjdk.org/jdk/compare/95bd1bb8...e02d0bf8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/421f1c4d..e02d0bf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=08-09

  Stats: 13086 lines in 471 files changed: 8379 ins; 2430 del; 2277 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From matsaave at openjdk.org  Thu Oct  9 18:37:16 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Oct 2025 18:37:16 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
Message-ID: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>

Trivial change to remove an unused line of code. Verified with tier1-5 tests.

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

Commit messages:
 - 8351595: JVM_FindClassFromCaller: unused var may be removed

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

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

From mli at openjdk.org  Thu Oct  9 18:43:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 18:43:18 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v3]
In-Reply-To: <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
Message-ID: <6yqFOMZnkRjdwq3kdtieWXIpATCbDozJF_EHeUF_zDw=.fd63620d-5264-4b1a-86a4-3ae812e5e303@github.com>

On Thu, 9 Oct 2025 09:04:35 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch? Thanks!
>> 
>> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
>> 
>> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
>> 
>> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
>> 
>> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
>> 
>> We can check the status of EnableVectorSupport as follows:
>> 
>> On k1
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [0.737s][info][compilation] EnableVectorSupport=false
>> [0.738s][info][compilation] EnableVectorReboxing=false
>> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
>> 
>> On qemu
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [3.048s][info][compilation] EnableVectorSupport=true
>> [3.050s][info][compilation] EnableVectorReboxing=true
>> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
>> 
>> 
>> ### Test (fastdebug)
>> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1
>
> Dingli Zhang 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
>  - Add supports_misaligned_vector_accesses
>  - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

Please the title of pr/bug by removing `RISC-V` prefix, if you want to get more attention, as you're changing the common code, and it could potentially impact other platforms.

src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 202:

> 200:   constexpr static bool supports_secondary_supers_table() { return true; }
> 201: 
> 202:   constexpr static bool supports_misaligned_vector_accesses() { return true; }

Does this `supports_misaligned_vector_accesses` equal to `AlignVector` option?

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

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3387096159
PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2417667384

From mli at openjdk.org  Thu Oct  9 18:47:01 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 18:47:01 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v3]
In-Reply-To: <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
Message-ID: <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>

On Thu, 9 Oct 2025 09:04:35 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch? Thanks!
>> 
>> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
>> 
>> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
>> 
>> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
>> 
>> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
>> 
>> We can check the status of EnableVectorSupport as follows:
>> 
>> On k1
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [0.737s][info][compilation] EnableVectorSupport=false
>> [0.738s][info][compilation] EnableVectorReboxing=false
>> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
>> 
>> On qemu
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [3.048s][info][compilation] EnableVectorSupport=true
>> [3.050s][info][compilation] EnableVectorReboxing=true
>> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
>> 
>> 
>> ### Test (fastdebug)
>> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1
>
> Dingli Zhang 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
>  - Add supports_misaligned_vector_accesses
>  - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184:

> 182:     FLAG_SET_DEFAULT(AlignVector,
> 183:       unaligned_vector.value() != MISALIGNED_VECTOR_FAST);
> 184:   } else if (AlignVector == false) {

Seems these code is not necessary, as when `unaligned_vector` is not retrieved from kernel for any reason, user might want to pass `-XX:-AlignVector`.
Your change disable this behaviour.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2417673489

From shade at openjdk.org  Thu Oct  9 18:50:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 18:50:59 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v9]
In-Reply-To: <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
Message-ID: <q3Y9TkVXfYSTS2PFsEMhMGZInTmgXIglrdSHAQzlEQY=.7d134668-ed77-444f-83b7-0e3053d9252a@github.com>

On Thu, 9 Oct 2025 13:40:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing include header

Thanks for reviews, all! The crude parsing tool I now have tells me the logging is fairly complete for the safepoint investigation purposes. The re-run of `make test TEST=all` finished without issues. We can do more stuff as followups, if needed. I am integrating this meanwhile.

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

PR Comment: https://git.openjdk.org/jdk/pull/27673#issuecomment-3387113025

From mli at openjdk.org  Thu Oct  9 18:53:40 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 9 Oct 2025 18:53:40 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v3]
In-Reply-To: <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
Message-ID: <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>

On Thu, 9 Oct 2025 18:43:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Dingli Zhang 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 three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
>>  - Add supports_misaligned_vector_accesses
>>  - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184:
> 
>> 182:     FLAG_SET_DEFAULT(AlignVector,
>> 183:       unaligned_vector.value() != MISALIGNED_VECTOR_FAST);
>> 184:   } else if (AlignVector == false) {
> 
> Seems these code is not necessary, as when `unaligned_vector` is not retrieved from kernel for any reason, user might want to pass `-XX:-AlignVector`.
> Your change disable this behaviour.

It seems my advice is the opposite of @iwanowww's, let's see what others think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2417687886

From shade at openjdk.org  Thu Oct  9 18:51:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 18:51:00 GMT
Subject: Integrated: 8369283: Improve trace logs in safepoint machinery
In-Reply-To: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
Message-ID: <Ht0NzNCG8oPU4xTcg3AXzjNZFdmT2_QPtvqgi6TqLgs=.0f21edaf-2d1c-46b1-8e12-95d9867b4a3a@github.com>

On Tue, 7 Oct 2025 12:42:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
> 
> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
> 
> 
> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
> 
> 
> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
> 
> I am open for bikeshedding on logging wording. The log example is in the comment below.
> 
> Additional testing:
>  - [x] Ad-hoc log peeking
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 1992b69a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1992b69a4794d1f2f65eaeb6dbb1e1e23a948b6e
Stats:     38 lines in 2 files changed: 28 ins; 7 del; 3 mod

8369283: Improve trace logs in safepoint machinery

Reviewed-by: fbredberg, dholmes, rehn

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

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

From liach at openjdk.org  Thu Oct  9 19:14:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 Oct 2025 19:14:22 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <EPVT7EP6eAV9Qocm99tIq6fKQQZsh3-hUU_ygD47Pvw=.75496bb3-36a4-49da-a825-ec79f4568267@github.com>

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Since this now makes the caller arg unused, we should remove the caller argument all the way up to Class.forName0. The caller was previously used for security manager it appears.

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

PR Comment: https://git.openjdk.org/jdk/pull/27735#issuecomment-3387181774

From fandreuzzi at openjdk.org  Thu Oct  9 20:28:01 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 20:28:01 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <apmqV4RiB_sS5JeOrY_lQXgGFxU0IjkHim9r4v2tkJo=.62eb0def-d4f9-4f5d-b0a0-81ea52c02bc9@github.com>

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3320528887

From duke at openjdk.org  Thu Oct  9 21:11:38 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 9 Oct 2025 21:11:38 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class
 loading
Message-ID: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>

the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.

The location of the class file for a class defined can be of utility in both debugging and auditing.

this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

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

Commit messages:
 - JDK-8365400: changed field label, and normalized value of 'source' when 'null' to 'jvm://'
 - JDK-8365400: added jdk.ClassFileDefine JFR event to record class file source

Changes: https://git.openjdk.org/jdk/pull/27738/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365400
  Stats: 30 lines in 4 files changed: 27 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27738/head:pull/27738

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

From fandreuzzi at openjdk.org  Thu Oct  9 21:37:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 21:37:05 GMT
Subject: RFR: 8369440: Replace RootResolverMarkScope and
 RootSetClosureMarkScope with NMethodMarkingScope
In-Reply-To: <DZnC0cHpilY1agYC-PY9gMywjZSeUl3zjOY1KbGbG-4=.3f211070-4aee-417a-a58c-37af02826f5b@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
 <DZnC0cHpilY1agYC-PY9gMywjZSeUl3zjOY1KbGbG-4=.3f211070-4aee-417a-a58c-37af02826f5b@github.com>
Message-ID: <FozzgaMfHne6rxpmpFuQ28p-2lAOUn2PBuzNqq4LKTQ=.1a71de26-e957-48ed-847d-075cc84f080a@github.com>

On Thu, 9 Oct 2025 15:03:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Preexisting: why the two "*MarkScope" are needed at all? (I can't find the code that actually requires the use of `NMethodMarkingScope`.)

Actually, I couldn't find it either. 

These `MarkScope` subclasses were introduced in a060be1 ([JDK-8199712](https://bugs.openjdk.org/browse/JDK-8199712)). I couldn't find any reason for adding them in a060be1. 

I'll remove them and re-run the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/27729#issuecomment-3387558771

From asmehra at openjdk.org  Thu Oct  9 21:38:37 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 9 Oct 2025 21:38:37 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v7]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <fzEjVCrXFkeyCfbOHTDKPqotgV8q1BSgfCnsC4X1nzU=.55ca5f9a-626f-4ef4-a114-e217bcac531c@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Avoid jumps
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/cc885f66..1b1ed25d

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

  Stats: 62 lines in 5 files changed: 26 ins; 25 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

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

From egahlin at openjdk.org  Thu Oct  9 23:27:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 Oct 2025 23:27:03 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v7]
In-Reply-To: <kXGecXvBw8ECiEuQx83C4RZVR6UvjkCvPatiK69Yj58=.1a532532-1e84-4934-898c-d935dba1f56f@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <kXGecXvBw8ECiEuQx83C4RZVR6UvjkCvPatiK69Yj58=.1a532532-1e84-4934-898c-d935dba1f56f@github.com>
Message-ID: <9wBvd5DT0I-3MdnYv4PJh1i8z5rYHaSUpH1v50hD4Ig=.210a8d17-cddc-4a65-9d88-2f0064183049@github.com>

On Wed, 8 Oct 2025 06:53:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add description attribute to Field

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27080#pullrequestreview-3320902481

From fandreuzzi at openjdk.org  Fri Oct 10 00:28:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 00:28:30 GMT
Subject: RFR: 8369440: Remove RootResolverMarkScope and
 RootSetClosureMarkScope [v2]
In-Reply-To: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
Message-ID: <FW-6HyGpFifQB3PhAMF03r_MiIppM7N2iIXXXdoWJ0s=.fa8afb23-7e92-4341-aa06-1e42716873e6@github.com>

> `RootResolverMarkScope` and `RootSetClosureMarkScope` are not needed, since the code using them does not require `nmethod::oops_do_marking_prologue`.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27729/files
  - new: https://git.openjdk.org/jdk/pull/27729/files/3605bd49..21cbbcb9

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

  Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27729/head:pull/27729

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

From dholmes at openjdk.org  Fri Oct 10 01:11:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 01:11:05 GMT
Subject: RFR: 8369442: ExitOnOutOfMemoryError should exit more gracefully
In-Reply-To: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
References: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
Message-ID: <MSENMMfdG0LyvwcpKwYBMENmqVEdhL-4l-vKReQGFGI=.8aa9570e-d497-4d50-9e05-64671f8e1f2d@github.com>

On Thu, 9 Oct 2025 08:35:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See RFE for more discussion. It seems we have a leeway in defining what "exit" means for `-XX:+ExitOnOutOfMemoryError`, and this PR does it more akin to `JVM_Halt`, rather than abrupt `os::_exit`. This gives VM a chance to shutdown some of its subsystems gracefully.
> 
> Comments welcome!
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

One concern I just realized with this, is that we will now grab the Heap_lock before doing the `VM_Exit` safepoint op. But we are calling this in the context of a failed allocation, so are we sure this will always be safe and not e.g. cause a deadlock?

I don't know who might use ExitOnOutOfMemoryError, nor in what way, so it is hard to say whether this change might break something

src/hotspot/share/utilities/debug.cpp line 287:

> 285:     if (ExitOnOutOfMemoryError) {
> 286:       tty->print_cr("Terminating due to java.lang.OutOfMemoryError: %s", message);
> 287:       // Gracefully exit with no cleanup hooks run.

Suggestion:

      // Gracefully exit with no cleanup hooks run - just like JVM_Halt

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

PR Review: https://git.openjdk.org/jdk/pull/27718#pullrequestreview-3321041988
PR Review Comment: https://git.openjdk.org/jdk/pull/27718#discussion_r2418275876

From dzhang at openjdk.org  Fri Oct 10 01:50:04 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 10 Oct 2025 01:50:04 GMT
Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to
 lack of support for misaligned vector access [v3]
In-Reply-To: <6yqFOMZnkRjdwq3kdtieWXIpATCbDozJF_EHeUF_zDw=.fd63620d-5264-4b1a-86a4-3ae812e5e303@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <6yqFOMZnkRjdwq3kdtieWXIpATCbDozJF_EHeUF_zDw=.fd63620d-5264-4b1a-86a4-3ae812e5e303@github.com>
Message-ID: <R6_qkijz8Qac6kUZpez9FRYLh8f2N-UsPHfokzyu70g=.70b5ee38-1261-4604-90ab-9a4601e6c798@github.com>

On Thu, 9 Oct 2025 18:40:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Dingli Zhang 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 three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
>>  - Add supports_misaligned_vector_accesses
>>  - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 202:
> 
>> 200:   constexpr static bool supports_secondary_supers_table() { return true; }
>> 201: 
>> 202:   constexpr static bool supports_misaligned_vector_accesses() { return true; }
> 
> Does this `supports_misaligned_vector_accesses` equal to `AlignVector` option?

For RISC-V, `supports_misaligned_vector_accesses` is only determined by hwprode, while `AlignVector` can also be modified by the user on platforms that support misaligned vector accesses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2418321228

From fyang at openjdk.org  Fri Oct 10 02:08:03 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Oct 2025 02:08:03 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v5]
In-Reply-To: <4fRM76zFQ7o3zDqVZ__J485lsG-QMB0S8kS5_qZD-CQ=.e2e2ca49-73e8-4fb1-9bfd-5a916518a8a2@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <4fRM76zFQ7o3zDqVZ__J485lsG-QMB0S8kS5_qZD-CQ=.e2e2ca49-73e8-4fb1-9bfd-5a916518a8a2@github.com>
Message-ID: <ty3_REYNibQxNblWHTaR37yFwOkvI7D5ZS4FQwK3BKA=.72a5a5c8-71a2-40f3-877c-e266f145cb5c@github.com>

On Thu, 9 Oct 2025 08:37:35 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> 
>> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
>> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
>> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
>> 
>> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert name from non_ext_xxx

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 293:

> 291:   /* Manufactory JEDEC id encoded, ISA vol 2 3.1.2.. */                                        \
> 292:   decl(mvendorid        ,  RV_NO_FLAG_BIT,  false,  NO_UPDATE_DEFAULT)                         \
> 293:   decl(zicboz_block_size ,  RV_NO_FLAG_BIT,  false,  NO_UPDATE_DEFAULT)                        \

You might want to fix the style for this group making the `,` separator at the same column. LGTM otherwise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2418333461

From fyang at openjdk.org  Fri Oct 10 02:39:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Oct 2025 02:39:02 GMT
Subject: RFR: 8368722: Vector API intrinsic enabled wrongly on platforms
 not supporting misaligned vector access [v3]
In-Reply-To: <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
 <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
Message-ID: <UHR_QMk3BOsqMglcPIm2ENYYhg7es7S6DWr54kQkqOs=.d5b69afe-ed04-4dbb-9943-f8c7863ff1d3@github.com>

On Thu, 9 Oct 2025 18:51:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184:
>> 
>>> 182:     FLAG_SET_DEFAULT(AlignVector,
>>> 183:       unaligned_vector.value() != MISALIGNED_VECTOR_FAST);
>>> 184:   } else if (AlignVector == false) {
>> 
>> Seems these code is not necessary, as when `unaligned_vector` is not retrieved from kernel for any reason, user might want to pass `-XX:-AlignVector`.
>> Your change disable this behaviour.
>
> It seems my advice is the opposite of @iwanowww's, let's see what others think.

Considering that the linux-riscv64 hwprobe syscall is not always usable for detecting support for misaligned vector access especially on old kernels, it makes sense to me that we should give the user a choice to decide.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2418364161

From fyang at openjdk.org  Fri Oct 10 02:52:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Oct 2025 02:52:02 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
Message-ID: <b7HOAPNfezUdGKpVFIf9NUu2AjiA0ILCVP0IzbOFqnM=.c47725e6-f84b-4932-a779-96954666992d@github.com>

On Thu, 9 Oct 2025 09:04:35 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch? Thanks!
>> 
>> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
>> 
>> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
>> 
>> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
>> 
>> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
>> 
>> We can check the status of EnableVectorSupport as follows:
>> 
>> On k1
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [0.737s][info][compilation] EnableVectorSupport=false
>> [0.738s][info][compilation] EnableVectorReboxing=false
>> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
>> 
>> On qemu
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [3.048s][info][compilation] EnableVectorSupport=true
>> [3.050s][info][compilation] EnableVectorReboxing=true
>> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
>> 
>> 
>> ### Test (fastdebug)
>> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1
>
> Dingli Zhang 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
>  - Add supports_misaligned_vector_accesses
>  - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

Mind you that the following tests explicitly are testing `-XX:-AlignVector` and won't work on hardware platforms without misaligned vector. But it doesn't seem to me reasonable to add a requirement like `@requires vm.opt.EnableVectorSupport == true` for them as they are superword tests. These tests were once enabled for RISC-V by: https://bugs.openjdk.org/browse/JDK-8352529. Maybe we should simply keep them disabled for this platform?


TEST: compiler/loopopts/superword/TestAlignVector.java#NoAlignVector
TEST: compiler/loopopts/superword/TestAlignVector.java#NoAlignVector-COH
TEST: compiler/loopopts/superword/TestAliasingFuzzer.java#random-flags
TEST: compiler/loopopts/superword/TestMemorySegment_8365982.java
TEST: compiler/c2/irTests/TestVectorizationNotRun.java
TEST: compiler/c2/irTests/TestVectorizationMismatchedAccess.java

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

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3388091546

From asmehra at openjdk.org  Fri Oct 10 03:41:48 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 03:41:48 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v8]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Fix s390 compilation failure
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/1b1ed25d..4eb89b8b

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

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

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

From asmehra at openjdk.org  Fri Oct 10 03:46:06 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 03:46:06 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v2]
In-Reply-To: <87C_6FuOFoMBTzG5So9cza63FT6qRyOqK8DJIuyn8Yc=.a21361ef-7013-46a5-a264-b7dc201e0e86@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <gY7F__sLglanNnkSg8fz5dj2rBhddoHBPcPYv7RC13s=.5c7f6e63-8d4c-474a-b449-f288dfe2be0f@github.com>
 <uEFqdPEdmXMKCZTXtIycCL9XcdsA-kjgBcbd3hQxot8=.96ddb44f-464f-4715-b921-0c1717cc4be1@github.com>
 <87C_6FuOFoMBTzG5So9cza63FT6qRyOqK8DJIuyn8Yc=.a21361ef-7013-46a5-a264-b7dc201e0e86@github.com>
Message-ID: <ILTyW13w_oHmjfLsMPVH1gU71o3RgsVVc3s6AZ3ENS4=.36ae7b70-ba99-4ee2-b159-d975497c03d4@github.com>

On Tue, 7 Oct 2025 16:37:24 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar @Hamlin-Li  @RealFYang @TheRealMDoerr 
>> I need help in adding arch specific code for s390, risc-v and ppc for this PR. Would you be able to contribute the code for these platforms? Specifically, we need to add a call to `clinit_barrier` in `TemplateTable::resolve_cache_and_index_for_field`.
>> 
>> @vnkozlov  @adinn @iwanowww can you please review this patch.
>
> Hi @ashu-mehra,
> 
> This is fixing the test failure on s390: 
> 
> 
> diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp
> index 2b39cc8318c..cf34bff7746 100644
> --- a/src/hotspot/cpu/s390/templateTable_s390.cpp
> +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp
> @@ -2409,6 +2409,7 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>    assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>  
>    NearLabel resolved;
> +  Label L_clinit_barrier_slow;
>  
>    Bytecodes::Code code = bytecode();
>    switch (code) {
> @@ -2425,6 +2426,8 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>    __ z_bre(resolved);
>  
>    // resolve first time through
> +  // Class initialization barrier slow path lands here as well.
> +  __ bind(L_clinit_barrier_slow);
>    address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
>    __ load_const_optimized(Z_ARG2, (int)code);
>    __ call_VM(noreg, entry, Z_ARG2);
> @@ -2434,6 +2437,15 @@ void TemplateTable::resolve_cache_and_index_for_field(int byte_no,
>  
>    __ bind(resolved);
>  
> +  // Class initialization barrier for static fields
> +  if (VM_Version::supports_fast_class_init_checks() &&
> +      (bytecode() == Bytecodes::_getstatic || bytecode() == Bytecodes::_putstatic)) {
> +    const Register field_holder = index;
> +
> +    __ load_sized_value(field_holder, Address(cache, ResolvedFieldEntry::field_holder_offset()), sizeof(void*), false);
> +    __ clinit_barrier(field_holder, Z_thread, nullptr /*L_fast_path*/, &L_clinit_barrier_slow);
> +  }
> +
>    BLOCK_COMMENT("} resolve_cache_and_index_for_field");
>  }

@offamitkumar @RealFYang @TheRealMDoerr
I have made some changes on top of the arch specific patches to make it easier to understand the code flow. Can you please review the changes and provide approval if it all looks good.

@vnkozlov I have incorporated your suggestion. Please review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3388181594

From dholmes at openjdk.org  Fri Oct 10 04:00:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 04:00:01 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <WmBderXMTFUXN8Gv0UYvOsczW7CjBXaZfD90RpAKaA0=.435446a7-cc6d-4664-8b82-910db7bfcee9@github.com>

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

If caller is unused then this whole function is now meaningless as it is only separated out to allow using the caller to establish the ProtectionDomain.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3321261528

From dholmes at openjdk.org  Fri Oct 10 04:41:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 04:41:02 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
Message-ID: <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>

On Thu, 9 Oct 2025 13:00:33 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> This makes the top level os::free_memory() the obvious default to use for most use cases that don't care if we are running in a container or not, 

I have to disagree with the basic premise there. `os::free_memory` has to be specified to return some notion of "free memory" and that will either have to account for, or not account for, containers. The caller can't "not care" because the caller has to know why they are asking for this and what they expect to get back. 

I'm not convinced this API split is actually a good fit in general. The existing os::xxx API exposes some values based on a very old monolithic model of program execution: free-memory, available-memory, swap-space, available-processors. But they are not very well-defined concepts in modern compute environments. We've tried to map these to things that containers expose but there isn't always a clear way to do so - ref "active processors" when CPU quotas are involved. Even on the "machine" side it is far from clear e.g. what should "active processors" return for the "machine"? Your implementation will return sched_getaffinity values which accounts for cpu-sets that can come from the container environment - so that isn't really the "machine" value.

It might be clearer to just define specific methods for the things that are currently missing that you need to query, rather than trying to generalize the existing poorly-defined API. If you insist that three API's is better then I would like to see clear specifications for what each of the method variants actually returns.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3388264801

From ysuenaga at openjdk.org  Fri Oct 10 05:06:14 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 10 Oct 2025 05:06:14 GMT
Subject: Integrated: 8366847: JFR reports incorrect number of cores on hybrid
 CPU
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <8NtYMtIQcTEJPXa_QJKW9D8gfVXfyBiUMf8nUzbCnpM=.ba9e817a-975c-497e-832f-dc9287e32eb8@github.com>

On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

This pull request has now been integrated.

Changeset: be107224
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be10722436f20df26de66c00c4bc1b6772aa9087
Stats:     11 lines in 2 files changed: 9 ins; 0 del; 2 mod

8366847: JFR reports incorrect number of cores on hybrid CPU

Reviewed-by: dholmes, egahlin

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

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

From amitkumar at openjdk.org  Fri Oct 10 05:13:06 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 10 Oct 2025 05:13:06 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v8]
In-Reply-To: <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>
Message-ID: <WpLjOsEUAZ458akDLRTsjzrzz3GCgNhYd00amIx2Fhw=.9f89bdc1-78ce-494a-8be7-fe320f9644c4@github.com>

On Fri, 10 Oct 2025 03:41:48 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix s390 compilation failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

s390 part looks good and tier1 test passed with fastdebug vm.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3321359348

From dholmes at openjdk.org  Fri Oct 10 05:41:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 05:41:11 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl [v2]
In-Reply-To: <EpZx5Y73hjsFrLOOUhp0H5TpNx0RiwnRlI9yAYw7lYw=.f5de6d23-94e9-43dd-9f77-69a012d9a09e@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <EpZx5Y73hjsFrLOOUhp0H5TpNx0RiwnRlI9yAYw7lYw=.f5de6d23-94e9-43dd-9f77-69a012d9a09e@github.com>
Message-ID: <whZGoIvGBseY0bSzrdXhhG8SMVBPKIlNOrTyISDTR4E=.39bf0af7-48b9-4909-aeb7-d082ee0f6fa6@github.com>

On Thu, 9 Oct 2025 16:49:49 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8369021
>
> Jan Kratochvil 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 linkclass
>  - Make an alternative fix in compute_enclosing_class
>  - Revert "8369021: A crash in ConstantPool::klass_at_impl"
>    
>    This reverts commit 026fcb1b21729e41524169c7f78855e8794ddae2.
>  - 8369021: A crash in ConstantPool::klass_at_impl

I am still trying to piece together the actual problem here. 
- We are calling `GetDeclaringClass` on a given class `k`.
- We have found that `k` lists `outer_k` as its enclosing class.
- We are checking if `outer_k` lists `k` as an inner class via `Reflection::check_for_inner_class.
- We are looking up `outer_k->constants->klass_at(x)` where `x` could be the inner-class index or the outher-class index (can't tell which from the bug report)
- `klass_at_impl` does ` Handle loader (THREAD, this_cp->pool_holder()->class_loader());`, which is the same as `outer_k->class_loader()`
- `class_loader()` does `return class_loader_data()->class_loader()`
- we crash because `class_loader_data()` is null.

We normally set the `class_loader_data` during class file parsing, in `fill_instance_klass` which is done with `create_instance_klass`. So there is no way it should be null. And it not being null is not connected with the class being linked.

So there is a big piece of this puzzle missing for me.

src/hotspot/share/oops/instanceKlass.cpp line 3332:

> 3330:   if (nullptr == outer_klass) return nullptr;
> 3331: 
> 3332:   // Wait until also outer_klass gets fully loaded.

How are you "waiting"?

src/hotspot/share/oops/instanceKlass.cpp line 3333:

> 3331: 
> 3332:   // Wait until also outer_klass gets fully loaded.
> 3333:   InstanceKlass* pool_holder = outer_klass->constants()->pool_holder();

This should just set `pool_holder == outer_klass`. When we parse a class we do:

 _cp->set_pool_holder(this_klass);
this_klass->set_constants(_cp);

so `klass->constants()->pool_holder() == klass`. ??

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

PR Review: https://git.openjdk.org/jdk/pull/27595#pullrequestreview-3321335573
PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2418493625
PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2418508887

From dholmes at openjdk.org  Fri Oct 10 05:46:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 05:46:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <iNjD85NyiIAqTYuNqPtymJturfgclyWfnzZNq0QiVxc=.8efe3a56-5d65-4806-895f-430f1a422632@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

> Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

It is discouraged but yes they exist and cause problems. I am currently fixing a bunch of issues due to static Semaphore instances. https://bugs.openjdk.org/browse/JDK-8361462

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3388368328

From dholmes at openjdk.org  Fri Oct 10 05:51:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 05:51:21 GMT
Subject: RFR: 8369283: Improve trace logs in safepoint machinery [v9]
In-Reply-To: <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
References: <hgIE8djd_YJcdQCBW0U9g3Iln3x_Si8InSqXlZA_8uQ=.4c8810b6-4ac1-4acf-85f0-53efecfc4aba@github.com>
 <2pDyRgqLIr53SiyCR-KtIGoRr6WiHR45KgJ1OjiJYZQ=.0a00e969-2c22-4687-8250-0396bc380a0e@github.com>
Message-ID: <JKGBsjTWXHGBFv_wljNAMddUOfBtbDNcydWZwHERJS4=.27bf952c-051e-4dd5-8673-171b72460ecf@github.com>

On Thu, 9 Oct 2025 13:40:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During the performance investigations in safepoint machinery (notably [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324)), I found the trace logging lacking. It would be good to improve it in order to finely profile various microscopic things like thread list walks, the blocking/resuming of Java threads, etc. For [JDK-8350324](https://bugs.openjdk.org/browse/JDK-8350324), for example, I want to be able to measure the Java thread delays if they assist in avalanche wakeups.
>> 
>> This leans heavily on unified logging and invariant clocks to do the right thing, but I think it is a fair compromise for simplicity. The configuration I found most useful for testing is:
>> 
>> 
>> -Xlog:async -Xlog:safepoint=trace:file=safepoint.log:uptimenanos
>> 
>> 
>> My tentative plan is to visualize this more comprehensively with a little tool that digests that log.
>> 
>> I am open for bikeshedding on logging wording. The log example is in the comment below.
>> 
>> Additional testing:
>>  - [x] Ad-hoc log peeking
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing include header

Good update on the `thread_id()`. I had considered that earlier but it seemed we were using the address elsewhere so I didn't raise it. :)

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

PR Review: https://git.openjdk.org/jdk/pull/27673#pullrequestreview-3321439765

From shade at openjdk.org  Fri Oct 10 06:12:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Oct 2025 06:12:42 GMT
Subject: RFR: 8369442: ExitOnOutOfMemoryError should exit more gracefully
 [v2]
In-Reply-To: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
References: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
Message-ID: <moKnZOqMChLs9ZagjBhrooi-LhVGJRGE8YoN5nWYkSI=.959ad531-9f3d-4eb0-bb0a-13148af5d898@github.com>

> See RFE for more discussion. It seems we have a leeway in defining what "exit" means for `-XX:+ExitOnOutOfMemoryError`, and this PR does it more akin to `JVM_Halt`, rather than abrupt `os::_exit`. This gives VM a chance to shutdown some of its subsystems gracefully.
> 
> Comments welcome!
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/utilities/debug.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27718/files
  - new: https://git.openjdk.org/jdk/pull/27718/files/238d2901..40062dfc

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

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

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

From aboldtch at openjdk.org  Fri Oct 10 06:29:40 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 06:29:40 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:

 - sspitsyn patch
 - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state"
   
   This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27716/files
  - new: https://git.openjdk.org/jdk/pull/27716/files/e133d9b7..4ec7ce98

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

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

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

From aboldtch at openjdk.org  Fri Oct 10 06:35:01 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 06:35:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <Iv_JXTJ3IrRfxUfjYBzxzB9NkT7mpHgDrHyd0P-gf-c=.8b64b59f-39fa-472f-96c5-56438e2c2abe@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I agree with this. Below is the patch for this change.

Done. 

I was also wondering why the original patch change from just `JavaThread::jvmti_thread_state` to `get_jvmti_thread_state`. But it looked so intentional, I thought it was fundamental to JDK-8368159.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388474246

From alanb at openjdk.org  Fri Oct 10 06:51:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 06:51:03 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <tsehEEs4x9-trnunJ1dlxVPp8b5j_A11Va0fR6b0ytk=.5ae59369-3d86-4491-a829-149ba8a5c59c@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

The evolution of JFR events isn't clear to me so I don't know if adding a field is compatible or not for programs that are processing recordings. (I'm just trying to understand why a new not-enabled-by-default event is added instead of adding a field to the existing ClassDefine event.

The existing event is emitted in SystemDictionary::define_instance_class, the new event emits it from JVM_DefineClassXXX. Is this because it was awkward to get at cfs->source from the SD code?

I assume that a test will be added as it would be easy to refactor code and not record the event if enabled.

Using "jvm" as the URI scheme when there is no source is a bit strange. There will be custom class loaders that don't provide a code source, do you really want these to use this source in the event?

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3388530284

From wenanjian at openjdk.org  Fri Oct 10 07:19:39 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 07:19:39 GMT
Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before
 use [v3]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <3DE5IeY1Wq3hbsJghlSW3bNMcbBdtMwMNdFj-ik4NZU=.bb2797b4-8715-43c6-a782-4067464b6221@github.com>

> we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use
> 
> Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess

Anjian Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into add_unaligned_access_check
 - delete AvoidUnalignedAccesses and extra unnecessary check
 - RISC-V: Add unaligned access check

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

Changes: https://git.openjdk.org/jdk/pull/27510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27510&range=02
  Stats: 34 lines in 5 files changed: 0 ins; 6 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27510/head:pull/27510

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

From wenanjian at openjdk.org  Fri Oct 10 07:16:20 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 07:16:20 GMT
Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before
 use [v2]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <SUdkApI6yYLQyIiEDkrS86XjDVMR1O3aBkSAGqX98PA=.4a680b2b-4854-4b1e-839e-1481b3fcd6a6@github.com>

> we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use
> 
> Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  delete AvoidUnalignedAccesses and extra unnecessary check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27510/files
  - new: https://git.openjdk.org/jdk/pull/27510/files/3f657e0a..42f1db93

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

  Stats: 34 lines in 5 files changed: 0 ins; 7 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/27510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27510/head:pull/27510

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

From mbaesken at openjdk.org  Fri Oct 10 07:25:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 07:25:05 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984 [v2]
In-Reply-To: <RMEAHQ1hPRAeQbzlJNVGy2tyzIklyWuztgZzrSwdBrI=.b5a2d993-a6a7-4f83-b98b-9ef388403163@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <RMEAHQ1hPRAeQbzlJNVGy2tyzIklyWuztgZzrSwdBrI=.b5a2d993-a6a7-4f83-b98b-9ef388403163@github.com>
Message-ID: <yO6GnMBMrP1s6NkSy3kT3Bk3QQjswS_XLlz29Geo_gQ=.00d19a3f-a944-40d8-bc11-2d44949c8120@github.com>

On Thu, 9 Oct 2025 16:36:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
>> 
>> Updating both tests fix the problems.
>> 
>> **Testing:**
>> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
>> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
>> 
>> Thanks,
>> Severin
>
> Severin Gehwolf 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 three additional commits since the last revision:
> 
>  - Fix copyright
>  - Merge branch 'master' into jdk-8369441-test-fixes
>  - 8369441: Two container tests fail after JDK-8292984

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27699#pullrequestreview-3321701493

From wenanjian at openjdk.org  Fri Oct 10 07:26:56 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 07:26:56 GMT
Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before
 use [v4]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <TciQv1o-lV4Ohpt6FYzRmriSJbaG8fn0jDeaJTPDq_I=.8f023f93-dd32-4394-99be-3c0e0130a9bc@github.com>

> we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use
> 
> Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  delete whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27510/files
  - new: https://git.openjdk.org/jdk/pull/27510/files/910840da..c1b209fe

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

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

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

From dbriemann at openjdk.org  Fri Oct 10 07:51:45 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Fri, 10 Oct 2025 07:51:45 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  cast compare_value to unsigned

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/9aa64ff9..9e6fecd0

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

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

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

From aboldtch at openjdk.org  Fri Oct 10 07:54:34 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 07:54:34 GMT
Subject: RFR: 8367149: Add convenient construction for creating ad-hoc
 VMErrorCallback [v6]
In-Reply-To: <Cg4LOai5-cQ7hR-qy97a9aoYPgcM71wk4uRVykUYjUM=.665079a5-6112-4960-b5eb-794eda8c1383@github.com>
References: <Cg4LOai5-cQ7hR-qy97a9aoYPgcM71wk4uRVykUYjUM=.665079a5-6112-4960-b5eb-794eda8c1383@github.com>
Message-ID: <IHZsuphvvZMPlWW371um7olllcxyCYdQnAug96TDMd8=.eccfd009-8376-4f04-845d-adf8bfd47d25@github.com>

> Add a class OnVMError which uses the VMErrorCallback mechanism which is a convenient construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use:
> ```C++
>   {
>     // Note the lambda is invoked after an error occurs within this thread,
>     // and during on_error's lifetime. If state prior to the crash is required,
>     // capture a copy of it first.
>     auto important_value = get_the_value();
> 
>     OnVMError on_error([&](outputStream* st) {
>       // Dump the important bits.
>       st->print("Prior value: ");
>       important_value.print_on(st);
>       st->print("During crash: ")
>       get_the_value().print_on(st);
>       // Dump whole the whole state.
>       this->print_on(st);
>     });
> 
>     // Sometimes doing a thing will crash the VM.
>     do_a_thing();
>   }
> 
> 
> C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods.

Axel Boldt-Christmas 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 eight additional commits since the last revision:

 - Merge tag 'jdk-26+19' into JDK-8367149
   
   Added tag jdk-26+19 for changeset b37a1a33
 - Merge tag 'jdk-26+18' into JDK-8367149
   
   Added tag jdk-26+18 for changeset 5251405c
 - Merge tag 'jdk-26+17' into JDK-8367149
   
   Added tag jdk-26+17 for changeset 2aafda19
 - Replace ergonomic with convenient
 - Add a comment explaining the deduction rules
 - Skip multiple inheritance and allow more than lambda like callables.
 - Update doc example
 - 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27159/files
  - new: https://git.openjdk.org/jdk/pull/27159/files/250f23f3..6101c3ec

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

  Stats: 13098 lines in 507 files changed: 8331 ins; 2505 del; 2262 mod
  Patch: https://git.openjdk.org/jdk/pull/27159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159

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

From stefank at openjdk.org  Fri Oct 10 08:04:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 10 Oct 2025 08:04:42 GMT
Subject: RFR: 8367149: Add convenient construction for creating ad-hoc
 VMErrorCallback [v6]
In-Reply-To: <IHZsuphvvZMPlWW371um7olllcxyCYdQnAug96TDMd8=.eccfd009-8376-4f04-845d-adf8bfd47d25@github.com>
References: <Cg4LOai5-cQ7hR-qy97a9aoYPgcM71wk4uRVykUYjUM=.665079a5-6112-4960-b5eb-794eda8c1383@github.com>
 <IHZsuphvvZMPlWW371um7olllcxyCYdQnAug96TDMd8=.eccfd009-8376-4f04-845d-adf8bfd47d25@github.com>
Message-ID: <EBAYnAC_mQb6g5m82IJJG7VuwIEEBjMDlLtLHiAJh7M=.db9345f9-1646-494f-8519-ad0f104e979a@github.com>

On Fri, 10 Oct 2025 07:54:34 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a class OnVMError which uses the VMErrorCallback mechanism which is a convenient construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use:
>> ```C++
>>   {
>>     // Note the lambda is invoked after an error occurs within this thread,
>>     // and during on_error's lifetime. If state prior to the crash is required,
>>     // capture a copy of it first.
>>     auto important_value = get_the_value();
>> 
>>     OnVMError on_error([&](outputStream* st) {
>>       // Dump the important bits.
>>       st->print("Prior value: ");
>>       important_value.print_on(st);
>>       st->print("During crash: ")
>>       get_the_value().print_on(st);
>>       // Dump whole the whole state.
>>       this->print_on(st);
>>     });
>> 
>>     // Sometimes doing a thing will crash the VM.
>>     do_a_thing();
>>   }
>> 
>> 
>> C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods.
>
> Axel Boldt-Christmas 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 eight additional commits since the last revision:
> 
>  - Merge tag 'jdk-26+19' into JDK-8367149
>    
>    Added tag jdk-26+19 for changeset b37a1a33
>  - Merge tag 'jdk-26+18' into JDK-8367149
>    
>    Added tag jdk-26+18 for changeset 5251405c
>  - Merge tag 'jdk-26+17' into JDK-8367149
>    
>    Added tag jdk-26+17 for changeset 2aafda19
>  - Replace ergonomic with convenient
>  - Add a comment explaining the deduction rules
>  - Skip multiple inheritance and allow more than lambda like callables.
>  - Update doc example
>  - 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27159#pullrequestreview-3321850393

From rrich at openjdk.org  Fri Oct 10 08:08:48 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 10 Oct 2025 08:08:48 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
Message-ID: <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>

On Fri, 10 Oct 2025 07:51:45 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cast compare_value to unsigned

Nice job! ?

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 186:

> 184:     : [dest]            "b"     (dest),
> 185:       [exchange_value]  "r"     (exchange_value),
> 186:                         "m"     (*dest)

The memory operands with constraint 'm' are unused. I think the intent was to express that `dest` is dereferenced to read and write memory at that location. But that's expressed with `memory` in the `clobber` section.
These operands should be removed.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 224:

> 222:     : [dest]            "b"     (dest),
> 223:       [exchange_value]  "r"     (exchange_value),
> 224:                         "m"     (*dest)

Unused operands with memory constraint can be removed.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 274:

> 272:       [masked_compare_value]   "r"     (masked_compare_value),
> 273:       [exchange_value]         "r"     (exchange_value),
> 274:                                "m"     (*dest)

Unused operands with memory constraint can be removed.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 322:

> 320:       [compare_value]   "r"     (compare_value),
> 321:       [exchange_value]  "r"     (exchange_value),
> 322:                         "m"     (*dest)

Unused operands with memory constraint can be removed.

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 370:

> 368:       [compare_value]   "r"     (compare_value),
> 369:       [exchange_value]  "r"     (exchange_value),
> 370:                         "m"     (*dest)

Unused operands with memory constraint can be removed.

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

Changes requested by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3321853903
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2418839142
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2418841888
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2418842744
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2418843479
PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2418844290

From wenanjian at openjdk.org  Fri Oct 10 08:09:27 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 08:09:27 GMT
Subject: RFR: 8368724: RISC-V: Derived AvoidUnalignedAccesses Flag [v5]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>

> we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use
> 
> Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix the use of unaligned_access

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27510/files
  - new: https://git.openjdk.org/jdk/pull/27510/files/c1b209fe..be963cdc

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

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

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

From sgehwolf at openjdk.org  Fri Oct 10 08:17:12 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Oct 2025 08:17:12 GMT
Subject: RFR: 8369441: Two container tests fail after JDK-8292984 [v2]
In-Reply-To: <RMEAHQ1hPRAeQbzlJNVGy2tyzIklyWuztgZzrSwdBrI=.b5a2d993-a6a7-4f83-b98b-9ef388403163@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
 <RMEAHQ1hPRAeQbzlJNVGy2tyzIklyWuztgZzrSwdBrI=.b5a2d993-a6a7-4f83-b98b-9ef388403163@github.com>
Message-ID: <smA42G_PNkRHoaIwDgTjeJfd2ZN6KjCdTPoPOC0z1DU=.341cf2dc-8c0b-4182-8f14-841f1d9e7d94@github.com>

On Thu, 9 Oct 2025 16:36:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
>> 
>> Updating both tests fix the problems.
>> 
>> **Testing:**
>> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
>> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
>> 
>> Thanks,
>> Severin
>
> Severin Gehwolf 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 three additional commits since the last revision:
> 
>  - Fix copyright
>  - Merge branch 'master' into jdk-8369441-test-fixes
>  - 8369441: Two container tests fail after JDK-8292984

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27699#issuecomment-3388780718

From sgehwolf at openjdk.org  Fri Oct 10 08:17:13 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Oct 2025 08:17:13 GMT
Subject: Integrated: 8369441: Two container tests fail after JDK-8292984
In-Reply-To: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
References: <7I5PqfoUct49xjZmdhD3SHyzWLvrz9VKSl3p0GWc4Bw=.23a8fcb1-1326-48f0-a38a-93cd33e503e3@github.com>
Message-ID: <Zrx6aa7mvndvCx_QKPQrLzoyhupfXEo1FQh8t_J9WYs=.5d4bae21-8344-4ebb-ba3f-530b814815b9@github.com>

On Wed, 8 Oct 2025 16:46:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple test fix to the some container tests which currently fail. `TestJFREvents.java` fails because it was relying on a log line at the trace level in order to parse the total machine memory from it and use in the test. We should instead not rely on the log line but use the existing Whitebox API to query that info. `TestMemoryAwareness.java` fails because it matches a log line that was changed in JDK-8292984.
> 
> Updating both tests fix the problems.
> 
> **Testing:**
> - [x] GHA (not really useful for this as the touched tests don't run and it touches nothing else)
> - [x] Ran the affected container tests locally on Linux x86_64 (cg v2). Fail before this fix, pass after.
> 
> Thanks,
> Severin

This pull request has now been integrated.

Changeset: a1a37bd7
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1a37bd7b2a8807f462909eadfa83ec26261e464
Stats:     23 lines in 2 files changed: 3 ins; 13 del; 7 mod

8369441: Two container tests fail after JDK-8292984

Reviewed-by: mbaesken, cnorrbin, syan

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

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

From mli at openjdk.org  Fri Oct 10 08:17:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Oct 2025 08:17:44 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v6]
In-Reply-To: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
Message-ID: <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>

> Hi,
> Can you help to review the patch?
> 
> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
> 
> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
> 
> Thanks!

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27562/files
  - new: https://git.openjdk.org/jdk/pull/27562/files/f2cc974e..b995f7dd

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

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

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

From mli at openjdk.org  Fri Oct 10 08:17:46 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Oct 2025 08:17:46 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v5]
In-Reply-To: <ty3_REYNibQxNblWHTaR37yFwOkvI7D5ZS4FQwK3BKA=.72a5a5c8-71a2-40f3-877c-e266f145cb5c@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <4fRM76zFQ7o3zDqVZ__J485lsG-QMB0S8kS5_qZD-CQ=.e2e2ca49-73e8-4fb1-9bfd-5a916518a8a2@github.com>
 <ty3_REYNibQxNblWHTaR37yFwOkvI7D5ZS4FQwK3BKA=.72a5a5c8-71a2-40f3-877c-e266f145cb5c@github.com>
Message-ID: <cwIJR01ZOoq3ZXFTpLngJCh6m6-BHFYv9hcFQmnbRYY=.a34077b6-3877-4765-a62f-b8200f5b5477@github.com>

On Fri, 10 Oct 2025 02:01:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert name from non_ext_xxx
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 293:
> 
>> 291:   /* Manufactory JEDEC id encoded, ISA vol 2 3.1.2.. */                                        \
>> 292:   decl(mvendorid        ,  RV_NO_FLAG_BIT,  false,  NO_UPDATE_DEFAULT)                         \
>> 293:   decl(zicboz_block_size ,  RV_NO_FLAG_BIT,  false,  NO_UPDATE_DEFAULT)                        \
> 
> You might want to fix the style for this group making the `,` separator at the same column. LGTM otherwise.

fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2418870283

From aboldtch at openjdk.org  Fri Oct 10 08:18:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 08:18:03 GMT
Subject: RFR: 8369442: ExitOnOutOfMemoryError should exit more gracefully
 [v2]
In-Reply-To: <moKnZOqMChLs9ZagjBhrooi-LhVGJRGE8YoN5nWYkSI=.959ad531-9f3d-4eb0-bb0a-13148af5d898@github.com>
References: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
 <moKnZOqMChLs9ZagjBhrooi-LhVGJRGE8YoN5nWYkSI=.959ad531-9f3d-4eb0-bb0a-13148af5d898@github.com>
Message-ID: <-WtruSSGNZoK8VxUHXc_I2hPLxJfxgduPxU32HgKlUM=.780b3027-e625-4511-b19b-2a02b7d91c42@github.com>

On Fri, 10 Oct 2025 06:12:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See RFE for more discussion. It seems we have a leeway in defining what "exit" means for `-XX:+ExitOnOutOfMemoryError`, and this PR does it more akin to `JVM_Halt`, rather than abrupt `os::_exit`. This gives VM a chance to shutdown some of its subsystems gracefully.
>> 
>> Comments welcome!
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [ ] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/utilities/debug.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Are we sure that `before_exit` can handle being called at any point between `set_init_completed` and when we start running user byte code. 

I know we have internally questioned the validity of the development flag `ExitOnFullCodeCache` which also can call `before_exit` very early, albiet it uses the non-halting version which is scarier.

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

PR Comment: https://git.openjdk.org/jdk/pull/27718#issuecomment-3388789658

From mchevalier at openjdk.org  Fri Oct 10 08:28:22 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 10 Oct 2025 08:28:22 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <4AzzqZKwkzxGFxIszBSwfAdT6lyEEMdveyzYXhpfJLI=.224d078f-87e7-4b04-97ff-fe67ca4df4aa@github.com>

On Thu, 9 Oct 2025 13:16:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Looks good to me.

There are a lot of `SomeType *name` that we are slowly converting into `SomeType* name` when we have an occasion. As you wish.

I'm also running some tests. I'll be back soon.

src/hotspot/share/opto/mulnode.cpp line 1264:

> 1262:   int count = 0;
> 1263:   if (const_shift_count(phase, this, &count) && (count & (bits_per_java_integer(bt) - 1)) == 0) {
> 1264:     // Shift by a multiple of 32/64 does nothing

I know it was there before, but I wonder if it's useful. Shouldn't something like `x << K` be idealized into `x << (K mod 32)` (or 64) by `mask_and_replace_shift_amount`, and then, we just need to treat `x << 0` in `Identity`. Not that it hurts or it's really complex...

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

PR Review: https://git.openjdk.org/jdk/pull/27725#pullrequestreview-3321957081
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2418898051

From sspitsyn at openjdk.org  Fri Oct 10 08:42:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 08:42:10 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I think `JvmtiExport::has_frame_pops` should just check if `thread->jvmti_thread_state()` is nullptr?and return false, and not try to create the state. Same with `JvmtiExport::continuation_yield_cleanup()`. This `JvmtiExport::get_jvmti_thread_state()` method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the `JvmtiThreadState` created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in `VTMS_unmount_begin` so we would leave the wrong state in the platform thread until the next transition.
>> 
>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a `!cont.entry()->is_virtual_thread()` check too?
>
>> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition.
> 
> Thank you, Patrico!
> I agree with this. Below is the patch for this change.
> 
> 
> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp
> index 077b3fec505..fa6ede86cd9 100644
> --- a/src/hotspot/share/prims/jvmtiExport.cpp
> +++ b/src/hotspot/share/prims/jvmtiExport.cpp
> @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) {
>    if (!can_post_frame_pop()) {
>      return false;
>    }
> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>    if (state == nullptr) {
>      return false;
>    }
> @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati
>    }
>  
>    assert(thread == JavaThread::current(), "must be");
> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>    if (state == nullptr) {
>      return;
>    }
> 
> 
>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?
> 
> Good idea. I was also thinking about it at some point.
> 
>> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
> 
> I can be but could you be more presize about the preempt case? What place do you mean?

> /author @sspitsyn

This suggestion came from Patricio. :)

> I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159.

Wrong assumptions. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388899792

From roland at openjdk.org  Fri Oct 10 08:44:24 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 10 Oct 2025 08:44:24 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  sort headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27725/files
  - new: https://git.openjdk.org/jdk/pull/27725/files/ba8dc6df..05ff54dc

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

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

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

From roland at openjdk.org  Fri Oct 10 08:44:25 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 10 Oct 2025 08:44:25 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <-2FHpMSA3_maSA1AokaCBLke5OL4FPFMKNUSz2CiXNM=.dec85f0d-be9b-490b-9a3d-15154fa891a1@github.com>

On Thu, 9 Oct 2025 13:16:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

I pushed a new commit that fixes the test failures because some headers were not properly sorted.

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

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3388906913

From roland at openjdk.org  Fri Oct 10 08:47:17 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 10 Oct 2025 08:47:17 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <4AzzqZKwkzxGFxIszBSwfAdT6lyEEMdveyzYXhpfJLI=.224d078f-87e7-4b04-97ff-fe67ca4df4aa@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <4AzzqZKwkzxGFxIszBSwfAdT6lyEEMdveyzYXhpfJLI=.224d078f-87e7-4b04-97ff-fe67ca4df4aa@github.com>
Message-ID: <0ydTWVqw0FMaH9tTpRnYDZ8vW1XeFzdb25r9Sx_AFMI=.a093ab46-187c-4532-82f5-5f5927a4d07e@github.com>

On Fri, 10 Oct 2025 08:23:19 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sort headers
>
> src/hotspot/share/opto/mulnode.cpp line 1264:
> 
>> 1262:   int count = 0;
>> 1263:   if (const_shift_count(phase, this, &count) && (count & (bits_per_java_integer(bt) - 1)) == 0) {
>> 1264:     // Shift by a multiple of 32/64 does nothing
> 
> I know it was there before, but I wonder if it's useful. Shouldn't something like `x << K` be idealized into `x << (K mod 32)` (or 64) by `mask_and_replace_shift_amount`, and then, we just need to treat `x << 0` in `Identity`. Not that it hurts or it's really complex...

Right. Maybe it's because `Identity` can be called with no previous call to `Ideal`: `PhaseIdealLoop::split_thru_phi()` for instance, even though, not sure it makes much of a difference here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2418961556

From mdoerr at openjdk.org  Fri Oct 10 09:20:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 09:20:07 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
Message-ID: <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>

On Fri, 10 Oct 2025 08:02:06 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cast compare_value to unsigned
>
> src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 186:
> 
>> 184:     : [dest]            "b"     (dest),
>> 185:       [exchange_value]  "r"     (exchange_value),
>> 186:                         "m"     (*dest)
> 
> The memory operands with constraint 'm' are unused. I think the intent was to express that `dest` is dereferenced to read and write memory at that location. But that's expressed with `memory` in the `clobber` section.
> These operands should be removed.

Do you know what "b" means? We use "r" at other places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419037761

From rrich at openjdk.org  Fri Oct 10 09:20:08 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 10 Oct 2025 09:20:08 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
 <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
Message-ID: <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>

On Fri, 10 Oct 2025 09:15:35 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 186:
>> 
>>> 184:     : [dest]            "b"     (dest),
>>> 185:       [exchange_value]  "r"     (exchange_value),
>>> 186:                         "m"     (*dest)
>> 
>> The memory operands with constraint 'm' are unused. I think the intent was to express that `dest` is dereferenced to read and write memory at that location. But that's expressed with `memory` in the `clobber` section.
>> These operands should be removed.
>
> Do you know what "b" means? We use "r" at other places.

It means base register (R0 not allowed). See PowerPC section in https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419042661

From mgronlun at openjdk.org  Fri Oct 10 09:21:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Oct 2025 09:21:11 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <Vl4TmeTRJc_zWZp52J9khIayGd6wTjPAMUP_irLIL-U=.0dc5efb1-cf81-477a-81e2-fa5f534907e5@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

Why is this change not getting a hotspot-jfr label?

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3389029340

From mli at openjdk.org  Fri Oct 10 09:26:21 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Oct 2025 09:26:21 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <b7HOAPNfezUdGKpVFIf9NUu2AjiA0ILCVP0IzbOFqnM=.c47725e6-f84b-4932-a779-96954666992d@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <b7HOAPNfezUdGKpVFIf9NUu2AjiA0ILCVP0IzbOFqnM=.c47725e6-f84b-4932-a779-96954666992d@github.com>
Message-ID: <f83An8LDCCHH0mUT3L42RCeaYtR9jtq63k04kBApNcY=.1638d04c-2f60-4cf8-9247-ed75421fed3d@github.com>

On Fri, 10 Oct 2025 02:47:09 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Mind you that the following tests explicitly are testing `-XX:-AlignVector` and won't work on hardware platforms without misaligned vector. But it doesn't seem to me reasonable to add a requirement like `@requires vm.opt.EnableVectorSupport == true` for them as they are superword tests. These tests were once enabled for RISC-V by: https://bugs.openjdk.org/browse/JDK-8352529. Maybe we should simply keep them disabled for this platform?

Simply distable them on riscv seems not a good idea.
Maybe add `@requires (os.arch != "riscv64" | !vm.opt.AlignVector))`?

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

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3389044810

From mgronlun at openjdk.org  Fri Oct 10 09:27:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Oct 2025 09:27:24 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <7HeGUHbKpK4hPMNj3_qkp3mTEjI5ucNXFwKziLd1Nx8=.d83f286e-e24c-47a7-85f8-e200b0d4dca8@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

Introducing a separate jdk.ClassFileDefine event seems gratuitous. Why is it not enabled by default? 

What problem is being addressed again?

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3389043586

From mdoerr at openjdk.org  Fri Oct 10 09:28:25 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 09:28:25 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
 <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
 <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>
Message-ID: <MoQdICqMIf7ipKCiB6GOYQMxE3Wr925nAItJRVzBPqg=.f40f232c-3f5b-4b35-b4f4-5597b188c9b8@github.com>

On Fri, 10 Oct 2025 09:17:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Do you know what "b" means? We use "r" at other places.
>
> It means base register (R0 not allowed). See PowerPC section in https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html

Ah, so we should use "b" consistently for memory addresses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419062961

From mli at openjdk.org  Fri Oct 10 09:29:29 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Oct 2025 09:29:29 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v5]
In-Reply-To: <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
Message-ID: <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>

On Fri, 10 Oct 2025 08:09:27 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the use of unaligned_access

src/hotspot/cpu/riscv/globals_riscv.hpp line 95:

> 93:   product(bool, UseConservativeFence, false,                                     \
> 94:           "Extend i for r and o for w in the pred/succ flags of fence")          \
> 95:   product(bool, AvoidUnalignedAccesses, true,                                    \

Not sure what's the rule to remove this riscv specific options. Can we just simply delete it in this pr?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2419066002

From mgronlun at openjdk.org  Fri Oct 10 09:35:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Oct 2025 09:35:28 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <tsehEEs4x9-trnunJ1dlxVPp8b5j_A11Va0fR6b0ytk=.5ae59369-3d86-4491-a829-149ba8a5c59c@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <tsehEEs4x9-trnunJ1dlxVPp8b5j_A11Va0fR6b0ytk=.5ae59369-3d86-4491-a829-149ba8a5c59c@github.com>
Message-ID: <R26kopJD37vsr7bAUroqJEf8Bf9160kh4lxbGNiRPt0=.e670ebe8-0c7e-42c7-962f-e024c0218f22@github.com>

On Fri, 10 Oct 2025 06:48:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The evolution of JFR events isn't clear to me so I don't know if adding a field is compatible or not for programs that are processing recordings. (I'm just trying to understand why a new not-enabled-by-default event is added instead of adding a field to the existing ClassDefine event.
> 
> The existing event is emitted in SystemDictionary::define_instance_class, the new event emits it from JVM_DefineClassXXX. Is this because it was awkward to get at cfs->source from the SD code?
> 
> I assume that a test will be added as it would be easy to refactor code and not record the event if enabled.
> 
> Using "jvm" as the URI scheme when there is no source is a bit strange. There will be custom class loaders that don't provide a code source, do you really want these to use this source in the event?

Adding a field to an existing event is non-detrimental, equivalent to extending a table with a new column in a database.

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3389076928

From wenanjian at openjdk.org  Fri Oct 10 09:44:02 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 09:44:02 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <XcJlM3nl16rnId7eeLmnG2qjMLCIc0HrD6h9Vb0tdg0=.4a6b996c-aa37-498a-89b6-cb302c3bc544@github.com>

> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  modify the global flag change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27510/files
  - new: https://git.openjdk.org/jdk/pull/27510/files/be963cdc..6eb1dd95

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

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

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

From wenanjian at openjdk.org  Fri Oct 10 09:44:04 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 09:44:04 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
Message-ID: <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>

On Fri, 10 Oct 2025 09:26:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify the global flag change
>
> src/hotspot/cpu/riscv/globals_riscv.hpp line 95:
> 
>> 93:   product(bool, UseConservativeFence, false,                                     \
>> 94:           "Extend i for r and o for w in the pred/succ flags of fence")          \
>> 95:   product(bool, AvoidUnalignedAccesses, true,                                    \
> 
> Not sure what's the rule to remove this riscv specific options. Can we just simply delete it in this pr?

Ok I understand, I have deleted the change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2419106355

From mdoerr at openjdk.org  Fri Oct 10 09:47:26 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 09:47:26 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <MoQdICqMIf7ipKCiB6GOYQMxE3Wr925nAItJRVzBPqg=.f40f232c-3f5b-4b35-b4f4-5597b188c9b8@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
 <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
 <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>
 <MoQdICqMIf7ipKCiB6GOYQMxE3Wr925nAItJRVzBPqg=.f40f232c-3f5b-4b35-b4f4-5597b188c9b8@github.com>
Message-ID: <SHQzG3Ocxg0lknoqa9HjXPZ3L4Hqb7dio5-gO4ZMgw0=.e339016b-8cc2-4aaa-aab8-b0909be5e74a@github.com>

On Fri, 10 Oct 2025 09:25:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> It means base register (R0 not allowed). See PowerPC section in https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
>
> Ah, so we should use "b" consistently for memory addresses.

To be more precise: In this case (lwarx, stwcx, ...), the operand we are using supports R0. So "r" is also fine. But some other functions use lwz, ... which can't use R0.
So, those with "simple guard" need to use "b", the other ones can also use "r".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419115953

From ayang at openjdk.org  Fri Oct 10 09:47:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 09:47:28 GMT
Subject: RFR: 8369440: Remove RootResolverMarkScope and
 RootSetClosureMarkScope [v2]
In-Reply-To: <FW-6HyGpFifQB3PhAMF03r_MiIppM7N2iIXXXdoWJ0s=.fa8afb23-7e92-4341-aa06-1e42716873e6@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
 <FW-6HyGpFifQB3PhAMF03r_MiIppM7N2iIXXXdoWJ0s=.fa8afb23-7e92-4341-aa06-1e42716873e6@github.com>
Message-ID: <0gi0QCHiRoDf2CwyicSZDRqQVANQGY7v3rvdZ2oCGEY=.d1b66b70-c5aa-46c7-9dbf-686f978725a1@github.com>

On Fri, 10 Oct 2025 00:28:30 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> `RootResolverMarkScope` and `RootSetClosureMarkScope` are not needed, since the code using them does not seem to require `nmethod::oops_do_marking_prologue`.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27729#pullrequestreview-3322252007

From mdoerr at openjdk.org  Fri Oct 10 09:47:27 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 09:47:27 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <SHQzG3Ocxg0lknoqa9HjXPZ3L4Hqb7dio5-gO4ZMgw0=.e339016b-8cc2-4aaa-aab8-b0909be5e74a@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
 <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
 <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>
 <MoQdICqMIf7ipKCiB6GOYQMxE3Wr925nAItJRVzBPqg=.f40f232c-3f5b-4b35-b4f4-5597b188c9b8@github.com>
 <SHQzG3Ocxg0lknoqa9HjXPZ3L4Hqb7dio5-gO4ZMgw0=.e339016b-8cc2-4aaa-aab8-b0909be5e74a@github.com>
Message-ID: <wMR5mXWVBmzEEBW8aBjPJ55HJFwszrbsPo4QPTj1ArY=.7de16f09-d26f-4874-a875-71441091f329@github.com>

On Fri, 10 Oct 2025 09:42:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ah, so we should use "b" consistently for memory addresses.
>
> To be more precise: In this case (lwarx, stwcx, ...), the operand we are using supports R0. So "r" is also fine. But some other functions use lwz, ... which can't use R0.
> So, those with "simple guard" need to use "b", the other ones can also use "r".

Always using "b" should do no harm and avoid copy&paste bugs in the future. So that's probably better?
(We could also usr "cr0" in clobber list, but "cc" should be good enough, too.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419119497

From rrich at openjdk.org  Fri Oct 10 09:54:23 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 10 Oct 2025 09:54:23 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
Message-ID: <IQyBNwYZfUN89a52rKlounL3l-ASifUjahUI4y_0gsc=.6451c485-5064-4377-b839-9e7b64de503d@github.com>

On Fri, 10 Oct 2025 07:51:45 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cast compare_value to unsigned

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 165:

> 163:                                                    T exchange_value,
> 164:                                                    atomic_memory_order order) const {
> 165:   // Note that xchg doesn't necessarily do an acquire

Suggestion:

  STATIC_ASSERT(4 == sizeof(T));
  // Note that xchg doesn't necessarily do an acquire

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419108660

From rrich at openjdk.org  Fri Oct 10 09:54:26 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 10 Oct 2025 09:54:26 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v6]
In-Reply-To: <wMR5mXWVBmzEEBW8aBjPJ55HJFwszrbsPo4QPTj1ArY=.7de16f09-d26f-4874-a875-71441091f329@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <ltKQiwboYdAMgGv2wHyElei2tkE7_i9e-Wu5a8fK_tc=.829d3ab6-a306-4f40-8027-dbce68962764@github.com>
 <C1iFvQnV1bE1HdE7rO3qc18TQIW5AVwZ7uUEq3BxZcw=.2a1245cc-df31-4dc2-944d-1ff725aba4ab@github.com>
 <Xf_KDtvFeO4_H7SQrk75457S6KUawncMNjZhbR7x48Y=.360f84b6-7186-4787-bd3a-639539a5a047@github.com>
 <8c7YK5hqxlg4ABAkItVRtYe30_uOsaJvrQN1Ddl5Keg=.f1a45745-1ddc-4d24-99ba-dc08cde3c8db@github.com>
 <MoQdICqMIf7ipKCiB6GOYQMxE3Wr925nAItJRVzBPqg=.f40f232c-3f5b-4b35-b4f4-5597b188c9b8@github.com>
 <SHQzG3Ocxg0lknoqa9HjXPZ3L4Hqb7dio5-gO4ZMgw0=.e339016b-8cc2-4aaa-aab8-b0909be5e74a@github.com>
 <wMR5mXWVBmzEEBW8aBjPJ55HJFwszrbsPo4QPTj1ArY=.7de16f09-d26f-4874-a875-71441091f329@github.com>
Message-ID: <H7yJh9tIoUzcBOapTi0OnfWept3vr8-hsZNTVBwr8b8=.baf11b1d-632e-4a66-beb7-ae9d7444126e@github.com>

On Fri, 10 Oct 2025 09:44:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> To be more precise: In this case (lwarx, stwcx, ...), the operand we are using supports R0. So "r" is also fine. But some other functions use lwz, ... which can't use R0.
>> So, those with "simple guard" need to use "b", the other ones can also use "r".
>
> Always using "b" should do no harm and avoid copy&paste bugs in the future. So that's probably better?
> (We could also usr "cr0" in clobber list, but "cc" should be good enough, too.)

Yes. I'd say so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2419137667

From mdoerr at openjdk.org  Fri Oct 10 09:56:27 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 09:56:27 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v8]
In-Reply-To: <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>
Message-ID: <6fF64mBIPwkM1zCjemf94JywcraF2mbv_YckKSxw8O4=.61cff790-d171-4f8d-9d63-cf8db16ad0d4@github.com>

On Fri, 10 Oct 2025 03:41:48 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix s390 compilation failure
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Unfortunately, this is no longer correct for PPC64 because the isync instruction is missing on some paths, now. While this looks good for other platforms, can you revert only PPC64 to the previous version, please?

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3322283211

From mli at openjdk.org  Fri Oct 10 10:10:46 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Oct 2025 10:10:46 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
 <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
Message-ID: <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>

On Fri, 10 Oct 2025 09:39:04 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/globals_riscv.hpp line 95:
>> 
>>> 93:   product(bool, UseConservativeFence, false,                                     \
>>> 94:           "Extend i for r and o for w in the pred/succ flags of fence")          \
>>> 95:   product(bool, AvoidUnalignedAccesses, true,                                    \
>> 
>> Not sure what's the rule to remove this riscv specific options. Can we just simply delete it in this pr?
>
> Ok I understand, I have deleted the change

Sorry, I did not mean you should delete the `AvoidUnalignedAccesses`. I just don't know the exact rule about how to delete it.
Please hold on for a while to get a comment on this part of change from others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2419188693

From snazarkin at azul.com  Fri Oct 10 10:14:27 2025
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Fri, 10 Oct 2025 10:14:27 +0000
Subject: virtual/stress/PingPon fails on win-arm64
Message-ID: <20867C7A-417A-446C-8AAA-CFCAC75A467A@azul.com>

Hi!

We have encountered an issue with the PingPong [1] stress test with JDK21 (and JDK 25) run on Win-ARM64, other platforms seem unaffected. I haven't found any record of this issue (except valhalla related [2]), so I'd like to check if it's a known problem.

The problem is reproducible with C2 only

============
#21 "" virtual java.base/java.lang.VirtualThread.park(VirtualThread.java:596) java.base/java.lang.System$2.parkVirtualThread(System.java:2643) java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54) java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:369) java.base/java.util.concurrent.LinkedTransferQueue$DualNode.await(LinkedTransferQueue.java:458) java.base/java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:613) 
java.base/java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1257) 
PingPong$LTQExchanger.take(PingPong.java:128) PingPong.lambda$main$0(PingPong.java:68) 
java.base/java.lang.VirtualThread.run(VirtualThread.java:329) 

#23 "" virtual java.base/java.lang.VirtualThread.park(VirtualThread.java:596) 
java.base/java.lang.System$2.parkVirtualThread(System.java:2643) 
java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54) 
java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:369) 
java.base/java.util.concurrent.LinkedTransferQueue$DualNode.await(LinkedTransferQueue.java:458) java.base/java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:613) 
java.base/java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1257) 
PingPong$LTQExchanger.take(PingPong.java:128) 
PingPong.lambda$main$1(PingPong.java:81) 
java.base/java.lang.VirtualThread.run(VirtualThread.java:329)
===========


Sergey


[1] https://github.com/openjdk/jdk21u/blob/master/test/jdk/java/lang/Thread/virtual/stress/PingPong.java
[2] https://bugs.openjdk.org/browse/JDK-8314996

From ayang at openjdk.org  Fri Oct 10 10:24:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 10:24:19 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v11]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang 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 15 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - ... and 5 more: https://git.openjdk.org/jdk/compare/266d2e3f...dca26616

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/e02d0bf8..dca26616

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=09-10

  Stats: 2992 lines in 81 files changed: 2039 ins; 737 del; 216 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

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

From sspitsyn at openjdk.org  Fri Oct 10 10:25:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 10:25:53 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>
Message-ID: <0O2-w0R94vfTJjRk7iVnL2EBImcfgmYNLHpI-gXEHlQ=.7937917d-80d9-493c-ab42-747001694da9@github.com>

On Fri, 10 Oct 2025 08:39:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition.
>> 
>> Thank you, Patrico!
>> I agree with this. Below is the patch for this change.
>> 
>> 
>> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp
>> index 077b3fec505..fa6ede86cd9 100644
>> --- a/src/hotspot/share/prims/jvmtiExport.cpp
>> +++ b/src/hotspot/share/prims/jvmtiExport.cpp
>> @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) {
>>    if (!can_post_frame_pop()) {
>>      return false;
>>    }
>> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
>> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>>    if (state == nullptr) {
>>      return false;
>>    }
>> @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati
>>    }
>>  
>>    assert(thread == JavaThread::current(), "must be");
>> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
>> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>>    if (state == nullptr) {
>>      return;
>>    }
>> 
>> 
>>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?
>> 
>> Good idea. I was also thinking about it at some point.
>> 
>>> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
>> 
>> I can be but could you be more presize about the preempt case? What place do you mean?
>
>> /author @sspitsyn
> 
> This suggestion came from Patricio. :)
> 
>> I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159.
> 
> Wrong assumptions. :) For consistency with `JvmtiExport::continuation_yield_cleanup()`.

> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?

This is one more suggestion from Patricio (I'm testing it now):


diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 33b4f2bf488..3e509e71551 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -1626,7 +1626,7 @@ static void invalidate_jvmti_stack(JavaThread* thread) {
 }
 
 static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) {
-  if (JvmtiExport::has_frame_pops(thread)) {
+  if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) {
     int num_frames = num_java_frames(cont);
 
     ContinuationWrapper::SafepointOp so(Thread::current(), cont);

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3389242915

From alanb at openjdk.org  Fri Oct 10 10:28:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 10:28:44 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <Sdk6rbROqXt4UXwxgUkUsit9Xwso7xBYr-w15LfiijY=.f96c37d9-3002-4523-ba7f-32b78b5be6a7@github.com>

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Just to add to Chen and David's comments and to give more context. JEP 486 was a huge change. To keep things manageable the proposal/agreement was to keep the changes to src/hotspot as minimal as possible.  The callout to checkPackageAccess from the dictionary code and the inherited ACC has to be removed, but that was mostly it. Coleen followed up quickly with a huge removal of the ProtectionDomain code. For JVM_FindClassFromCaller, a non-null caller would have been used to get its PD. Not needed now so it does look like another pass is needed to do further removal/cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/27735#issuecomment-3389253467

From wenanjian at openjdk.org  Fri Oct 10 10:51:13 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Fri, 10 Oct 2025 10:51:13 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
 <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
 <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>
Message-ID: <awsyLcrSdQHwSbPZC1mtAuIEsck_2Ng_2UNCySDylAU=.bcc75894-3826-4fd6-9849-2db9fa9d856b@github.com>

On Fri, 10 Oct 2025 10:07:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Ok I understand, I have deleted the change
>
> Sorry, I did not mean you should delete the `AvoidUnalignedAccesses`. I just don't know the exact rule about how to delete it.
> Please hold on for a while to get a comment on this part of change from others.

Oh, I misunderstood, I will try to check the rule and test tier1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2419399165

From duke at openjdk.org  Fri Oct 10 10:55:02 2025
From: duke at openjdk.org (Larry Cable)
Date: Fri, 10 Oct 2025 10:55:02 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <5wmcrcVHnwuibED77Ud3fdgXIK_pcEQijGZ34GOavp0=.406ec398-87f9-47ff-9aa1-47b0b4fd4117@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

in previous discussions regarding adding fields to existing JFR (jdk) events I concluded (based on feedback from the JFR team) that this was undesirable hence the new event.

I will investigate the feasibility of adding this metadata to the existing event(s)

knowing where a class originated from, in addition to the knowledge that it has been loaded etc is of particular value in pre-existing auditing and debugging scenarios.

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

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3389346359

From jsikstro at openjdk.org  Fri Oct 10 11:38:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 11:38:07 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v11]
In-Reply-To: <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@github.com>
Message-ID: <-VmhyEUjFQL-ij7T7MqH8QbvkJZyhBxbhxdwe91T2AI=.a2978773-192d-40d3-b6d6-a9a0cf288c3c@github.com>

On Fri, 10 Oct 2025 10:24:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/edcedec4...dca26616

I have a few small comments, but I think this looks pretty good now.

src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 368:

> 366:         new_region = MemRegion(ps->end(), end());
> 367:       }
> 368:     }

This is technically fine, but maybe we can combine the else and the if to something like below to fit better with the comments?

if (i == 0) { // Bottom chunk
...
} else if (i < lgrp_spaces()->length() - 1) { // Middle chunks
...
} else { // Top chunk
...
}

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3309512696
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2419401651

From jsikstro at openjdk.org  Fri Oct 10 11:38:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 11:38:10 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v9]
In-Reply-To: <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>
Message-ID: <tuIt3d_WMEcLdS3_o_xTmEvD5ZE78mvluSE8Vkwh8Tw=.6fbb0479-becc-433c-8b35-503c86ef9247@github.com>

On Fri, 3 Oct 2025 14:44:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

src/hotspot/share/gc/parallel/mutableNUMASpace.hpp line 129:

> 127: 
> 128:   size_t _base_space_size;
> 129:   void set_base_space_size(size_t v)                 { _base_space_size = v;      }

These are unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2410189143

From syan at openjdk.org  Fri Oct 10 11:55:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 11:55:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <th0xj31xU5BouCinlYO39yensVKK5fzapO7AQ1Ce5-M=.0d8ac8e9-880e-4a88-a1f5-9ec3d08ed752@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389686651

From fandreuzzi at openjdk.org  Fri Oct 10 11:57:07 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 11:57:07 GMT
Subject: RFR: 8369440: Remove RootResolverMarkScope and
 RootSetClosureMarkScope
In-Reply-To: <DZnC0cHpilY1agYC-PY9gMywjZSeUl3zjOY1KbGbG-4=.3f211070-4aee-417a-a58c-37af02826f5b@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
 <DZnC0cHpilY1agYC-PY9gMywjZSeUl3zjOY1KbGbG-4=.3f211070-4aee-417a-a58c-37af02826f5b@github.com>
Message-ID: <Aqmd3jRHcn8750MwyKU990zA-fTA-qdD7bs9k5suFDM=.219603a1-0011-4a77-b198-20a94e415512@github.com>

On Thu, 9 Oct 2025 15:03:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> `RootResolverMarkScope` and `RootSetClosureMarkScope` are not needed, since the code using them does not seem to require `nmethod::oops_do_marking_prologue`.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Preexisting: why the two "*MarkScope" are needed at all? (I can't find the code that actually requires the use of `NMethodMarkingScope`.)

Thanks for the review @albertnetymk

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27729#issuecomment-3389688062

From duke at openjdk.org  Fri Oct 10 11:57:10 2025
From: duke at openjdk.org (duke)
Date: Fri, 10 Oct 2025 11:57:10 GMT
Subject: RFR: 8369440: Remove RootResolverMarkScope and
 RootSetClosureMarkScope [v2]
In-Reply-To: <FW-6HyGpFifQB3PhAMF03r_MiIppM7N2iIXXXdoWJ0s=.fa8afb23-7e92-4341-aa06-1e42716873e6@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
 <FW-6HyGpFifQB3PhAMF03r_MiIppM7N2iIXXXdoWJ0s=.fa8afb23-7e92-4341-aa06-1e42716873e6@github.com>
Message-ID: <0B3sPO6ZbOyMQzeYsMmuTajC4qwMbBp017ckE5wyW0E=.81238288-fe60-4e1f-9b07-fd631f2fd7aa@github.com>

On Fri, 10 Oct 2025 00:28:30 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> `RootResolverMarkScope` and `RootSetClosureMarkScope` are not needed, since the code using them does not seem to require `nmethod::oops_do_marking_prologue`.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

@fandreuz 
Your change (at version 21cbbcb9b180287ce64996429a4a26e9c4eca322) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27729#issuecomment-3389693739

From syan at openjdk.org  Fri Oct 10 12:00:06 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 10 Oct 2025 12:00:06 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <4WET954Oj6nVqTC0d9fTAAFyjWoUnu0EsGy7VM-V9do=.b4957a46-6b4e-4e74-bfde-33291622fde4@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Hi, is there a way to get the jtreg8.1 binary, except build from source.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3389704303

From mchevalier at openjdk.org  Fri Oct 10 12:20:38 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 10 Oct 2025 12:20:38 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>
Message-ID: <QENriVylwLRHp05UlYy-YA2kyqrfVNJcGgOHAR6IyTA=.f26a6227-bb3c-4e62-9aac-6f170f0c4d05@github.com>

On Fri, 10 Oct 2025 08:44:24 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change refactor code that's similar for LShiftINode and
>> LShiftLNode into shared methods. I also added extra test cases to
>> cover all transformations.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sort headers

Testing looks good (up to the now fixed inclusion order). I'm happy: it looks good, it's significant sharing, it's no giving some unreadable code that keeps making cases between long and int, nice new tests...

An idea (not a suggestion, just something that crossed my mind, take it more as a thought experiment): we could also parametrize everything not with a `BasicType` parameter but a template parameter (since `IdealIL` and co are invoked with literal values). It wouldn't change much, but for instance it would allow to replace the assert in `java_shift_left` and friends with static checks (I have a bias toward static checks).

-------------

Marked as reviewed by mchevalier (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27725#pullrequestreview-3323043825

From ayang at openjdk.org  Fri Oct 10 12:39:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 12:39:21 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v12]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/dca26616..a6bafe71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=10-11

  Stats: 12 lines in 2 files changed: 0 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

PR: https://git.openjdk.org/jdk/pull/26700

From dbriemann at openjdk.org  Fri Oct 10 13:31:33 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Fri, 10 Oct 2025 13:31:33 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v7]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/9e6fecd0..d182588e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27650&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27650&range=05-06

  Stats: 36 lines in 1 file changed: 1 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/27650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27650/head:pull/27650

PR: https://git.openjdk.org/jdk/pull/27650

From sgehwolf at openjdk.org  Fri Oct 10 13:38:56 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Oct 2025 13:38:56 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
Message-ID: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>

Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.

It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.

All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.

All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.

While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.

Testing (looking good):
- [x] GHA
- [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
- [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.

Thoughts? Opinions?

-------------

Commit messages:
 - Fix print_container_info output
 - whitespace clean-ups and other small fixes
 - Fix log format in container macro and scanf format
 - Fix duplicate include in osContainer_linux
 - 8365606: Container code should not be using jlong/julong

Changes: https://git.openjdk.org/jdk/pull/27743/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365606
  Stats: 1247 lines in 16 files changed: 477 ins; 111 del; 659 mod
  Patch: https://git.openjdk.org/jdk/pull/27743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27743/head:pull/27743

PR: https://git.openjdk.org/jdk/pull/27743

From sgehwolf at openjdk.org  Fri Oct 10 13:38:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Oct 2025 13:38:57 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <23599yVgDZSAOeHbVlxG2edQxSRdmtr42J60EfWlAQ0=.a25ab0c1-8f01-4d96-8182-30e073a8a03b@github.com>

On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

## Testing details:

**cgroup v2 F42 (docker):**

Passed: containers/cgroup/CgroupSubsystemFactory.java
Passed: containers/cgroup/TestContainerized.java
Passed: containers/docker/DockerBasicTest.java
Passed: containers/docker/ShareTmpDir.java
Passed: containers/docker/TestContainerInfo.java
Passed: containers/docker/TestCPUAwareness.java
Passed: containers/docker/TestCPUSets.java
Passed: containers/docker/TestJcmd.java
Passed: containers/docker/TestJcmdWithSideCar.java
Passed: containers/docker/TestJFREvents.java
Passed: containers/docker/TestJFRNetworkEvents.java
Passed: containers/docker/TestJFRWithJMX.java
Passed: containers/docker/TestLimitsUpdating.java
Passed: containers/docker/TestMemoryAwareness.java
Passed: containers/docker/TestMemoryWithCgroupV1.java
Passed: containers/docker/TestMemoryWithSubgroups.java
Passed: containers/docker/TestMisc.java
Passed: containers/docker/TestPids.java
Passed: containers/systemd/SystemdMemoryAwarenessTest.java
Passed: jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java
Passed: jdk/internal/platform/cgroup/CgroupV2SubsystemControllerTest.java
Passed: jdk/internal/platform/cgroup/TestCgroupMetrics.java
Passed: jdk/internal/platform/cgroup/TestCgroupSubsystemController.java
Passed: jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java
Passed: jdk/internal/platform/cgroup/TestSystemSettings.java
Passed: jdk/internal/platform/docker/TestDockerBasic.java
Passed: jdk/internal/platform/docker/TestDockerCpuMetrics.java
Passed: jdk/internal/platform/docker/TestDockerMemoryMetrics.java
Passed: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java
Passed: jdk/internal/platform/docker/TestGetFreeSwapSpaceSize.java
Passed: jdk/internal/platform/docker/TestLimitsUpdating.java
Passed: jdk/internal/platform/docker/TestPidsLimit.java
Passed: jdk/internal/platform/docker/TestSystemMetrics.java
Passed: jdk/internal/platform/docker/TestUseContainerSupport.java
Test results: passed: 34


**cgroup v2 F39 (docker):**

Passed: containers/cgroup/CgroupSubsystemFactory.java
Passed: containers/cgroup/TestContainerized.java
Passed: containers/docker/DockerBasicTest.java
Passed: containers/docker/ShareTmpDir.java
Passed: containers/docker/TestContainerInfo.java
Passed: containers/docker/TestCPUAwareness.java
Passed: containers/docker/TestCPUSets.java
Passed: containers/docker/TestJcmd.java
Passed: containers/docker/TestJcmdWithSideCar.java
Passed: containers/docker/TestJFREvents.java
Passed: containers/docker/TestJFRNetworkEvents.java
Passed: containers/docker/TestJFRWithJMX.java
Passed: containers/docker/TestLimitsUpdating.java
Passed: containers/docker/TestMemoryAwareness.java
Passed: containers/docker/TestMemoryWithCgroupV1.java
Passed: containers/docker/TestMemoryWithSubgroups.java
Passed: containers/docker/TestMisc.java
Passed: containers/docker/TestPids.java
Passed: containers/systemd/SystemdMemoryAwarenessTest.java
Test results: passed: 19


**cgroup v1 RHEL 8 (podman):**

Passed: containers/cgroup/CgroupSubsystemFactory.java
Passed: containers/cgroup/TestContainerized.java
Passed: containers/docker/DockerBasicTest.java
Passed: containers/docker/ShareTmpDir.java
Passed: containers/docker/TestContainerInfo.java
Passed: containers/docker/TestCPUAwareness.java
Passed: containers/docker/TestCPUSets.java
Passed: containers/docker/TestJcmd.java
Passed: containers/docker/TestJcmdWithSideCar.java
Passed: containers/docker/TestJFREvents.java
Passed: containers/docker/TestJFRNetworkEvents.java
Passed: containers/docker/TestJFRWithJMX.java
Passed: containers/docker/TestLimitsUpdating.java
Passed: containers/docker/TestMemoryAwareness.java
Passed: containers/docker/TestMemoryWithCgroupV1.java
Passed: containers/docker/TestMemoryWithSubgroups.java
Passed: containers/docker/TestMisc.java
Passed: containers/docker/TestPids.java
Passed: containers/systemd/SystemdMemoryAwarenessTest.java
Test results: passed: 19; skipped: 1


Note: The skipped test on RHEL 8 is `TestContainerInfo` which checks `cgv2` functionality only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3390060127

From eosterlund at openjdk.org  Fri Oct 10 13:48:38 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 10 Oct 2025 13:48:38 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v2]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <xgl6rFVWMGfndCOgAeIc_7txlymPYDWRqjWRAKljGVw=.b46ec7ca-7364-4a7b-a98f-af999655abb4@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Polish printout
 - test polishing
 - more comments from stefank
 - comments from stefank

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/ae782dda..23ef68fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=00-01

  Stats: 54 lines in 10 files changed: 35 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From mbaesken at openjdk.org  Fri Oct 10 14:00:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 14:00:16 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails
Message-ID: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>

Slowdebug builds without CDS fail, this was noticed on AIX.
On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :


/jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
/jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
collect2: error: ld returned 1 exit status

-------------

Commit messages:
 - JDK-8369560

Changes: https://git.openjdk.org/jdk/pull/27744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369560
  Stats: 8 lines in 3 files changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27744/head:pull/27744

PR: https://git.openjdk.org/jdk/pull/27744

From mdoerr at openjdk.org  Fri Oct 10 14:00:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 14:00:16 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <P66CoIWEMH0vN5UWNaVxkEVV89TqaMQhabPZcbQSzgQ=.9feaa231-277c-4aa4-a32f-c9147b0e7427@github.com>

On Fri, 10 Oct 2025 13:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

Thanks for fixing it! Alternatively, you could use the `CDS_ONLY` macro for single statements. Would make it a bit shorter. But, I'm ok with either version.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27744#pullrequestreview-3323733575

From mbaesken at openjdk.org  Fri Oct 10 14:16:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Oct 2025 14:16:50 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <uOZtmr8dDi-ONPOGC81vMNYtJzEIwM4DwnbKzI5eRIo=.80f15731-1823-4f99-b1dd-194527e3afe0@github.com>

On Fri, 10 Oct 2025 13:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

Thanks for the review !
With this change Linux slowdebug without CDS builds again ; AIX slowdebug  does not have the link error any more, but faces a TOC issue. But this is something to be addressed elsewhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27744#issuecomment-3390384641

From jsikstro at openjdk.org  Fri Oct 10 14:16:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 14:16:55 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v12]
In-Reply-To: <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@github.com>
Message-ID: <Tjx_n1Q6Z-w9m2iKDFSKLXIxzlLudrbdfi48gBbeHXw=.9b56cafd-7ac6-4bfe-8ee2-0b8cd7a8e929@github.com>

On Fri, 10 Oct 2025 12:39:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by jsikstro (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3323841370

From mdoerr at openjdk.org  Fri Oct 10 14:31:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 14:31:12 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v7]
In-Reply-To: <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
Message-ID: <94s6JQYYjSkoKEJUXN7RZuRXXzQ0egfgB2B1B3U-leo=.913d059f-b755-4273-9d31-9c8673605724@github.com>

On Fri, 10 Oct 2025 13:31:33 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for fixing it!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3323934743

From asmehra at openjdk.org  Fri Oct 10 14:34:40 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 14:34:40 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v9]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Revert ppc64 changes
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/4eb89b8b..c81f3805

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=07-08

  Stats: 19 lines in 1 file changed: 9 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

PR: https://git.openjdk.org/jdk/pull/27676

From aph at openjdk.org  Fri Oct 10 14:34:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Oct 2025 14:34:54 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v14]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <f9kaFmzgFrbrhJbMvPNHiGbQ-qXC1azpgd7TcIdMiZk=.db216df6-8665-437b-97da-2dac60e79121@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Add missing WX setter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/6a7faf21..5a1a452b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=12-13

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From asmehra at openjdk.org  Fri Oct 10 14:38:32 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 14:38:32 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v8]
In-Reply-To: <6fF64mBIPwkM1zCjemf94JywcraF2mbv_YckKSxw8O4=.61cff790-d171-4f8d-9d63-cf8db16ad0d4@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <YeQ4e4Dl_chwwmRHumqDjwSr3UPX83LtQsrd86Ck2aE=.49d444b0-0ee3-4565-9893-4129279b51bf@github.com>
 <6fF64mBIPwkM1zCjemf94JywcraF2mbv_YckKSxw8O4=.61cff790-d171-4f8d-9d63-cf8db16ad0d4@github.com>
Message-ID: <Qsrd8htjBMtILZ6zkLV33QAHd5NH-sJpQ6LDqbtBCeU=.34d30cb7-6775-4675-b18f-9ce0f4858c8e@github.com>

On Fri, 10 Oct 2025 09:53:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Unfortunately, this is no longer correct for PPC64 because the isync instruction is missing on some paths, now. While this looks good for other platforms, can you revert only PPC64 to the previous version, please?

@TheRealMDoerr thanks for catching the bug. The resolved non-static case is missing the isync. Reverted the ppc changes as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3390508507

From mgronlun at openjdk.org  Fri Oct 10 14:47:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Oct 2025 14:47:08 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <2EF1whYIVC4qpXKNQJIYsxK6eLqfI89YWn0HjCxNjH4=.053b510f-fbd0-4ccd-a835-c235a35716c9@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

Can you please give an example URL for a class definition? I am concerned about whether this is high cardinality strings (for path/name.class) or a lot of reuse (for paths). We should only represent a URL once, which makes me think that the field type should be symbol instead of string.

For that, we would need a concurrent symbol table, which I have already planned in other changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3390552142

From rrich at openjdk.org  Fri Oct 10 14:48:44 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 10 Oct 2025 14:48:44 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v7]
In-Reply-To: <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
Message-ID: <n0Cu4ALN4BnqrxpNNwB0YEKJVo3TZ9MWsD1CoJC0dM4=.86e9a683-442e-44b2-9d06-75d3c47311d8@github.com>

On Fri, 10 Oct 2025 13:31:33 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Looks good.
Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3324038480

From eastigeevich at openjdk.org  Fri Oct 10 14:51:58 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 10 Oct 2025 14:51:58 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <udR4_Zp0x4HM_pCGEgHxbeKIDteQS_u8m1snDE3snVo=.04f42bce-1f43-473e-bf63-14b337f60c4c@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <VAIlgrpsyng8nOzhUTaV0C9A_1arm39f6P5QQVzLHcw=.a8824b3e-bfe9-4679-b464-33780e5b0750@github.com>
 <udR4_Zp0x4HM_pCGEgHxbeKIDteQS_u8m1snDE3snVo=.04f42bce-1f43-473e-bf63-14b337f60c4c@github.com>
Message-ID: <ec3Cob9spYC-xa5i9o3DoY2RBPHulR6-snfIKhp4vS4=.e5273fad-7003-48e8-9e77-2f248338a763@github.com>

On Thu, 9 Oct 2025 17:01:16 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1337:
>> 
>>> 1335:   // - relocInfo::static_call_type
>>> 1336:   // - relocInfo::virtual_call_type
>>> 1337:   // Trampolines may be emitted immediately or deferred until stub finalization,
>> 
>> "... until stub" -> "until CodeBuffer"
>
> Well, the state is called `_finalize_stubs` and there's `CodeBuffer::finalize_stubs()` but I can see how "stub" can be confused with non-nmethod runtime stubs, so yeah, I'll reword it.

`_finalize_stubs` means to finally generate all stubs in an nmethod. This includes stubs to interpreter, trampolines. 

Yes, there might be a confusion with global stub code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2420641174

From pchilanomate at openjdk.org  Fri Oct 10 14:56:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 14:56:15 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
> 
> I can be but could you be more presize about the preempt case? What place do you mean?
>
So after freezing for the preempt case we should also call `invalidate_jvmti_stack()` in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3390600355

From cstein at openjdk.org  Fri Oct 10 15:13:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 10 Oct 2025 15:13:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <qJI-1Ab3I1HRm_e7nZ-JdpPPuWpaoJtK9GvXGYiQ-Rs=.9f9452fa-5034-4a46-b406-b22250ecb00c@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Usually @shipilev is kind and quick to provide them here: https://builds.shipilev.net/jtreg/

Mind his warning and motto, though:
> WARNING: These artifacts are not well-tested, not virus-checked, may contain horrible bugs that could lead to data corruption, engulfing machines in flames, sharing your financial data, selling your pets on eBay, etc. etc. etc. everything that applies for binaries^W code^W anything downloaded from the Internet. Be cautious. If in doubt, build from the source yourself, and/or run on staging environment that is not painful to restore.
>

> Our motto: "[builds.shipilev.net](https://builds.shipilev.net/) ? still more secure than npm install"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27719#issuecomment-3390690779

From alanb at openjdk.org  Fri Oct 10 15:16:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Oct 2025 15:16:03 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <2EF1whYIVC4qpXKNQJIYsxK6eLqfI89YWn0HjCxNjH4=.053b510f-fbd0-4ccd-a835-c235a35716c9@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <2EF1whYIVC4qpXKNQJIYsxK6eLqfI89YWn0HjCxNjH4=.053b510f-fbd0-4ccd-a835-c235a35716c9@github.com>
Message-ID: <mG8MDF3qLQHiDX9vUniODhKdXFcajmCXI4fXvQBIudk=.c1aed4d9-e797-471b-86ee-54f12a62f92d@github.com>

On Fri, 10 Oct 2025 14:44:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Can you please give an example URL for a class definition? I am concerned about whether this is high cardinality strings (for path/name.class) or a lot of reuse (for paths). We should only represent a URL once, which makes me think that the field type should be symbol instead of string.

Run with`-Xlog:class+load` to see examples of the code source. For classes loaded from modules in the run-time image then you'll see values of the form `jrt:/$MODULE`, e.g. `jrt:/java.base` or `jrt:/java.destop` (classes loaded from the AOT have something like "shared objects file"). The code source for classes loaded from JAR files is the path to the JAR file, e.g. 
`file:/lib/foo.jar`. When classes loaded from the file system then it will be the directory specified to the class path, e.g. `file:/d/classes/`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3390702449

From sgehwolf at openjdk.org  Fri Oct 10 15:59:26 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Oct 2025 15:59:26 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <7ZsK1yJQzaJ09WEageZzfvEYHugE9CX4aX0OOLbgqxo=.698bca0a-81e1-4e08-9442-28cd0fda5873@github.com>

On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

GHA test failure on Windows x64 is unrelated (this is a Linux only patch):
[gc/shenandoah/oom/TestThreadFailure](https://github.com/jerboaa/jdk/actions/runs/18406968978#user-content-gc_shenandoah_oom_testthreadfailure)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3390913305

From mdoerr at openjdk.org  Fri Oct 10 16:14:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 16:14:15 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v9]
In-Reply-To: <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>
Message-ID: <zhBin3JkF1iTp-c9WA6QvlVA31IKYphuomNU3fYJBWE=.ee5cc776-3d36-4c20-9db5-2d24169b8707@github.com>

On Fri, 10 Oct 2025 14:34:40 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ppc64 changes
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Thank you for improving it for all platforms! I think it is better readably, now. Only a minor nit. We'll retest it over the weekend.

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2204:

> 2202: 
> 2203: 
> 2204: 

Can you remove these extra empty lines, please?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3324544743
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2421055636

From kvn at openjdk.org  Fri Oct 10 16:49:45 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Oct 2025 16:49:45 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v9]
In-Reply-To: <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>
Message-ID: <9Rhn93VywCIlLMH6bfUTxoheJ2lJ8ExRNRhjabq0USM=.2665c851-5cf7-48a3-a281-a672966c984f@github.com>

On Fri, 10 Oct 2025 14:34:40 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ppc64 changes
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

aarch64 and x64 changes looks good to me.
I need to run new testing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3324748308

From kvn at openjdk.org  Fri Oct 10 17:08:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Oct 2025 17:08:02 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <V-KF6h6A0NRb4gMCnS8PZCung5F0YosCfhZlu7-fR8M=.66abb249-ca9b-4ea4-befe-99a0e1b17b46@github.com>

On Fri, 10 Oct 2025 13:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27744#pullrequestreview-3324831211

From jrose at openjdk.org  Fri Oct 10 17:17:03 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 10 Oct 2025 17:17:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
 <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>
Message-ID: <gmdQSCJtjoJ92QORY-Xi2_fFllRqpmQvmmEwCeMhZaM=.ee8c9f5d-485b-48f9-ae9c-e5e4112284c9@github.com>

On Thu, 9 Oct 2025 03:01:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 1971:
>> 
>>> 1969: 
>>> 1970: * `<system_error>`
>>> 1971: 
>> 
>> To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:
>> 
>> "HotSpot has its own timing support APIs."
>> "Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
>> "HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
>> "HotSpot has its own mechanisms for managing errors."
>
> I'll add some stuff to the PR change.
> 
>> "HotSpot has its own timing support APIs."
> 
> The argument for chrono is that our existing APIs aren't serving us well.
> chrono provides strong type safety. We've had multiple cases of mistakes like
> a double seconds being treated as double millis or vice versa, and other
> similar errors. But it would be a large effort to adopt chrono. And we'd need
> to decide whether to use the predefined clocks or hook up chrono to our
> clocks. It may be that using the predefined clocks is fine, but it's a
> question that needs careful study.
> 
>> "Initializer lists are an advanced C++ API feature which have surprising
>> interactions with other initialization syntaxes in use in HotSpot."
> 
> I think the trailing "in use in HotSpot" can be dropped from that. Mostly I
> think they are fine, but the potential ambiguity between some forms of direct
> initialization and initializer list initialization, and the resolution of that
> ambiguity, is unfortunate.
> 
>> "HotSpot uses floating point numbers ..."
> 
> Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also
> fixed (though parameterized) precision. It's not a general purpose rational
> arithmetic facility. My understanding is that it started life as a detail of
> chrono, and was extracted and promoted to a public facility in the belief that
> it has broader utility.
> 
>> "HotSpot has its own mechanisms for managing errors."
> 
> Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc
> mechanisms. There's a bunch of discussion happening around that topic lately.
> I don't think we've coalesced around any particular approach yet. And even
> once we decided on something it's likely to take quite a while for rollout to
> really make use of whatever we settle on.

I love a good nerd sniping! Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2421306579

From aph at openjdk.org  Fri Oct 10 17:23:07 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Oct 2025 17:23:07 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v15]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <HH5FzwmqfBO7Bxo_T6_0OcXQX6fK3MYwUxa_aVP8ktQ=.39ea35a5-7123-4a12-ba8d-7de43d8fdfc8@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Add logging for WX.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/5a1a452b..725cdee5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=13-14

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From asmehra at openjdk.org  Fri Oct 10 17:48:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 17:48:56 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Remove blank lines
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/c81f3805..5ddd660d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

PR: https://git.openjdk.org/jdk/pull/27676

From asmehra at openjdk.org  Fri Oct 10 17:49:00 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 10 Oct 2025 17:49:00 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v9]
In-Reply-To: <zhBin3JkF1iTp-c9WA6QvlVA31IKYphuomNU3fYJBWE=.ee5cc776-3d36-4c20-9db5-2d24169b8707@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <ZXOUeTilhrMXQmamGop8RQhZiPmFu_bnakI8wv6ovWA=.13f09bc9-09d4-4245-b18e-f8199839e571@github.com>
 <zhBin3JkF1iTp-c9WA6QvlVA31IKYphuomNU3fYJBWE=.ee5cc776-3d36-4c20-9db5-2d24169b8707@github.com>
Message-ID: <m9RZGLUyL6ZeoefeJ5y-XLFukUcR65UBs8zGAzWVcss=.944934fa-a763-4953-ba9f-31d130c2b4a1@github.com>

On Fri, 10 Oct 2025 16:10:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert ppc64 changes
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2204:
> 
>> 2202: 
>> 2203: 
>> 2204: 
> 
> Can you remove these extra empty lines, please?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2421418196

From sspitsyn at openjdk.org  Fri Oct 10 19:51:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 19:51:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
Message-ID: <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>

On Fri, 10 Oct 2025 14:53:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.

We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392113146

From pchilanomate at openjdk.org  Fri Oct 10 20:37:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 20:37:02 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
Message-ID: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>

On Fri, 10 Oct 2025 19:48:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.
> 
> We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything?
>
Yes, but we are calling the other overload of `freeze_epilog()` which only logs and verifies the continuation. : )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392242151

From jkratochvil at openjdk.org  Fri Oct 10 21:10:02 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 10 Oct 2025 21:10:02 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl [v2]
In-Reply-To: <whZGoIvGBseY0bSzrdXhhG8SMVBPKIlNOrTyISDTR4E=.39bf0af7-48b9-4909-aeb7-d082ee0f6fa6@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <EpZx5Y73hjsFrLOOUhp0H5TpNx0RiwnRlI9yAYw7lYw=.f5de6d23-94e9-43dd-9f77-69a012d9a09e@github.com>
 <whZGoIvGBseY0bSzrdXhhG8SMVBPKIlNOrTyISDTR4E=.39bf0af7-48b9-4909-aeb7-d082ee0f6fa6@github.com>
Message-ID: <IkFwcm4-m8UWlQBmF9CB9R3pY7vVUOSKlPu3SQPWrBI=.eaf865a5-6717-4a94-8673-4d70913c0d2c@github.com>

On Fri, 10 Oct 2025 05:38:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>     * We are looking up `outer_k->constants->klass_at(x)` where `x` could be the inner-class index or the outher-class index (can't tell which from the bug report)

It crashes with caller on the line `Klass* i = cp->klass_at(ioff, CHECK);` so `x` is the inner-class index.

`klass_at_impl` has already successfully returned `Klass*` for the outer-class index that time.

>     * `klass_at_impl` does ` Handle loader (THREAD, this_cp->pool_holder()->class_loader());`, which is the same as `outer_k->class_loader()`

`klass_at_impl` is that time running for `inner_k`.

> src/hotspot/share/oops/instanceKlass.cpp line 3332:
> 
>> 3330:   if (nullptr == outer_klass) return nullptr;
>> 3331: 
>> 3332:   // Wait until also outer_klass gets fully loaded.
> 
> How are you "waiting"?

I expected the line `ObjectLocker ol(h_init_lock, THREAD);` is the waiting. But this patch is not verified with the customer so maybe (or now probably?) it does not work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27595#issuecomment-3392307478
PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2422088410

From jkratochvil at openjdk.org  Fri Oct 10 21:13:06 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 10 Oct 2025 21:13:06 GMT
Subject: RFR: 8369021: A crash in ConstantPool::klass_at_impl [v2]
In-Reply-To: <whZGoIvGBseY0bSzrdXhhG8SMVBPKIlNOrTyISDTR4E=.39bf0af7-48b9-4909-aeb7-d082ee0f6fa6@github.com>
References: <AK3KNcSxew3NzxuFsUjk2j-Jiy9ytumEXI4pJ-g2s-k=.3f2ddea5-e2e3-4dd8-8120-c8f0c91140bf@github.com>
 <EpZx5Y73hjsFrLOOUhp0H5TpNx0RiwnRlI9yAYw7lYw=.f5de6d23-94e9-43dd-9f77-69a012d9a09e@github.com>
 <whZGoIvGBseY0bSzrdXhhG8SMVBPKIlNOrTyISDTR4E=.39bf0af7-48b9-4909-aeb7-d082ee0f6fa6@github.com>
Message-ID: <tDolHfBuXe_g1bKmnmp3-uRtIe7KQvxmilGJDHfmDLM=.f8ca504d-b98b-4c56-847e-3cb994057674@github.com>

On Fri, 10 Oct 2025 05:06:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil 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 linkclass
>>  - Make an alternative fix in compute_enclosing_class
>>  - Revert "8369021: A crash in ConstantPool::klass_at_impl"
>>    
>>    This reverts commit 026fcb1b21729e41524169c7f78855e8794ddae2.
>>  - 8369021: A crash in ConstantPool::klass_at_impl
>
> src/hotspot/share/oops/instanceKlass.cpp line 3333:
> 
>> 3331: 
>> 3332:   // Wait until also outer_klass gets fully loaded.
>> 3333:   InstanceKlass* pool_holder = outer_klass->constants()->pool_holder();
> 
> This should just set `pool_holder == outer_klass`. When we parse a class we do:
> 
>  _cp->set_pool_holder(this_klass);
> this_klass->set_constants(_cp);
> 
> so `klass->constants()->pool_holder() == klass`. ??

I see now. I am withdrawing this patch before I get some updated patch verified with the customer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27595#discussion_r2422091665

From mdoerr at openjdk.org  Fri Oct 10 21:39:04 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 21:39:04 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v7]
In-Reply-To: <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
Message-ID: <h3QHxWsMFPKUPyyOJaQpSyOcy1P6tEhYeAMbLzoYECo=.48f49e91-d53f-413c-ab1e-e70c8b8529ba@github.com>

On Fri, 10 Oct 2025 13:31:33 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 268:

> 266:     /* in */
> 267:     : [dest]                   "b"     (dest),
> 268:       [masked_compare_value]   "r"     (masked_compare_value),

Typo: masked_compare_val. Please fix!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2422133661

From mdoerr at openjdk.org  Fri Oct 10 21:44:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Oct 2025 21:44:05 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <V9DNP0BaiMBEEoHnLX5m81ePFqMiUn_UsxqmF8KujKQ=.022ebf66-3f44-47d3-bf60-9f2a5fe122bb@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3326007439

From bulasevich at openjdk.org  Fri Oct 10 22:22:50 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 10 Oct 2025 22:22:50 GMT
Subject: RFR: 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster
Message-ID: <9KmPqhIXB8_05Tu4NQP7TECtTqtQKs0ZvXWxI58C1TU=.5c488724-4d57-4d4f-aa2e-bdecab6a91af@github.com>

This change adjusts the default selection of SHA-3 intrinsics on AArch64 based on observed performance across CPUs. In our measurements, the SHA-3 SIMD path (using SHA3 instructions) is consistently faster on Apple silicon, while on Neoverse and several older cores the GPR implementation performs better. On CPUs without SHA-3 instructions, the GPR path is the only viable option and behaves as expected.

Accordingly, `UseSIMDForSHA3Intrinsic` now defaults to false globally. The SIMD variant is auto-enabled only on Apple silicon; elsewhere the default remains the GPR path.

_The attached raw data also includes observations about `UseFPUForSpilling`. Back in #27350 we discussed whether the option is entirely useless. While orthogonal to this change, the MessageDigests benchmark is a convenient probe of register-spilling behavior because the SHA-3 (Keccak) algorithm is highly register-hungry, which adds a significant number of spills to the generated assembly sequence. In the provided results, at least one CPU benefits from enabling UseFPUForSpilling, so the option seems worth keeping for now._

**Cortex-A53 (RPi3)**

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
Benchmark          (digesterName)  (length)   Cnt    Score   Error   Units
MessageDigests.digest    SHA3-512        64   150  345.010 ? 0.473  ops/ms
MessageDigests.digest    SHA3-512     16384   150    1.817 ? 0.001  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
MessageDigests.digest    SHA3-512        64   150  352.247 ? 0.279  ops/ms  +UseFPUForSpilling: +2%
MessageDigests.digest    SHA3-512     16384   150    1.855 ? 0.001  ops/ms  +UseFPUForSpilling: +2%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt    Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  345.552 ?  0.291  ops/ms
MessageDigests.digest          SHA3-512     16384    15    1.818 ?  0.001  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  265.744 ? 56.591  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    1.812 ?  0.002  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt    Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  343.047 ?  3.802  ops/ms  (UseSHA3Intrinsics is disabled due to missing sha3 capabilites)
MessageDigests.digest          SHA3-512     16384    15    1.817 ?  0.003  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  292.429 ? 20.928  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    1.788 ?  0.020  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt    Score   Error   Units
MessageDigests.digest          SHA3-512        64    15  474.854 ? 4.275  ops/ms  GPR SHA3: +37% ?
MessageDigests.digest          SHA3-512     16384    15    2.940 ? 0.003  ops/ms  GPR SHA3: +61% ?
MessageDigests.getAndDigest    SHA3-512        64    15  411.179 ? 3.143  ops/ms  GPR SHA3: +54% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    2.927 ? 0.002  ops/ms  GPR SHA3: +61% ?

$ head /proc/cpuinfo
processor	: 0
BogoMIPS	: 38.40
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

$ ./jdk-25/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = false                     {product} {default}
     bool UseSHA1Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA256Intrinsics              = false                  {diagnostic} {default}
     bool UseSHA3Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA512Intrinsics              = false                  {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

**Cortex-A72 (G1)**

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  1056.831 ? 10.485 ops/ms
MessageDigests.digest    SHA3-512     16384    50     5.348 ?  0.008 ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  1050.750 ? 9.830  ops/ms  +UseFPUForSpilling:  0%
MessageDigests.digest    SHA3-512     16384    50     5.249 ? 0.003  ops/ms  +UseFPUForSpilling: -2%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1055.729 ? 22.589  ops/ms
MessageDigests.digest          SHA3-512     16384    15     5.355 ?  0.003  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15   867.129 ? 24.624  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15     5.320 ?  0.019  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1057.076 ? 22.620  ops/ms (UseSHA3Intrinsics is disabled due to missing sha3 capabilites)
MessageDigests.digest          SHA3-512     16384    15     5.354 ?  0.003  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15   866.266 ? 10.790  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15     5.330 ?  0.015  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1215.299 ? 24.954  ops/ms  GPR SHA3: +15% ?
MessageDigests.digest          SHA3-512     16384    15     6.582 ?  0.005  ops/ms  GPR SHA3: +23% ?
MessageDigests.getAndDigest    SHA3-512        64    15   956.375 ? 36.935  ops/ms  GPR SHA3: +10% ?
MessageDigests.getAndDigest    SHA3-512     16384    15     6.552 ?  0.008  ops/ms  GPR SHA3: +23% ?

$ cat /proc/cpuinfo
processor	: 0
BogoMIPS	: 166.66
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

$ ./jdk-25/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = true                      {product} {default}
     bool UseSHA1Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA256Intrinsics              = true                   {diagnostic} {default}
     bool UseSHA3Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA512Intrinsics              = false                  {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

**ARM Neoverse N1 (G2)**

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10 MessageDigests.digest    SHA3-512        64    50  1693.312 ? 6.705  ops/ms
MessageDigests.digest    SHA3-512     16384    50     8.338 ? 0.004  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  1549.136 ? 4.379  ops/ms  +UseFPUForSpilling:  -9%
MessageDigests.digest    SHA3-512     16384    50     7.464 ? 0.008  ops/ms  +UseFPUForSpilling: -10%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1699.575 ? 12.454  ops/ms
MessageDigests.digest          SHA3-512     16384    15     8.337 ?  0.008  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  1530.011 ?  3.471  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15     8.342 ?  0.006  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1690.346 ? 10.649  ops/ms (UseSHA3Intrinsics is disabled due to missing sha3 capabilites)
MessageDigests.digest          SHA3-512     16384    15     8.339 ?  0.009  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  1529.265 ?  3.778  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15     8.259 ?  0.005  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  2071.184 ?  2.020  ops/ms  GPR SHA3: +22% ?
MessageDigests.digest          SHA3-512     16384    15    10.550 ?  0.002  ops/ms  GPR SHA3: +26% ?
MessageDigests.getAndDigest    SHA3-512        64    15  1821.436 ?  9.783  ops/ms  GPR SHA3: +19% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    10.541 ?  0.001  ops/ms  GPR SHA3: +26% ?

$ cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 243.75
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x3
CPU part        : 0xd0c
CPU revision    : 1

$ ./jdk-25/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = true                      {product} {default}
     bool UseSHA1Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA256Intrinsics              = true                   {diagnostic} {default}
     bool UseSHA3Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA512Intrinsics              = false                  {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

**ARM Neoverse V1 (G3)**

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
MessageDigests.digest    SHA3-512        64    50  2567.010 ? 6.958  ops/ms
MessageDigests.digest    SHA3-512     16384    50    12.267 ? 0.003  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
MessageDigests.digest    SHA3-512        64    50  2023.971 ? 3.043  ops/ms  +UseFPUForSpilling: -21%
MessageDigests.digest    SHA3-512     16384    50     9.531 ? 0.006  ops/ms  +UseFPUForSpilling: -22%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  2567.030 ? 11.001  ops/ms
MessageDigests.digest          SHA3-512     16384    15    12.266 ?  0.006  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  2283.653 ?  4.276  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    12.253 ?  0.007  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1586.933 ?  5.553  ops/ms  SIMD SHA3: -38%
MessageDigests.digest          SHA3-512     16384    15     7.411 ?  0.001  ops/ms  SIMD SHA3: -39%
MessageDigests.getAndDigest    SHA3-512        64    15  1449.235 ? 31.213  ops/ms  SIMD SHA3: -36%
MessageDigests.getAndDigest    SHA3-512     16384    15     7.401 ?  0.001  ops/ms  SIMD SHA3: -39%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score   Error   Units
MessageDigests.digest          SHA3-512        64    15  2877.972 ? 1.844  ops/ms   GPR SHA3: +12% ?
MessageDigests.digest          SHA3-512     16384    15    14.259 ? 0.015  ops/ms   GPR SHA3: +16% ?
MessageDigests.getAndDigest    SHA3-512        64    15  2494.387 ? 5.761  ops/ms   GPR SHA3:  +9% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    14.221 ? 0.012  ops/ms   GPR SHA3: +16% ?

$ cat /proc/cpuinfo
processor	: 0
BogoMIPS	: 2100.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x1
CPU part	: 0xd40
CPU revision	: 1

$ ./jdk-25/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = true                      {product} {default}
     bool UseSHA1Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA256Intrinsics              = true                   {diagnostic} {default}
     bool UseSHA3Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA512Intrinsics              = true                   {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

**ARM Neoverse V2 (G4)**

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
MessageDigests.digest    SHA3-512        64    50  3014.775 ? 1.913  ops/ms
MessageDigests.digest    SHA3-512     16384    50    14.404 ? 0.004  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
MessageDigests.digest    SHA3-512        64    50  2793.075 ? 2.551  ops/ms  +UseFPUForSpilling: -7%
MessageDigests.digest    SHA3-512     16384    50    13.243 ? 0.006  ops/ms  +UseFPUForSpilling: -8%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
Benchmark                (digesterName)  (length)   Cnt     Score   Error   Units
MessageDigests.digest          SHA3-512        64    15  3015.873 ? 4.404  ops/ms
MessageDigests.digest          SHA3-512     16384    15    14.403 ? 0.008  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  2606.421 ? 6.977  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    14.295 ? 0.051  ops/ms

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  1734.671 ?  1.107  ops/ms  SIMD SHA3: -43%
MessageDigests.digest          SHA3-512     16384    15     7.975 ?  0.001  ops/ms  SIMD SHA3: -45%
MessageDigests.getAndDigest    SHA3-512        64    15  1580.420 ? 31.229  ops/ms  SIMD SHA3: -40%
MessageDigests.getAndDigest    SHA3-512     16384    15     7.967 ?  0.001  ops/ms  SIMD SHA3: -45%

$ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score   Error   Units
MessageDigests.digest          SHA3-512        64    15  3295.626 ? 7.651  ops/ms   GPR SHA3:  +9% ?
MessageDigests.digest          SHA3-512     16384    15    16.291 ? 0.011  ops/ms   GPR SHA3: +13% ?
MessageDigests.getAndDigest    SHA3-512        64    15  2822.072 ? 8.346  ops/ms   GPR SHA3:  +8% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    16.241 ? 0.035  ops/ms   GPR SHA3: +13% ?

$ cat /proc/cpuinfo
processor	: 0
BogoMIPS	: 2000.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd4f
CPU revision	: 1

$ ./jdk-25/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = true                      {product} {default}
     bool UseSHA1Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA256Intrinsics              = true                   {diagnostic} {default}
     bool UseSHA3Intrinsics                = false                  {diagnostic} {default}
     bool UseSHA512Intrinsics              = true                   {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

**Apple M1**

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  4139.231 ? 18.412  ops/ms
MessageDigests.digest    SHA3-512     16384    50    19.897 ?  0.025  ops/ms

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  3706.428 ? 18.688  ops/ms  +UseFPUForSpilling: -10%
MessageDigests.digest    SHA3-512     16384    50    17.692 ?  0.010  ops/ms  +UseFPUForSpilling: -11%

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  4126.912 ? 34.411  ops/ms
MessageDigests.digest          SHA3-512     16384    15    19.895 ?  0.036  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  3661.652 ? 17.358  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    19.470 ?  0.171  ops/ms

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  5575.331 ? 53.743  ops/ms  SIMD SHA3: +35%
MessageDigests.digest          SHA3-512     16384    15    28.138 ?  0.016  ops/ms  SIMD SHA3: +41%
MessageDigests.getAndDigest    SHA3-512        64    15  4908.696 ?  3.546  ops/ms  SIMD SHA3: +34%
MessageDigests.getAndDigest    SHA3-512     16384    15    28.008 ?  0.029  ops/ms  SIMD SHA3: +44%

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  4436.765 ? 16.368  ops/ms   GPR SHA3:  +8% ?
MessageDigests.digest          SHA3-512     16384    15    21.573 ?  0.011  ops/ms   GPR SHA3:  +8% ?
MessageDigests.getAndDigest    SHA3-512        64    15  3972.640 ?  1.727  ops/ms   GPR SHA3:  +8% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    21.468 ?  0.016  ops/ms   GPR SHA3: +10% ?

**Apple M4**

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  5654.605 ? 47.051  ops/ms
MessageDigests.digest    SHA3-512     16384    50    27.613 ?  0.034  ops/ms

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest -f10
MessageDigests.digest    SHA3-512        64    50  5019.941 ? 45.104  ops/ms  +UseFPUForSpilling: -11%
MessageDigests.digest    SHA3-512     16384    50    23.929 ?  0.009  ops/ms  +UseFPUForSpilling: -13%

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics"
 Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  5701.512 ? 70.397  ops/ms
MessageDigests.digest          SHA3-512     16384    15    27.656 ?  0.013  ops/ms
MessageDigests.getAndDigest    SHA3-512        64    15  5253.424 ? 12.838  ops/ms
MessageDigests.getAndDigest    SHA3-512     16384    15    27.207 ?  0.149  ops/ms

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:+UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  7204.542 ? 51.968  ops/ms  SIMD SHA3: +26%
MessageDigests.digest          SHA3-512     16384    15    33.473 ?  0.294  ops/ms  SIMD SHA3: +21%
MessageDigests.getAndDigest    SHA3-512        64    15  6621.422 ? 24.413  ops/ms  SIMD SHA3: +26$
MessageDigests.getAndDigest    SHA3-512     16384    15    33.431 ?  0.022  ops/ms  SIMD SHA3: +23%

$ ./jdk-25.jdk/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:+UseSHA3Intrinsics -XX:-UseSIMDForSHA3Intrinsic"
Benchmark                (digesterName)  (length)   Cnt     Score    Error   Units
MessageDigests.digest          SHA3-512        64    15  7084.719 ? 94.518  ops/ms   GPR SHA3: +24$ ?
MessageDigests.digest          SHA3-512     16384    15    35.974 ?  0.025  ops/ms   GPR SHA3: +30% ?
MessageDigests.getAndDigest    SHA3-512        64    15  6475.984 ? 18.642  ops/ms   GPR SHA3: +23% ?
MessageDigests.getAndDigest    SHA3-512     16384    15    35.839 ?  0.012  ops/ms   GPR SHA3: +32% ?

$ cat /proc/cpuinfo | head
     No such file or directory

$ ./jdk-25.jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep SHA
     bool UseSHA                           = true                      {product} {default}
     bool UseSHA1Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA256Intrinsics              = true                   {diagnostic} {default}
     bool UseSHA3Intrinsics                = true                   {diagnostic} {default}
     bool UseSHA512Intrinsics              = true                   {diagnostic} {default}
     bool UseSIMDForSHA3Intrinsic          = true                 {ARCH product} {default}

-------------

Commit messages:
 - 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster

Changes: https://git.openjdk.org/jdk/pull/27726/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359256
  Stats: 20 lines in 2 files changed: 8 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27726/head:pull/27726

PR: https://git.openjdk.org/jdk/pull/27726

From sspitsyn at openjdk.org  Fri Oct 10 22:33:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 22:33:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
 <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
Message-ID: <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>

On Fri, 10 Oct 2025 20:34:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : )

I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well?

I've filed new JVMTI bug:
[8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392488763

From fandreuzzi at openjdk.org  Sat Oct 11 06:16:14 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 06:16:14 GMT
Subject: Integrated: 8369440: Remove RootResolverMarkScope and
 RootSetClosureMarkScope
In-Reply-To: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
References: <QbQTlEHy0nFuXwqKQu8cBv-pJ14_ymGc68ff04dN_Oo=.7a23a25a-9a6c-4df3-a04b-648408815e2a@github.com>
Message-ID: <oJcEDiotgbYHu5rcEO5hVYn_C44SLi8AtdeKbSJbL74=.1042dda3-00e2-4115-b3c1-a11d5f7f4e0b@github.com>

On Thu, 9 Oct 2025 14:19:22 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> `RootResolverMarkScope` and `RootSetClosureMarkScope` are not needed, since the code using them does not seem to require `nmethod::oops_do_marking_prologue`.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 9b99bc8e
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b99bc8ef53ad20c4f1cb5d26cffc64b0deb79ad
Stats:     85 lines in 6 files changed: 0 ins; 85 del; 0 mod

8369440: Remove RootResolverMarkScope and RootSetClosureMarkScope

Reviewed-by: ayang

-------------

PR: https://git.openjdk.org/jdk/pull/27729

From fandreuzzi at openjdk.org  Sat Oct 11 14:56:39 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 14:56:39 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache
Message-ID: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>

I propose to amend the check in `nmethod::is_cold` to allow not-entrant native `nmethod` instances to be collected during GC.

Passes tier1 and tier2 (fastdebug).

-------------

Commit messages:
 - trigger
 - nn
 - othervm
 - stuff
 - comments and fix test
 - cc
 - fix check
 - fix and test

Changes: https://git.openjdk.org/jdk/pull/27742/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369219
  Stats: 145 lines in 3 files changed: 144 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From fandreuzzi at openjdk.org  Sat Oct 11 15:04:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 15:04:43 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache [v2]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <oD9xL1nHfUau4nAtkQmelFMwh9MDwb3KGXTxDJMAm2M=.8de3d1f8-6fbe-498b-9763-babdbdc77bcb@github.com>

> I propose to amend the check in `nmethod::is_cold` to allow not-entrant native `nmethod` instances to be collected during GC.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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 10 additional commits since the last revision:

 - nn
 - Merge branch 'master' into JDK-8369219
 - trigger
 - nn
 - othervm
 - stuff
 - comments and fix test
 - cc
 - fix check
 - fix and test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/ab6b8051..b3eae893

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=00-01

  Stats: 92 lines in 7 files changed: 81 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From kim.barrett at oracle.com  Sat Oct 11 15:41:13 2025
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 11 Oct 2025 11:41:13 -0400
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <WWuvmG4xgHdPyGLGc9qevYrVkZ6PBb3qYPsThvyFMNg=.726dd880-32d9-43be-b517-3b1649060bd0@github.com>
Message-ID: <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>

On 10/8/25 8:06 AM, Julian Waters wrote:
>> Paging with the mailing list bridge to restart discussion, which I need in order to be able to continue working on this

As I've said before, we (Oracle) think LTO support is a substantial project,
we haven't made it a priority, and nobody here has offered up time to work on
it. Someone else might have time for this; we don't seem to. That might change
in the future, but for now...

Some of the issues that make it a substantial project include:

The LTO vs flattening problem.

There are functions that assume (or even rely upon) implicit noinline via
being in a different translation unit from callers. I think that's probably a
much harder problem to resolve, since it's generally not obvious. Functions
that do things like getting the current stack pointer or frame pointer may be
relevant? Not sure what else.

Build time issues, and their impact on development time and testing resources.

Is LTO an alternative mode, different from how things are "normally" done?
That increases testing resource requirements, else it will bit rot.

There might be others that I'm not remembering or I'm completely unaware of.


From fandreuzzi at openjdk.org  Sat Oct 11 15:42:55 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 15:42:55 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache [v3]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <kCwGtyTw9vF9f7k9V0NTE9dB-ZxUJJWhgMcTdG3TRbA=.51a86cd0-e5fb-4459-a0bc-d5eb03c60a57@github.com>

> I propose to amend the check in `nmethod::is_cold` to allow not-entrant native `nmethod` instances to be collected during GC.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  fix summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/b3eae893..6bba7687

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From jwaters at openjdk.org  Sat Oct 11 16:28:06 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Oct 2025 16:28:06 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers
In-Reply-To: <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <154ed38b-841a-4199-bbb1-0bafecdbd40f@oracle.com>
Message-ID: <HtK1pb08qwWlskTyNBhssAR80-edNEbZQ4I9AhO6P6U=.ced4fb98-a529-4902-8b1d-815316a08793@github.com>

On Sat, 11 Oct 2025 15:42:53 GMT, Kim Barrett <kim.barrett at oracle.com> wrote:

> The LTO vs flattening problem.

Currently that seems to be the biggest problem, I do have solutions for other smaller issues with LTO, but from what I witness the flattening problem has to be solved first before any more work can be done with LTO. While I fortunately do have time to spare to try working on the issue (I'm that "Someone else", more or less), I less fortunately don't have the knowledge required to fix that problem, as even though only G1 uses flattening, the call hierarchy is too massive to actually meaningfully discern which calls need to be flattened and which calls shouldn't be flattened. Not very sure if anyone knows which code paths shouldn't be inlined within g1ParScanThreadState.cpp, actually. If anyone knew, I could fast track the flattening issue on my end and have it solved pretty quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3393474226

From apangin at openjdk.org  Sat Oct 11 17:22:06 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Sat, 11 Oct 2025 17:22:06 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache [v3]
In-Reply-To: <kCwGtyTw9vF9f7k9V0NTE9dB-ZxUJJWhgMcTdG3TRbA=.51a86cd0-e5fb-4459-a0bc-d5eb03c60a57@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <kCwGtyTw9vF9f7k9V0NTE9dB-ZxUJJWhgMcTdG3TRbA=.51a86cd0-e5fb-4459-a0bc-d5eb03c60a57@github.com>
Message-ID: <v8jJ3zf8pxr1RWFboH_TZ7VHg0t4A9qytbgKG0C8UBA=.39089a86-5766-4d3b-9b99-95fe9741ee3b@github.com>

On Sat, 11 Oct 2025 15:42:55 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I propose to amend the check in `nmethod::is_cold` to allow not-entrant native `nmethod` instances to be collected during GC.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix summary

test/hotspot/jtreg/gc/NativeWrapperCollection/TestNativeWrapperCollection.java line 84:

> 82:                 continue;
> 83:             }
> 84:             if (foundOne) {

Where is `foundOne` updated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2423055494

From fandreuzzi at openjdk.org  Sat Oct 11 18:25:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 18:25:48 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache [v4]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>

> I propose to amend the check in `nmethod::is_cold` to allow not-entrant native `nmethod` instances to be collected during GC.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  update foundOne

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/6bba7687..8ea13b6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=02-03

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From fandreuzzi at openjdk.org  Sat Oct 11 18:25:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 11 Oct 2025 18:25:48 GMT
Subject: RFR: 8369219: JNI::RegisterNatives can cause a memory leak in
 CodeCache [v3]
In-Reply-To: <v8jJ3zf8pxr1RWFboH_TZ7VHg0t4A9qytbgKG0C8UBA=.39089a86-5766-4d3b-9b99-95fe9741ee3b@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <kCwGtyTw9vF9f7k9V0NTE9dB-ZxUJJWhgMcTdG3TRbA=.51a86cd0-e5fb-4459-a0bc-d5eb03c60a57@github.com>
 <v8jJ3zf8pxr1RWFboH_TZ7VHg0t4A9qytbgKG0C8UBA=.39089a86-5766-4d3b-9b99-95fe9741ee3b@github.com>
Message-ID: <8BVbjgobGslfUK7F6guCncIA7gA-YAHDjtLYbdz0pTI=.46fa897f-3500-4c5a-89da-af19a28899a1@github.com>

On Sat, 11 Oct 2025 17:18:19 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix summary
>
> test/hotspot/jtreg/gc/NativeWrapperCollection/TestNativeWrapperCollection.java line 84:
> 
>> 82:                 continue;
>> 83:             }
>> 84:             if (foundOne) {
> 
> Where is `foundOne` updated?

Thanks, the test would usually fail when it finds the not-entrant line so I missed it. Fixed in 8ea13b6ec69ef5bfcd5f2719363b0a0596b55800

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2423077779

From kbarrett at openjdk.org  Sun Oct 12 00:06:20 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 12 Oct 2025 00:06:20 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into stdlib-header-wrappers
 - jrose comments
 - move tuple to undecided category
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

-------------

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=02
  Stats: 670 lines in 68 files changed: 430 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

PR: https://git.openjdk.org/jdk/pull/27601

From kvn at openjdk.org  Sun Oct 12 23:48:05 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 12 Oct 2025 23:48:05 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <yWotp_II4fHreKNLMp3HgAzugHftI1tozy2OWURIVJo=.b931658e-ae7a-42ec-b1b3-3e3a57ffca67@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

My v08 testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3329687293

From fjiang at openjdk.org  Mon Oct 13 01:30:56 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 13 Oct 2025 01:30:56 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers and
 wrong store order in MacroAssembler
Message-ID: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>

Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.

Testing:
- [x] tier1-3

-------------

Commit messages:
 - JavaFrameAnchor on RISCV has unnecessary barriers and wrong store order in MacroAssembler

Changes: https://git.openjdk.org/jdk/pull/27757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369616
  Stats: 19 lines in 2 files changed: 9 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27757/head:pull/27757

PR: https://git.openjdk.org/jdk/pull/27757

From dholmes at openjdk.org  Mon Oct 13 01:49:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Oct 2025 01:49:02 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <mzbEojjWWHqU2Zhn1GMGg7_80MUV7Hae6zN6mj0nR8U=.ab939c67-890d-4266-99b7-2464ee74627f@github.com>

On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

There seems to be some collision here with JDK-[8367319](https://github.com/openjdk/jdk/pull/27646/)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3395619340

From fyang at openjdk.org  Mon Oct 13 02:03:07 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 13 Oct 2025 02:03:07 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <YwI_Z-EAGHIx179zkBIweVaYXZf1jdrLz_KaTxaNykw=.d2a52d3b-09da-4579-96f0-09a5e75b4a14@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Update to RISC-V part looks fine. And `hotspot_runtime` still test good with fastdebug build on linux-riscv64.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3329822236

From fyang at openjdk.org  Mon Oct 13 02:05:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 13 Oct 2025 02:05:02 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler
In-Reply-To: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
Message-ID: <mzAj3aCz3ZzL7d3EJXAcp-MDHyugMlRsseg0w46jlZI=.ad885f46-7e0e-4d55-b103-284f120702bc@github.com>

On Sat, 11 Oct 2025 12:48:46 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
> 
> Testing:
> - [x] tier1-3

Thanks!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27757#pullrequestreview-3329823526

From dholmes at openjdk.org  Mon Oct 13 02:18:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Oct 2025 02:18:02 GMT
Subject: RFR: 8369442: ExitOnOutOfMemoryError should exit more gracefully
 [v2]
In-Reply-To: <-WtruSSGNZoK8VxUHXc_I2hPLxJfxgduPxU32HgKlUM=.780b3027-e625-4511-b19b-2a02b7d91c42@github.com>
References: <jmDCleeQhVqoqZP3h6o4tKHn7VthljAD_wmZX93KCb4=.88ff8222-aea4-402c-9261-22e43b414f09@github.com>
 <moKnZOqMChLs9ZagjBhrooi-LhVGJRGE8YoN5nWYkSI=.959ad531-9f3d-4eb0-bb0a-13148af5d898@github.com>
 <-WtruSSGNZoK8VxUHXc_I2hPLxJfxgduPxU32HgKlUM=.780b3027-e625-4511-b19b-2a02b7d91c42@github.com>
Message-ID: <MaZl1Z22-9OS8L0l5CSWxMg8hQxVYJFVac0d_Wt6S-c=.68ea997a-dd3e-4ff5-b68e-cac1c221f2e1@github.com>

On Fri, 10 Oct 2025 08:15:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Are we sure that before_exit can handle being called at any point between set_init_completed and when we start running user byte code.

Good point! More generally if we can trigger OOM during VM init, then some of the tear-down actions in `before_exit` may not be valid if we haven't completed the corresponding init actions. And some of those "init" actions may happen after `set_init_completed`.

> I know we have internally questioned the validity of the development flag ExitOnFullCodeCache which also can call before_exit very early,

I would also question its validity, but as a develop flag I'd be prepared to accept that unexpected things may happen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27718#issuecomment-3395651429

From dholmes at openjdk.org  Mon Oct 13 02:55:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Oct 2025 02:55:02 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v2]
In-Reply-To: <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <4LsWE0LB0nCQyB2YGtZ4HZDlpRIp8pKuwJZ-j7ydUEs=.12912ff9-67fc-446f-8191-0f410adf5154@github.com>
Message-ID: <eQnaExbnVDYJeEC55gdLTCEN9J_Jy2aNaTwWXdsIqqE=.53e610f3-0648-41dd-8457-28a1612d4074@github.com>

On Thu, 9 Oct 2025 11:40:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
>> 
>> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rdtsc: Remove experimental support for non invariant tsc

Happy to see that go. :)

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27713#pullrequestreview-3329858869

From dholmes at openjdk.org  Mon Oct 13 03:04:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Oct 2025 03:04:09 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
In-Reply-To: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
Message-ID: <cuzUIvaNHny1ekQ8Z8G5L_31mSIqYX7qkS76naUe_YE=.e7ed44f5-4a62-4de3-9a74-1e50569be412@github.com>

On Thu, 9 Oct 2025 06:18:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
> However the current implementation does not do this correctly in all places, where it does:
> 
>   static bool initialized = false;
>   if (!initialized) {
>     ...
>     initialized = true;
>   }
> 
> It should do
> 
> static bool initialized = initialize_impl(); // Do the logic inside a function call
> 
> to guarantee that initialize is only called once.
> 
> We have observed this from some GC threads if we start using Ticks to early.
> 
> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.

Seems reasonable.

One typo to fix.

Thanks

src/hotspot/cpu/x86/rdtsc_x86.cpp line 34:

> 32: #include "vm_version_x86.hpp"
> 33: 
> 34: DEBUG_ONLY(volatile int Rdtsc::_initalized = 0;)

Suggestion:

DEBUG_ONLY(volatile int Rdtsc::_initialized = 0;)

src/hotspot/cpu/x86/rdtsc_x86.cpp line 173:

> 171: 
> 172: bool Rdtsc::initialize() {
> 173:   precond(AtomicAccess::xchg(&_initalized, 1) == 0);

Suggestion:

  precond(AtomicAccess::xchg(&_initialized, 1) == 0);

src/hotspot/cpu/x86/rdtsc_x86.hpp line 42:

> 40: class Rdtsc : AllStatic {
> 41:  private:
> 42:   DEBUG_ONLY(static volatile int _initalized;)

Suggestion:

  DEBUG_ONLY(static volatile int _initialized;)

-------------

PR Review: https://git.openjdk.org/jdk/pull/27712#pullrequestreview-3329861518
PR Review Comment: https://git.openjdk.org/jdk/pull/27712#discussion_r2425134093
PR Review Comment: https://git.openjdk.org/jdk/pull/27712#discussion_r2425135899
PR Review Comment: https://git.openjdk.org/jdk/pull/27712#discussion_r2425136929

From stefank at openjdk.org  Mon Oct 13 06:15:07 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Oct 2025 06:15:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>
Message-ID: <gDALmhCV8DGJe0F2WpD121C-uE39agVerfrrbJQApzk=.9e2ac3d3-b898-4cd1-8c8d-5c47b8365577@github.com>

On Sun, 12 Oct 2025 00:06:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3330092146

From rrich at openjdk.org  Mon Oct 13 06:19:05 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 13 Oct 2025 06:19:05 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v7]
In-Reply-To: <h3QHxWsMFPKUPyyOJaQpSyOcy1P6tEhYeAMbLzoYECo=.48f49e91-d53f-413c-ab1e-e70c8b8529ba@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <d87QgM565HoHlAlAyuRd76gKcdzIuX2r2egD-EOWmSI=.b774824d-c93f-44be-b8f3-109e1d5abd91@github.com>
 <h3QHxWsMFPKUPyyOJaQpSyOcy1P6tEhYeAMbLzoYECo=.48f49e91-d53f-413c-ab1e-e70c8b8529ba@github.com>
Message-ID: <p5aodafmWpb5ccwuOrWAQxGu3hDmxUKlI8uKr9Dk7pQ=.fac4c426-1b3b-4c93-92be-6282538353d0@github.com>

On Fri, 10 Oct 2025 21:36:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comments
>
> src/hotspot/cpu/ppc/atomicAccess_ppc.hpp line 268:
> 
>> 266:     /* in */
>> 267:     : [dest]                   "b"     (dest),
>> 268:       [masked_compare_value]   "r"     (masked_compare_value),
> 
> Typo: masked_compare_val. Please fix!

I wonder why there are no tests. Do you know?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27650#discussion_r2425305854

From aboldtch at openjdk.org  Mon Oct 13 06:22:49 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 06:22:49 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 [v2]
In-Reply-To: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
Message-ID: <Le5nUytDTqbQV6pGR7mrt16Wye3J-55mwUg3T0ENhEM=.1d9cf77c-2abc-4135-bc73-5dbc95207d49@github.com>

> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
> However the current implementation does not do this correctly in all places, where it does:
> 
>   static bool initialized = false;
>   if (!initialized) {
>     ...
>     initialized = true;
>   }
> 
> It should do
> 
> static bool initialized = initialize_impl(); // Do the logic inside a function call
> 
> to guarantee that initialize is only called once.
> 
> We have observed this from some GC threads if we start using Ticks to early.
> 
> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27712/files
  - new: https://git.openjdk.org/jdk/pull/27712/files/93e2d96a..d9524470

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27712&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27712&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27712/head:pull/27712

PR: https://git.openjdk.org/jdk/pull/27712

From stefank at openjdk.org  Mon Oct 13 06:22:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Oct 2025 06:22:50 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 [v2]
In-Reply-To: <Le5nUytDTqbQV6pGR7mrt16Wye3J-55mwUg3T0ENhEM=.1d9cf77c-2abc-4135-bc73-5dbc95207d49@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
 <Le5nUytDTqbQV6pGR7mrt16Wye3J-55mwUg3T0ENhEM=.1d9cf77c-2abc-4135-bc73-5dbc95207d49@github.com>
Message-ID: <3Y9lUtTyYnkCmC9d_QVBJXG0kBMYD7N63i4kGDNJjdE=.a94bc867-9675-4781-a5f1-64043e02712d@github.com>

On Mon, 13 Oct 2025 06:19:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
>> However the current implementation does not do this correctly in all places, where it does:
>> 
>>   static bool initialized = false;
>>   if (!initialized) {
>>     ...
>>     initialized = true;
>>   }
>> 
>> It should do
>> 
>> static bool initialized = initialize_impl(); // Do the logic inside a function call
>> 
>> to guarantee that initialize is only called once.
>> 
>> We have observed this from some GC threads if we start using Ticks to early.
>> 
>> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27712#pullrequestreview-3330103650

From jsjolen at openjdk.org  Mon Oct 13 06:45:02 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 13 Oct 2025 06:45:02 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <rLWQp4I1uJn8-Vmsf-ZzS5V4X-KcoCicXhpHPSHmO-o=.75665d3e-ba1c-4f08-a8ad-102b35a6bddb@github.com>

On Fri, 10 Oct 2025 13:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

Changes requested by jsjolen (Reviewer).

src/hotspot/share/oops/trainingData.cpp line 475:

> 473: #if INCLUDE_CDS
> 474:     TrainingDataLocker::snapshot();
> 475: #endif

Is this actually needed? Seems like `snapshot()` already protects us.


    static void snapshot() {
#if INCLUDE_CDS
      assert_locked();
      _snapshot = true;
#endif
    }

-------------

PR Review: https://git.openjdk.org/jdk/pull/27744#pullrequestreview-3330150623
PR Review Comment: https://git.openjdk.org/jdk/pull/27744#discussion_r2425339193

From dbriemann at openjdk.org  Mon Oct 13 07:16:06 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Mon, 13 Oct 2025 07:16:06 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v8]
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27650/files
  - new: https://git.openjdk.org/jdk/pull/27650/files/d182588e..f43feb31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27650&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27650&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27650/head:pull/27650

PR: https://git.openjdk.org/jdk/pull/27650

From fyang at openjdk.org  Mon Oct 13 07:21:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 13 Oct 2025 07:21:05 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v6]
In-Reply-To: <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
Message-ID: <XVMp6Zb_IWlX7nXdjWosUhRZi_BXJ5VPQw3YCDQeLwY=.c0f3280e-592d-4e80-b945-28967d6db993@github.com>

On Fri, 10 Oct 2025 08:17:44 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> 
>> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
>> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
>> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
>> 
>> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

Latest version LGTM. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27562#pullrequestreview-3330240318

From mbaesken at openjdk.org  Mon Oct 13 07:34:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 07:34:42 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails [v2]
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove not needed macro in trainingData.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27744/files
  - new: https://git.openjdk.org/jdk/pull/27744/files/13b3a872..8d69ea9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27744&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27744/head:pull/27744

PR: https://git.openjdk.org/jdk/pull/27744

From aboldtch at openjdk.org  Mon Oct 13 07:51:13 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 07:51:13 GMT
Subject: RFR: 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version
 stub area
In-Reply-To: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
References: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
Message-ID: <j-xoBPrYIy2UIeulA9CQngI0SxCAv1_PZ-EhLJ1b3SA=.4a5056bf-241a-4e32-84d8-999806e0b983@github.com>

On Thu, 9 Oct 2025 05:59:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently these stubs are created in `Rdtsc::initialize` which may be called from the first ElapsedCounter now call. This causes problems with lock ranks as we may be holding a lock while taking time, because we need to lock the code cache to create a stub.
> 
> I suggest we move the `getCPUIDBrandString_stub` next to the other `VM_Version` stubs and generate them together. This is done at the earliest point we can, right after the CodeCache system has been initialized.

Thanks for the reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27711#issuecomment-3396269806

From aboldtch at openjdk.org  Mon Oct 13 07:51:14 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 07:51:14 GMT
Subject: Integrated: 8369468: Rdtsc: Move getCPUIDBrandString_stub into
 VM_Version stub area
In-Reply-To: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
References: <NbzFtX9AipQaP8iXE9Zke5W62Kai6aYWjGugPWcao-Q=.eb04c00e-1e90-402e-aa46-f4ef3fc54274@github.com>
Message-ID: <WFtoxU-_JRgkAoSKNcFdMN8dWWXi9wSpXwUb9lBHCAA=.41e8b201-5c8e-4b7e-8535-c4988fd98c84@github.com>

On Thu, 9 Oct 2025 05:59:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently these stubs are created in `Rdtsc::initialize` which may be called from the first ElapsedCounter now call. This causes problems with lock ranks as we may be holding a lock while taking time, because we need to lock the code cache to create a stub.
> 
> I suggest we move the `getCPUIDBrandString_stub` next to the other `VM_Version` stubs and generate them together. This is done at the earliest point we can, right after the CodeCache system has been initialized.

This pull request has now been integrated.

Changeset: a6f624b0
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6f624b0743a1e0a3df4e8323c13b0d1fd6d0002
Stats:     29 lines in 3 files changed: 4 ins; 24 del; 1 mod

8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Reviewed-by: mgronlun, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/27711

From luhenry at openjdk.org  Mon Oct 13 07:52:08 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 13 Oct 2025 07:52:08 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler
In-Reply-To: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
Message-ID: <DtjyL0yoSsOj6qVdRahT3eDVEsnXFe1AgNpUCF2uUno=.63804a88-c50e-4929-a166-e263120d16a0@github.com>

On Sat, 11 Oct 2025 12:48:46 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
> 
> Testing:
> - [x] tier1-3

src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp line 43:

> 41:   void clear(void) {
> 42:     // No hardware barriers are necessary. All members are volatile and the profiler
> 43:     // is run from a signal handler and only observers the thread its running on.

Suggestion:

    // is run from a signal handler and the only observer is the thread its running on.

src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp line 53:

> 51:   void copy(JavaFrameAnchor* src) {
> 52:     // No hardware barriers are necessary. All members are volatile and the profiler
> 53:     // is run from a signal handler and only observers the thread its running on.

Suggestion:

    // is run from a signal handler and the only observer is the thread its running on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27757#discussion_r2425469047
PR Review Comment: https://git.openjdk.org/jdk/pull/27757#discussion_r2425469514

From aboldtch at openjdk.org  Mon Oct 13 08:11:44 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 08:11:44 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 [v3]
In-Reply-To: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
Message-ID: <tyltBRnL-OZkWORNMmd2jqXMS2nwH2Hu3d7ug3lS14Y=.82641a7b-92d5-4bb7-85f0-ab588f9b8ac3@github.com>

> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
> However the current implementation does not do this correctly in all places, where it does:
> 
>   static bool initialized = false;
>   if (!initialized) {
>     ...
>     initialized = true;
>   }
> 
> It should do
> 
> static bool initialized = initialize_impl(); // Do the logic inside a function call
> 
> to guarantee that initialize is only called once.
> 
> We have observed this from some GC threads if we start using Ticks to early.
> 
> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.

Axel Boldt-Christmas 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 remote-tracking branch 'upstream_jdk/master' into JDK-8369469
 - Fix typo
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27712/files
  - new: https://git.openjdk.org/jdk/pull/27712/files/d9524470..53db5867

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27712&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27712&range=01-02

  Stats: 4447 lines in 119 files changed: 3167 ins; 903 del; 377 mod
  Patch: https://git.openjdk.org/jdk/pull/27712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27712/head:pull/27712

PR: https://git.openjdk.org/jdk/pull/27712

From mli at openjdk.org  Mon Oct 13 08:14:13 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 08:14:13 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v6]
In-Reply-To: <XVMp6Zb_IWlX7nXdjWosUhRZi_BXJ5VPQw3YCDQeLwY=.c0f3280e-592d-4e80-b945-28967d6db993@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
 <XVMp6Zb_IWlX7nXdjWosUhRZi_BXJ5VPQw3YCDQeLwY=.c0f3280e-592d-4e80-b945-28967d6db993@github.com>
Message-ID: <STRSX4fJZKpFd2yxN0jEkHE2x3vclWP7N-f4b94dq6s=.520fbebf-74ff-4221-b016-7ac35f488e51@github.com>

On Mon, 13 Oct 2025 07:18:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Latest version LGTM. Thanks.

Thank you!

@RealFYang Can you have a look at https://github.com/openjdk/jdk/pull/27572? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3396348221

From mli at openjdk.org  Mon Oct 13 08:14:15 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 08:14:15 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v4]
In-Reply-To: <3hkT1x_jjhRREPVpaTZpAyZBBN36emMP3H5MLcWesdw=.51f5666c-03f7-44b1-9c69-f63308bc05da@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <UEmr3h4-bi-rP_O2acM9H8qiodj5vZqQmUZJh3zSHi0=.d268ffeb-1f59-43ee-b8ad-8cda1f60b1c9@github.com>
 <1z5hQirRwwsgJK7n_rb_lRb5mygb8d8Spc1RVPm1fIA=.eb52d116-5471-47ae-9c50-7aa4808e5459@github.com>
 <LeZiwW5tZ-CXHfCh9YuNJ3XQAn8-MmZta2NpLQ4cN3o=.55b872bd-20e8-4da7-bf79-cb5f3e3908fb@github.com>
 <3hkT1x_jjhRREPVpaTZpAyZBBN36emMP3H5MLcWesdw=.51f5666c-03f7-44b1-9c69-f63308bc05da@github.com>
Message-ID: <JmaYDO7vOkPd0mQqatSL5YSqsBnMSGyQBUpzLjOrZYI=.b1b2d03d-bfa2-4a6f-9cc6-3b5709163216@github.com>

On Mon, 6 Oct 2025 15:55:36 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>>> Hey, I don't get the premise.
>>> 
>>> VMVersion have a bunch of methods e.g VM_Version::supports_data_cache_line_flush() / VM_Version::get_current_sve_vector_length, etc.... Now we call some of them "non_ext_UnalignedScalar()", why ? And how is this a improvement ?
>>> 
>>> VM_Version methods is not related to whatever or not some information we need is part of an RVI extension.
>>> 
>>> E.g. VMVersion::unaligned_scalar() (hotspot don't do camel case) seems more reasonable.
>> 
>> I don't have a preference to the name, either `unaligned_scalar` or `non_ext_UnalignedScalar`. Let's see how others think about it, then I'll modify accordingly.
>
>> > Hey, I don't get the premise.
>> > VMVersion have a bunch of methods e.g VM_Version::supports_data_cache_line_flush() / VM_Version::get_current_sve_vector_length, etc.... Now we call some of them "non_ext_UnalignedScalar()", why ? And how is this a improvement ?
>> > VM_Version methods is not related to whatever or not some information we need is part of an RVI extension.
>> > E.g. VMVersion::unaligned_scalar() (hotspot don't do camel case) seems more reasonable.
>> 
>> I don't have a preference to the name, either `unaligned_scalar` or `non_ext_UnalignedScalar`. Let's see how others think about it, then I'll modify accordingly.
> 
> 
> Camel case is not an opinion: "and function names are lower-case (foo_bar). (For these, avoid mixing in upper case letters.)"
> https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names
> See e.g. : https://github.com/openjdk/jdk/blob/b6a4cfecb731615b6ef70828ac10fae4b2264cdc/src/hotspot/share/runtime/abstract_vm_version.hpp

@robehn Can you have another look? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3396348983

From sgehwolf at openjdk.org  Mon Oct 13 08:18:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 13 Oct 2025 08:18:10 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <mzbEojjWWHqU2Zhn1GMGg7_80MUV7Hae6zN6mj0nR8U=.ab939c67-890d-4266-99b7-2464ee74627f@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <mzbEojjWWHqU2Zhn1GMGg7_80MUV7Hae6zN6mj0nR8U=.ab939c67-890d-4266-99b7-2464ee74627f@github.com>
Message-ID: <IL0lKjDCxudiA5UWbBXdSAW_aringz1bImxIPN8NunU=.83dce077-bf45-41ca-95a7-8d6564846969@github.com>

On Mon, 13 Oct 2025 01:46:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There seems to be some collision here with JDK-[8367319](https://github.com/openjdk/jdk/pull/27646/)

Thanks, yes, I'm aware. We'll resolve conflicts once we know which one goes in first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3396358387

From aboldtch at openjdk.org  Mon Oct 13 08:32:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 08:32:03 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Check !cont.entry()->is_virtual_thread()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27716/files
  - new: https://git.openjdk.org/jdk/pull/27716/files/4ec7ce98..d5a2cc0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27716&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27716.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27716/head:pull/27716

PR: https://git.openjdk.org/jdk/pull/27716

From aboldtch at openjdk.org  Mon Oct 13 08:34:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 08:34:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
Message-ID: <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>

On Fri, 10 Oct 2025 06:29:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - sspitsyn patch
>  - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state"
>    
>    This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d.

Pushed the latest patch. 

The intent of this bug fix was to solve the safepoint (check) issue. 

Is there anything else we should fix as part of this bug fix? Especially given that there is interest in back-porting JDK-8368159.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3396411952

From mdoerr at openjdk.org  Mon Oct 13 08:39:09 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 08:39:09 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <_0ZcJObJkDe2Yz4h_YLAjNtH3PSk7fsVDqWE1z7N_K8=.527b9fb6-05b2-4e6d-8729-ee63c8d6fc87@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Test results look good on all SAP supported platforms (including linux and AIX on PPC64).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3396428112

From jsjolen at openjdk.org  Mon Oct 13 08:44:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 13 Oct 2025 08:44:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
 <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>
Message-ID: <ldP6l9HXdO3wyvdyjBPCamdbiNFE4iErR11AATcN7s4=.b118610e-b617-401a-8252-ad45f371b45d@github.com>

On Wed, 8 Oct 2025 18:48:12 GMT, John R Rose <jrose at openjdk.org> wrote:

>> I have a different take on the distinction between forbidden and undecided. I
>> think of forbidden features as being those where there are good arguments
>> against. Whereas I think of undecided as perhaps having wishy washy arguments
>> in either direction, or even not seriously thought about. But good arguments
>> against can be overcome by better arguments in favor.
>> 
>> But I can see how someone else might take that distinction differently.
>> 
>> I also admit to being somewhat biased against tuple in particular. I've seen
>> a few pretty terrible uses... one was even my fault!
>> 
>> So okay, I'll recategorize tuple.
>
> I'm OK with cracking the door open on tuple, but I have to say I do like API-specific names very much.  (And `fst`/`snd` or whatever are not API specific; they are tuple-specific!)  So the guidance that steers folks towards name-based techniques, instead of positional techniques, is still sound.
> 
> I even like out-args, personally, in cases where the out-arg is for a return value that is clearly secondary to the main return value.  Example:  Main value is boolean, and out-arg is some hint about why the main value is what it is, like a position.  The out-arg can also be optional if a null pointer is tolerated (explicitly documented as such, of course), which is useful when the out-arg costs extra to compute.  (A separate boolean arg is OK for such uses also, but null pointers are so darn useful as optionality sentinels!)  Note that our TRAPS/THREAD macro system can be viewed as a giant set of out-args.

Often, we can use more "specialized" tuples like `Maybe<T, Error>`, in which case it's fine to have the 'generic' `_value`, `_error` slots. Having a bigger sign saying "hey, hey!! this might fail!!!!" is good, it makes bugs related to missing error handling more shallow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2425580500

From mli at openjdk.org  Mon Oct 13 08:55:08 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 08:55:08 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <jt9wJIMO-gVRlFAtbRTZAARD64MuJCAOVaII2-FkEtw=.c784ba09-bf5b-4d5f-8214-d3cfb9c0a640@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Riscv part looks good, Thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3330540170

From rehn at openjdk.org  Mon Oct 13 09:27:14 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 13 Oct 2025 09:27:14 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v6]
In-Reply-To: <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
Message-ID: <FgpDPJ-wvZD85XhADrnMIEsEZO9bR-35n9y2NYAlGwk=.f9502753-91bf-46bf-9c58-d0a4c94ae93d@github.com>

On Fri, 10 Oct 2025 08:17:44 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> 
>> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
>> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
>> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
>> 
>> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

Ack !

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27562#pullrequestreview-3330653748

From mdoerr at openjdk.org  Mon Oct 13 09:48:11 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 09:48:11 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails [v2]
In-Reply-To: <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
 <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
Message-ID: <0iAezdJ9OudP1yAqydzGjN6QqSrwsbdhUiUZEpsr-qc=.4af6adb4-4ba2-4a41-a1c7-d0f1d9d7c2d4@github.com>

On Mon, 13 Oct 2025 07:34:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Slowdebug builds without CDS fail, this was noticed on AIX.
>> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
>> 
>> 
>> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
>> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
>> collect2: error: ld returned 1 exit status
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not needed macro in trainingData.cpp

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27744#pullrequestreview-3330724944

From alanb at openjdk.org  Mon Oct 13 09:51:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 09:51:10 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
Message-ID: <61w8E0BpN40jLzkmF8Yslw2ouRneaninNCWhr3b9SW8=.6562492c-345e-4bf5-a2f9-c9a4dec39097@github.com>

On Thu, 9 Oct 2025 13:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Questions that this change brings up to me:
> 
> Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area? If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

It's similar to standard APIs vs. JDK-specific APIs. A management interface with HotSpot VM or JDK-specific attributes or operations would be a candidate for the jdk.management module rather than the java.management module. 

I wasn't directly involved in JSR-174 but there were three VM vendors in the EG at the time. The management interfaces that were defined had to be feasible to implement on all. There was interest in further management interfaces and the Sun JDK defined its extensions in com.sun.management. The word "extension" is significant here because asking the platform MBeanServer for a standard MXBean (either directly or via the standard object name) provides access to additional attributes/operations defined by the extension. It might seem a bit strange to see csm.ThreadMXBean extends jlm.ThreadMXBean, but that was the pattern established back in JDK 5. A lookup of say "java.lang:type=Threading" gives access to csm.ThreadMXBean with the additional attributes and operations defined in the subclass. It may be that some of the attributes or operations in these extensions could be proposed for the standard management interfaces, not clear if this is worth doing. TBH, I think the bigger issue is th
 at these management interfaces haven't evolved significantly, they pre-date fully concurrent GCs and other significant improvements.

Note that are some management interfaces that are clearly HotSpot VM or JDK-specific, e.g. csm.HotSpotDiagnosticMXBean and jdk.management.VirtualThreadSchedulerMXBean.

As regards the proposal here. I think the API docs will need work. The standard APIs don't know about non-Java threads. This is why it can't speak of "driver threads" and the "VM thread". It seems reasonable to introduce the notion that garbage collection consuming CPU cycle but anything about STW vs. concurrent GCs is more for an implNote. One of the goals, as I understand it, is to use it in conjunction with JDK-specific OperatingSystemMXBean "processCpuTime" attribute. It's possible to cross link in API docs but its relation to that attribute can't be normative if in a standard API. So I think focus on the specifying the attribute first. So far I think Jonas has demonstrated that it is feasible to implementation as either a standard or extension.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3396681608

From mdoerr at openjdk.org  Mon Oct 13 09:51:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 09:51:15 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v8]
In-Reply-To: <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
Message-ID: <9B8gGVlooeCXICuGZOUhov8OR_MMBLL__4mcTvB84hk=.e4cf919e-afaf-4bb4-b117-3ed6e761c7fb@github.com>

On Mon, 13 Oct 2025 07:16:06 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3330734445

From sspitsyn at openjdk.org  Mon Oct 13 09:58:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Oct 2025 09:58:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <VLzXf7S8Vl7tsz8B9p5udo8b6AdaveGAgMXP9G0mLt8=.e4463a25-9992-4367-a7c7-5557dd7391cc@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Looks good. Thank you for taking care about this!

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3330756505

From mbaesken at openjdk.org  Mon Oct 13 10:15:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 10:15:40 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails [v2]
In-Reply-To: <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
 <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
Message-ID: <e7f4itFuN_VBwVgnYolx_OmdGDF5xx8BpJxLr1U8JUw=.570ce382-f1d4-4b16-b8d9-c1fd1d566a4b@github.com>

On Mon, 13 Oct 2025 07:34:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Slowdebug builds without CDS fail, this was noticed on AIX.
>> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
>> 
>> 
>> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
>> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
>> collect2: error: ld returned 1 exit status
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not needed macro in trainingData.cpp

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27744#issuecomment-3396788813

From mbaesken at openjdk.org  Mon Oct 13 10:18:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 13 Oct 2025 10:18:59 GMT
Subject: Integrated: 8369560: Slowdebug build without CDS fails
In-Reply-To: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
Message-ID: <b5RmIsMCNMdBZ0awoG-D9PyfeMrMOjYviZUYIJxyUGg=.3e95c92f-62b6-4465-893f-cfe55b632cef@github.com>

On Fri, 10 Oct 2025 13:51:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Slowdebug builds without CDS fail, this was noticed on AIX.
> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
> 
> 
> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
> collect2: error: ld returned 1 exit status

This pull request has now been integrated.

Changeset: 0af959a3
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0af959a340fe68caa47fc476ff861f0e86087162
Stats:     7 lines in 3 files changed: 6 ins; 1 del; 0 mod

8369560: Slowdebug build without CDS fails

Reviewed-by: mdoerr, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/27744

From sjohanss at openjdk.org  Mon Oct 13 10:30:15 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 13 Oct 2025 10:30:15 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v4]
In-Reply-To: <sndhDHP_SpmYc7_jHwGO9M4QKZu3ODGdaH1CGQV6kjQ=.acbb83c8-c550-475f-8611-f2ead28ab793@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
 <sndhDHP_SpmYc7_jHwGO9M4QKZu3ODGdaH1CGQV6kjQ=.acbb83c8-c550-475f-8611-f2ead28ab793@github.com>
Message-ID: <KM2HWE5l4qsuLrqRW_YHEda7ZNP3sJDRuz6o-Ou_I-U=.beb5d250-4536-40c1-bda4-45074878ae6e@github.com>

On Sun, 5 Oct 2025 13:30:27 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
>> 
>> ---
>> 
>> Following the direction outlined in the issue description,
>> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
>> 
>> I've confirmed that it works without issues in my local tests.
>> 
>> Reviews and feedback are welcome.
>
> jonghoonpark 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:
> 
>   Refactor: Introduce Smaps class for testing
>   
>   Signed-off-by: jonghoonpark <dev at jonghoonpark.com>

Now I've had time to look through this and more or less nothing more to add, just a small update to one comment. 

Did run some additional testing as well, which looked good. 

Please also add me ass co-author since we now have collaborated on the change, just use the commands:

test/lib/jdk/test/lib/os/linux/Smaps.java line 167:

> 165:     // ...
> 166:     // KernelPageSize:        4 kB
> 167:     // ...

Suggestion:

    // ...
    // THPeligible:           0
    // ...    

Pre-existing, but we should update the comment to include that we also care about THPeligible.

-------------

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27273#pullrequestreview-3330863912
PR Review Comment: https://git.openjdk.org/jdk/pull/27273#discussion_r2425841317

From dholmes at openjdk.org  Mon Oct 13 10:34:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Oct 2025 10:34:08 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 [v3]
In-Reply-To: <tyltBRnL-OZkWORNMmd2jqXMS2nwH2Hu3d7ug3lS14Y=.82641a7b-92d5-4bb7-85f0-ab588f9b8ac3@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
 <tyltBRnL-OZkWORNMmd2jqXMS2nwH2Hu3d7ug3lS14Y=.82641a7b-92d5-4bb7-85f0-ab588f9b8ac3@github.com>
Message-ID: <akuaodzlASd_ek7V7d9mzZEVnQj7_S6B4kMBopPPXQw=.5b648f05-1074-46ab-98d9-69488f54a59a@github.com>

On Mon, 13 Oct 2025 08:11:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
>> However the current implementation does not do this correctly in all places, where it does:
>> 
>>   static bool initialized = false;
>>   if (!initialized) {
>>     ...
>>     initialized = true;
>>   }
>> 
>> It should do
>> 
>> static bool initialized = initialize_impl(); // Do the logic inside a function call
>> 
>> to guarantee that initialize is only called once.
>> 
>> We have observed this from some GC threads if we start using Ticks to early.
>> 
>> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.
>
> Axel Boldt-Christmas 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 remote-tracking branch 'upstream_jdk/master' into JDK-8369469
>  - Fix typo
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
>  - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27712#pullrequestreview-3330911163

From mli at openjdk.org  Mon Oct 13 10:36:19 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 10:36:19 GMT
Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS [v6]
In-Reply-To: <FgpDPJ-wvZD85XhADrnMIEsEZO9bR-35n9y2NYAlGwk=.f9502753-91bf-46bf-9c58-d0a4c94ae93d@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
 <_fzwggL5BkgZrC02xdXTHv9CGmlfSp86sB_4aX15_bU=.d8e00b30-683f-4c0e-9e09-19a805bc7d83@github.com>
 <FgpDPJ-wvZD85XhADrnMIEsEZO9bR-35n9y2NYAlGwk=.f9502753-91bf-46bf-9c58-d0a4c94ae93d@github.com>
Message-ID: <YN958soioztJTRDQ8rnQkq88NOPsjeaJF2oihwq8ioU=.729fa217-5a2b-4586-b5e0-7ae7abd3455c@github.com>

On Mon, 13 Oct 2025 09:24:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Ack !

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3396869930

From mli at openjdk.org  Mon Oct 13 10:36:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 10:36:20 GMT
Subject: Integrated: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS &
 RV_NON_EXT_FEATURE_FLAGS
In-Reply-To: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
References: <PJipKmd2ng9fDzEP2p9ay0h0cZ4LsImmX65jVqXPCAg=.8841e0a6-73c6-4bae-85ac-35903eaec0e8@github.com>
Message-ID: <azfp-L7AFlR_nN9CScmSPaJ7hoVAeFJX9Ay3MTjSNv4=.28ff20c0-aefc-42e5-bbf6-bdc3106cf287@github.com>

On Mon, 29 Sep 2025 21:37:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> 
> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820:
> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS
> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS
> 
> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this  assert (<del>is not necessary</del>, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 28460ca3
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28460ca3305a444238e6edcc80e335be20356e6d
Stats:     168 lines in 4 files changed: 42 ins; 46 del; 80 mod

8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS

Reviewed-by: fyang, rehn

-------------

PR: https://git.openjdk.org/jdk/pull/27562

From krk at openjdk.org  Mon Oct 13 11:12:46 2025
From: krk at openjdk.org (Kerem Kat)
Date: Mon, 13 Oct 2025 11:12:46 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v3]
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <7TYnbiOnvYocn_KWhbncjeoNZi2wsfsK5_bn8INITqc=.3882923b-cb5e-4f2b-8024-72dc7927569b@github.com>

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat 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 three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
 - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
 - 8334866: Cache debug_aranges for faster address lookups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/3f8b7a4e..fe32a078

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=01-02

  Stats: 154686 lines in 1819 files changed: 130062 ins; 14981 del; 9643 mod
  Patch: https://git.openjdk.org/jdk/pull/27337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337

PR: https://git.openjdk.org/jdk/pull/27337

From jpai at openjdk.org  Mon Oct 13 11:14:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 Oct 2025 11:14:08 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <RTx-AAwtz37KRyTmKChREbrWrQBIiW14P86H5hp1DGQ=.2edbc9f8-b68f-4333-859e-257c3d012ebd@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331114106

From duke at openjdk.org  Mon Oct 13 11:45:02 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 13 Oct 2025 11:45:02 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge from the main branch
 - Address review comments
 - Address review comments
 - Address review comments
 - The patch is contributed by @TheRealMDoerr
 - Offset the deoptimization handler entry point
   
   Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
 - Revert "Ensure stub code is not adjacent to a call"
 - Ensure stub code is not adjacent to a call
 - Address review comments
 - 8365047: Remove exception handler stub code in C2
   
   The C2 exception handler stub code is only a trampoline to the
   generated exception handler blob. This change removes the extra
   step on the way to the generated blob.
   
   According to some comments in the source code, the exception handler
   stub code used to be patched upon deoptimization, however presumably
   these comments are outdated as the patching upon deoptimization happens
   for post-call NOPs only.

-------------

Changes: https://git.openjdk.org/jdk/pull/26678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=06
  Stats: 376 lines in 37 files changed: 98 ins; 212 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/26678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678

PR: https://git.openjdk.org/jdk/pull/26678

From duke at openjdk.org  Mon Oct 13 11:49:21 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 13 Oct 2025 11:49:21 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5]
In-Reply-To: <pQEeXRn0BGkvHDMZx4rznPIGvqj1KdrDZTsii9H64B0=.6fda502d-d48b-4355-9986-61ed384d46b9@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <RRBHEANMwk5TyEPkAaxJrPEHwBNJREoWUwB1vEY7Kec=.583fbe61-46a0-4143-8244-4d15384a53bc@github.com>
 <mk_eykgSPSzczsDhuvDWMf4FT52Y56N1hxt4bpJmMJY=.32ae7162-8abc-4bb6-b398-308d0b8a1cff@github.com>
 <ZH2HI7Mjj-eS3lG0XqcvP5HhoAufj_I63_XVskDMPqw=.6f49fad1-ba76-445a-8b4d-8146574b107b@github.com>
 <pQEeXRn0BGkvHDMZx4rznPIGvqj1KdrDZTsii9H64B0=.6fda502d-d48b-4355-9986-61ed384d46b9@github.com>
Message-ID: <Vrxfn4OCziv6KmGpnI7U5QfkCNubKMCeNjwbIqCP6WU=.d1a803e9-3783-420d-96a5-0aa83c65d287@github.com>

On Mon, 29 Sep 2025 10:36:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thanks for the feedback. I followed the current guideline at https://openjdk.org/guide/#copyright-headers which advises:
>> 
>>> If your affiliation doesn?t have a copyright notice, again consult your legal representative to see if you should add one.
>> 
>> If the guideline isn't applicable or if there is a more detailed guidance on when Copyright header should or should not be added, I'd appreciate further advice.
>
> Here are some arguments why I wouldn't do it:
> - We usually don't add Copyright headers to existing files. Only to new ones we created. Many contributors are doing the same AFAIK. (Maybe only for very significant contributions to a file.)
> - The Linux Foundation has listed reasons "Why not list every copyright holder?" https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects
> - OpenJDK headers say "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER."

@TheRealMDoerr, @bulasevich,
Thank you for your detailed response.
I've removed these lines following your request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2426097487

From jkern at openjdk.org  Mon Oct 13 11:51:44 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 13 Oct 2025 11:51:44 GMT
Subject: RFR: 8369560: Slowdebug build without CDS fails [v2]
In-Reply-To: <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
References: <a90LZU7cW_mdTY7HUhkYoX8chJA1IR_PhlLX4E9Wz6s=.fd5585e1-8bbf-4809-9062-c82fbe6f0a24@github.com>
 <k8BmzoVcYCg3ASh0GXZ6-IsHke2viJ8V7zjV2W1q-Tg=.b28b7149-2af0-49c7-b6cc-16bf82499223@github.com>
Message-ID: <m9WfwXl7nW_XasYqcfMZER-9uSCQokBRwy2hizFgJkA=.5afca9ca-fcbe-4683-9882-1b4fc0563a26@github.com>

On Mon, 13 Oct 2025 07:34:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Slowdebug builds without CDS fail, this was noticed on AIX.
>> On Linux x86_64 (when using --with-debug-level=slowdebug --disable-cds ) I get a little better error messages , pointing already to code locations :
>> 
>> 
>> /jdk/src/hotspot/share/oops/trainingData.hpp:155: error: undefined reference to 'TrainingData::TrainingDataLocker::_snapshot'
>> /jdk/src/hotspot/share/classfile/vmClasses.cpp:123: error: undefined reference to 'AOTLinkedClassBulkLoader::preload_classes(JavaThread*)'
>> collect2: error: ld returned 1 exit status
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not needed macro in trainingData.cpp

src/hotspot/share/oops/trainingData.cpp line 474:

> 472:     TrainingDataLocker l;
> 473:     TrainingDataLocker::snapshot();
> 474: 

Could you please add the line again, so that trainingsData.cpp remains unchanged by this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27744#discussion_r2426102795

From aboldtch at openjdk.org  Mon Oct 13 12:20:21 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 12:20:21 GMT
Subject: RFR: 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 [v3]
In-Reply-To: <tyltBRnL-OZkWORNMmd2jqXMS2nwH2Hu3d7ug3lS14Y=.82641a7b-92d5-4bb7-85f0-ab588f9b8ac3@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
 <tyltBRnL-OZkWORNMmd2jqXMS2nwH2Hu3d7ug3lS14Y=.82641a7b-92d5-4bb7-85f0-ab588f9b8ac3@github.com>
Message-ID: <roeok5XGZ0ueb2_2Vxvs0Gsifjlsg8Lm8_1P7_PcpOc=.0e5a3c91-be78-4bd4-ae42-89fa0e3f670a@github.com>

On Mon, 13 Oct 2025 08:11:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
>> However the current implementation does not do this correctly in all places, where it does:
>> 
>>   static bool initialized = false;
>>   if (!initialized) {
>>     ...
>>     initialized = true;
>>   }
>> 
>> It should do
>> 
>> static bool initialized = initialize_impl(); // Do the logic inside a function call
>> 
>> to guarantee that initialize is only called once.
>> 
>> We have observed this from some GC threads if we start using Ticks to early.
>> 
>> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.
>
> Axel Boldt-Christmas 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 remote-tracking branch 'upstream_jdk/master' into JDK-8369469
>  - Fix typo
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
>  - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Thanks for the reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27712#issuecomment-3397278520

From aboldtch at openjdk.org  Mon Oct 13 12:20:23 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 12:20:23 GMT
Subject: Integrated: 8369469: Rdtsc: Remove potential races in
 Rdtsc::initialize
In-Reply-To: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
References: <2nRG5QrCVcrlbegh4f50VUULNEDxqTz4Cp4gLRpU4V4=.fadfe5db-a07d-4b61-b2dd-7f79e8a97ccf@github.com>
Message-ID: <yBmDhtvapS6L_im_YuoQbW4T8ndWx0r2E_9h1LnoN60=.fb334733-9407-4272-b66e-353633dd5288@github.com>

On Thu, 9 Oct 2025 06:18:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The whole chain of Rdtsc uses static block scope variables which are guaranteed to be constructed only once (implements some sort of double checked locking).
> However the current implementation does not do this correctly in all places, where it does:
> 
>   static bool initialized = false;
>   if (!initialized) {
>     ...
>     initialized = true;
>   }
> 
> It should do
> 
> static bool initialized = initialize_impl(); // Do the logic inside a function call
> 
> to guarantee that initialize is only called once.
> 
> We have observed this from some GC threads if we start using Ticks to early.
> 
> The suggested patch makes `Rdtsc::initialize` private an is only called from the `Rdtsc::enabled` which uses a static bock scoped variable to ensure the call once semantics. The property called from outside is now  `Rdtsc::enabled`. Which is more true to what how it is used on all call sites.

This pull request has now been integrated.

Changeset: d47e6b71
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d47e6b713c77d9e2f477f05291e8772129a5471c
Stats:     65 lines in 4 files changed: 25 ins; 17 del; 23 mod

8369469: Rdtsc: Remove potential races in Rdtsc::initialize

Reviewed-by: dholmes, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/27712

From rrich at openjdk.org  Mon Oct 13 12:42:54 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 13 Oct 2025 12:42:54 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v8]
In-Reply-To: <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
Message-ID: <w_ZHwHW_XLeH8vCXkqhNMktpyHAkaaJDCL-2ue3nLCs=.308f9ad5-88c4-4719-a0e3-3928845efd17@github.com>

On Mon, 13 Oct 2025 07:16:06 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by rrich (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27650#pullrequestreview-3331468249

From aboldtch at openjdk.org  Mon Oct 13 12:43:24 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 12:43:24 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v3]
In-Reply-To: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
Message-ID: <DJ8qlIfAFjeVVsUsnlHDGBuBeO4qklj8ruN1HS0CkWg=.f78f9bc8-befd-4522-b8a1-437428bf94cf@github.com>

> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
> 
> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8369467
 - Rdtsc: Remove experimental support for non invariant tsc
 - 8369467: Rdtsc: Avoid initialize_elapsed_counter when UseFastUnorderedTimeStamps will be disabled
 - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
 - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

-------------

Changes: https://git.openjdk.org/jdk/pull/27713/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27713&range=02
  Stats: 102 lines in 2 files changed: 6 ins; 81 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27713/head:pull/27713

PR: https://git.openjdk.org/jdk/pull/27713

From mli at openjdk.org  Mon Oct 13 13:11:28 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 13 Oct 2025 13:11:28 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to RVFeatureValue::enabled
Message-ID: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>

Hi,
Can you help to review this patch?
@RealFYang 

Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
And also do some simple refactoring related to enable/disable/enabled and so on.

Thanks

-------------

Commit messages:
 - minor
 - minor
 - initial commit
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 4 more: https://git.openjdk.org/jdk/compare/28460ca3...48c78ad9

Changes: https://git.openjdk.org/jdk/pull/27771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369685
  Stats: 41 lines in 2 files changed: 10 ins; 23 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27771/head:pull/27771

PR: https://git.openjdk.org/jdk/pull/27771

From mdoerr at openjdk.org  Mon Oct 13 13:30:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 13:30:38 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <PBTFe44R7V1fN0pxmrmIih7XtjV0JcJW32TI49QN-Eo=.08c35039-b293-4719-9606-331aefa8f939@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Thank you!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3331641868

From pchilanomate at openjdk.org  Mon Oct 13 13:50:01 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 13:50:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
 <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
 <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>
Message-ID: <Q8DVT07X855UWfbT3Rp8IcJknheT_vTMZdU-aLgkBM0=.9b28a26c-3644-4c13-a925-106961583146@github.com>

On Fri, 10 Oct 2025 22:29:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : )
> 
> I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well?
> 
> I've filed new JVMTI bug: [8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack
>
Yes, only `invalidate_jvmti_stack` is missing since `preempt_epilog` is only called in the virtual thread case.
Thanks for filing the bug Serguei!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3397611850

From pchilanomate at openjdk.org  Mon Oct 13 13:53:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 13:53:10 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <Q6PRyNqR8VkkgagomZdBcBmj-qAFmUjYkmj_Auo4cCw=.1b9ea230-0f8b-4531-9edb-f61c01c38d6f@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Looks good to me, thanks.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3331727767

From syan at openjdk.org  Mon Oct 13 14:07:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 13 Oct 2025 14:07:56 GMT
Subject: RFR: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <yX2LuOCWrBHmNJmSLRm8yJLW_03I3QS6aTbzTpWatQw=.5e2349a9-c189-4e26-8a8d-ed38bd4c2a05@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

I have run the tests with jtreg8.1, and there is no new failure.

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27719#pullrequestreview-3331786495

From duke at openjdk.org  Mon Oct 13 14:18:43 2025
From: duke at openjdk.org (jonghoonpark)
Date: Mon, 13 Oct 2025 14:18:43 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v5]
In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
Message-ID: <W5vyqV47498Jwpp9Au-b9-83haGln_fSRqAH_GjQO-I=.44c037c7-3367-4dcc-9ee2-0cdadab01b52@github.com>

> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
> 
> ---
> 
> Following the direction outlined in the issue description,
> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
> 
> I've confirmed that it works without issues in my local tests.
> 
> Reviews and feedback are welcome.

jonghoonpark has updated the pull request incrementally with two additional commits since the last revision:

 - remove whitespace
   
   Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
 - Apply suggestion from @kstefanj
   
   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27273/files
  - new: https://git.openjdk.org/jdk/pull/27273/files/57b1dcaf..e82154fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273

PR: https://git.openjdk.org/jdk/pull/27273

From roland at openjdk.org  Mon Oct 13 14:20:04 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 13 Oct 2025 14:20:04 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v3]
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <GVAYuMhn1W75P4FgkFW0eEkvIJGEtH2jZ3ePR6M2dNc=.9d7b9fc1-76d7-4b64-9700-b12ae7abde3d@github.com>

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27725/files
  - new: https://git.openjdk.org/jdk/pull/27725/files/05ff54dc..e521d918

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=01-02

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27725/head:pull/27725

PR: https://git.openjdk.org/jdk/pull/27725

From roland at openjdk.org  Mon Oct 13 14:38:50 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 13 Oct 2025 14:38:50 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v4]
In-Reply-To: <4AzzqZKwkzxGFxIszBSwfAdT6lyEEMdveyzYXhpfJLI=.224d078f-87e7-4b04-97ff-fe67ca4df4aa@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <4AzzqZKwkzxGFxIszBSwfAdT6lyEEMdveyzYXhpfJLI=.224d078f-87e7-4b04-97ff-fe67ca4df4aa@github.com>
Message-ID: <wm_Q1ulqSNdQgCK_e0nzGyoq0p0cqvOpJ8uK8xr4gM8=.0f1c5e87-47a7-4929-9926-2102ada15bbb@github.com>

On Fri, 10 Oct 2025 08:25:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> There are a lot of `SomeType *name` that we are slowly converting into `SomeType* name` when we have an occasion. As you wish.

I went over the change and fixed those that I spotted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3397782311

From roland at openjdk.org  Mon Oct 13 14:38:51 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 13 Oct 2025 14:38:51 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <QENriVylwLRHp05UlYy-YA2kyqrfVNJcGgOHAR6IyTA=.f26a6227-bb3c-4e62-9aac-6f170f0c4d05@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>
 <QENriVylwLRHp05UlYy-YA2kyqrfVNJcGgOHAR6IyTA=.f26a6227-bb3c-4e62-9aac-6f170f0c4d05@github.com>
Message-ID: <gW0LvUknSvsYrYfi6ARSEeT_vjKzgv0AOtP7ULNHKwM=.0f6a165e-0fc7-4d82-be90-0755f9608792@github.com>

On Fri, 10 Oct 2025 12:17:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> An idea (not a suggestion, just something that crossed my mind, take it more as a thought experiment): we could also parametrize everything not with a `BasicType` parameter but a template parameter (since `IdealIL` and co are invoked with literal values). It wouldn't change much, but for instance it would allow to replace the assert in `java_shift_left` and friends with static checks (I have a bias toward static checks).

I wondered about that too. There are many more methods that are parameterized by a `BasicType`. They would have to all go through that transition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3397792680

From roland at openjdk.org  Mon Oct 13 14:38:50 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 13 Oct 2025 14:38:50 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v4]
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <VpbUCxh6209-ARkz9a8Kch9_50FBuBRcu2thAxrJpdM=.3a700c3b-aef1-4052-8073-eb80a39eab68@github.com>

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - review
 - Merge branch 'master' into JDK-8369167
 - review
 - sort headers
 - more
 - more
 - more
 - more
 - more
 - fix

-------------

Changes: https://git.openjdk.org/jdk/pull/27725/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=03
  Stats: 617 lines in 6 files changed: 343 ins; 170 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/27725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27725/head:pull/27725

PR: https://git.openjdk.org/jdk/pull/27725

From fjiang at openjdk.org  Mon Oct 13 15:27:04 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 13 Oct 2025 15:27:04 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler [v2]
In-Reply-To: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
Message-ID: <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>

> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
> 
> Testing:
> - [x] tier1-3

Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:

  update comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27757/files
  - new: https://git.openjdk.org/jdk/pull/27757/files/004d2e04..2aba63c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27757&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27757&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27757/head:pull/27757

PR: https://git.openjdk.org/jdk/pull/27757

From fjiang at openjdk.org  Mon Oct 13 15:27:05 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 13 Oct 2025 15:27:05 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler [v2]
In-Reply-To: <DtjyL0yoSsOj6qVdRahT3eDVEsnXFe1AgNpUCF2uUno=.63804a88-c50e-4929-a166-e263120d16a0@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
 <DtjyL0yoSsOj6qVdRahT3eDVEsnXFe1AgNpUCF2uUno=.63804a88-c50e-4929-a166-e263120d16a0@github.com>
Message-ID: <XpumSkHXOq9i-tbzYVMLh_qfS6PD0ppj_bL5wUlw-aE=.0b8d7de0-f373-4753-a56f-0ddb1419e06e@github.com>

On Mon, 13 Oct 2025 07:48:48 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comments
>
> src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp line 43:
> 
>> 41:   void clear(void) {
>> 42:     // No hardware barriers are necessary. All members are volatile and the profiler
>> 43:     // is run from a signal handler and only observers the thread its running on.
> 
> Suggestion:
> 
>     // is run from a signal handler and the only observer is the thread its running on.

Fixed.

> src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp line 53:
> 
>> 51:   void copy(JavaFrameAnchor* src) {
>> 52:     // No hardware barriers are necessary. All members are volatile and the profiler
>> 53:     // is run from a signal handler and only observers the thread its running on.
> 
> Suggestion:
> 
>     // is run from a signal handler and the only observer is the thread its running on.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27757#discussion_r2426655800
PR Review Comment: https://git.openjdk.org/jdk/pull/27757#discussion_r2426656003

From matsaave at openjdk.org  Mon Oct 13 20:34:20 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 13 Oct 2025 20:34:20 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <o76Jq6gjc6QZxs7khd2hSNZr6l0IFrWCy_LnqMn5OBI=.3ef242b1-b377-4a9e-a96a-a4121ee44f55@github.com>

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused argument

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27735/files
  - new: https://git.openjdk.org/jdk/pull/27735/files/d9290dd8..da3fe2d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27735&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27735&range=00-01

  Stats: 12 lines in 4 files changed: 0 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27735/head:pull/27735

PR: https://git.openjdk.org/jdk/pull/27735

From vlivanov at openjdk.org  Mon Oct 13 21:39:15 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 13 Oct 2025 21:39:15 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
Message-ID: <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2272:

> 2270:   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
> 2271: 
> 2272:   Label Lclinit_barrier_slow, Ldone;

Minor comment: why don't you use `L_name` instead? `Lname` is a new idiom for naming labels on most of the platforms. (The convention is either `L_name` or simply `name` almost everywhere.)

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2289:

> 2287: 
> 2288:   // Class initialization barrier for static methods
> 2289:   if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {

FTR `VM_Version::supports_fast_class_init_checks()` is redundant in platform-specific code. 

The method is intended to be used in shared code to support dispatching between 2 execution modes, but for each platform is it known well ahead whether fast class init checks are supported or not.

(It does make sense to keep it as an assert through.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2427368272
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2427371470

From sspitsyn at openjdk.org  Mon Oct 13 22:04:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Oct 2025 22:04:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
 <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>
Message-ID: <dHrdYEpLqJpuLcAMIc1zupWflB9OdY6eu9fXRVWKfhk=.789360c6-cd98-4557-a0b9-27012dad5db7@github.com>

On Mon, 13 Oct 2025 08:31:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The intent of this bug fix was to solve the safepoint (check) issue.

Agreed. But thank you for fixing the additional issue pointed out by Patricio!

> Is there anything else we should fix as part of this bug fix?

The fix is good as is, thanks!

> Especially given that there is interest in back-porting JDK-8368159.

I'm curios who do you know is interested in back-porting JDK-8368159. I considered to back-port it but now it needs to be back-ported together with this one: JDK-8369482.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3399182611

From dholmes at openjdk.org  Tue Oct 14 02:21:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 02:21:03 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: <o76Jq6gjc6QZxs7khd2hSNZr6l0IFrWCy_LnqMn5OBI=.3ef242b1-b377-4a9e-a96a-a4121ee44f55@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <o76Jq6gjc6QZxs7khd2hSNZr6l0IFrWCy_LnqMn5OBI=.3ef242b1-b377-4a9e-a96a-a4121ee44f55@github.com>
Message-ID: <gcJ2ePBtj4OvvFl3lbUssysgfoXylP1PRlFKiHkzvZE=.b37d19c5-be46-4cac-ba67-fe360eda098a@github.com>

On Mon, 13 Oct 2025 20:34:20 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Trivial change to remove an unused line of code. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused argument

Renaming etc looks good - thanks. I had assumed this was one of a number of `FindClassXX` methods and so would disappear, but now see it is the primary method and it is just the name and arg that were no longer appropriate.

src/hotspot/share/prims/jvm.cpp line 802:

> 800: JVM_END
> 801: 
> 802: // Find a class with this name in this loader

Suggestion:

// Find a class with this name in this loader.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3333662017
PR Review Comment: https://git.openjdk.org/jdk/pull/27735#discussion_r2427736161

From dholmes at openjdk.org  Tue Oct 14 03:52:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 03:52:03 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v3]
In-Reply-To: <DJ8qlIfAFjeVVsUsnlHDGBuBeO4qklj8ruN1HS0CkWg=.f78f9bc8-befd-4522-b8a1-437428bf94cf@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <DJ8qlIfAFjeVVsUsnlHDGBuBeO4qklj8ruN1HS0CkWg=.f78f9bc8-befd-4522-b8a1-437428bf94cf@github.com>
Message-ID: <kg4fA3HPt7LLSpQB0aM-46EJqi6tEbz4JpdPP8afNOk=.f8fb1850-82af-4c55-87a3-16b0272ac3f7@github.com>

On Mon, 13 Oct 2025 12:43:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
>> 
>> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8369467
>  - Rdtsc: Remove experimental support for non invariant tsc
>  - 8369467: Rdtsc: Avoid initialize_elapsed_counter when UseFastUnorderedTimeStamps will be disabled
>  - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
>  - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27713#pullrequestreview-3333795496

From iklam at openjdk.org  Tue Oct 14 04:21:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Oct 2025 04:21:37 GMT
Subject: RFR: 8369742 link aot linked classes at vm bootstrap
Message-ID: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>

**PROBLEM**

If we have an AOT-initialized class like this in java.base


@AOTSafeClassInitializer
class Foo {
    static Bar b = new Bar(); // AOT-cached
    static void doit() {
        b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
    }
}


If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.

**FIX**

Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.

**NOTES**

- The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
- I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
- The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

-------------

Commit messages:
 - Added more comments
 - clean up
 - Fixed JVMTI
 - Import for linking all aot-linked classes at vm bootstrap

Changes: https://git.openjdk.org/jdk/pull/27783/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369742
  Stats: 183 lines in 12 files changed: 120 ins; 30 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/27783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27783/head:pull/27783

PR: https://git.openjdk.org/jdk/pull/27783

From aboldtch at openjdk.org  Tue Oct 14 05:41:17 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:41:17 GMT
Subject: RFR: 8369467: Rdtsc: Remove experimental support for non invariant
 tsc [v3]
In-Reply-To: <DJ8qlIfAFjeVVsUsnlHDGBuBeO4qklj8ruN1HS0CkWg=.f78f9bc8-befd-4522-b8a1-437428bf94cf@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
 <DJ8qlIfAFjeVVsUsnlHDGBuBeO4qklj8ruN1HS0CkWg=.f78f9bc8-befd-4522-b8a1-437428bf94cf@github.com>
Message-ID: <4AM7u4TbUALVyDcCZ8XKj2VGFk50Fo5au6BGG7gOMaM=.c715a10c-35b7-4d73-b678-0aeff3125f45@github.com>

On Mon, 13 Oct 2025 12:43:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
>> 
>> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8369467
>  - Rdtsc: Remove experimental support for non invariant tsc
>  - 8369467: Rdtsc: Avoid initialize_elapsed_counter when UseFastUnorderedTimeStamps will be disabled
>  - 8369469: Rdtsc: Remove potential races in Rdtsc::initialize
>  - 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27713#issuecomment-3400195790

From aboldtch at openjdk.org  Tue Oct 14 05:41:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:41:18 GMT
Subject: Integrated: 8369467: Rdtsc: Remove experimental support for non
 invariant tsc
In-Reply-To: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
References: <6Kc-IhW1qPJfpjUaGRqd8c6L9gDpEMwrH3b6vfzXlFI=.a1ab8338-93da-411a-934a-b09a1290dbf0@github.com>
Message-ID: <BbdtFO0ky9gSKXU7SqebqrJB4HkZ0eoSHpUpEfUAQQ0=.60248998-0bee-45dc-9da1-21c32e16b1be@github.com>

On Thu, 9 Oct 2025 06:31:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The feature to use rdtsc when it is not invariant requires us to set `UseFastUnorderedTimeStamps`. However, the current implementation always does `do_time_measurements` first, which adds an accumulative 3 ms of sleeps during bootstrapping. While most modern hardware supports invariant tsc, we have observed that many virtualized environments disable this even if it is running on supported hardware. Which means that doing this adds to our startup time even if the feature is never used on many common deployments.
> 
> I suggest we do some checking before deciding to call `initialize_elapsed_counter` and avoid it if we know we will not use rdtsc regardless of the outcome.

This pull request has now been integrated.

Changeset: be0e49b7
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be0e49b7e20103ed5c1f3729df1cddf3c9c7ae80
Stats:     102 lines in 2 files changed: 6 ins; 81 del; 15 mod

8369467: Rdtsc: Remove experimental support for non invariant tsc

Reviewed-by: dholmes, mgronlun

-------------

PR: https://git.openjdk.org/jdk/pull/27713

From aboldtch at openjdk.org  Tue Oct 14 05:43:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:43:16 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <1q85w7kQkDpro3hC5sLTIoKoiU2pMb-g8EJGTGyAnFQ=.971e83d7-7f59-42fe-be64-c9120f1ac530@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3400197550

From aboldtch at openjdk.org  Tue Oct 14 05:43:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:43:18 GMT
Subject: Integrated: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint
 poll in disallowed state
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <KmzOzd8Okim8eeewadNah18gqYjbQtPjXS_7k0C_hnk=.a4fb1e24-7340-49c0-a50b-1815a7b1939e@github.com>

On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

This pull request has now been integrated.

Changeset: 5bf1bab5
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Committer: Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Reviewed-by: sspitsyn, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/27716

From dzhang at openjdk.org  Tue Oct 14 05:55:02 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 14 Oct 2025 05:55:02 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <UHR_QMk3BOsqMglcPIm2ENYYhg7es7S6DWr54kQkqOs=.d5b69afe-ed04-4dbb-9943-f8c7863ff1d3@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
 <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
 <UHR_QMk3BOsqMglcPIm2ENYYhg7es7S6DWr54kQkqOs=.d5b69afe-ed04-4dbb-9943-f8c7863ff1d3@github.com>
Message-ID: <DoIicmWfNmLt0XbsbbQLKPqwOqyQBy-QTwgdeGWq2kE=.1fd42f87-49c7-4d17-a8d0-f811f402eb94@github.com>

On Fri, 10 Oct 2025 02:36:14 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> It seems my advice is the opposite of @iwanowww's, let's see what others think.
>
> Considering that the linux-riscv64 hwprobe syscall is not always usable for detecting support for misaligned vector access especially on old kernels, it makes sense to me that we should give the user a choice to decide.

Hi @iwanowww What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2427984813

From alanb at openjdk.org  Tue Oct 14 06:16:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 06:16:03 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v2]
In-Reply-To: <o76Jq6gjc6QZxs7khd2hSNZr6l0IFrWCy_LnqMn5OBI=.3ef242b1-b377-4a9e-a96a-a4121ee44f55@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <o76Jq6gjc6QZxs7khd2hSNZr6l0IFrWCy_LnqMn5OBI=.3ef242b1-b377-4a9e-a96a-a4121ee44f55@github.com>
Message-ID: <DFG-0wbL56b0St4QhN29QiNXhMk_Crnijg85WUhFQLA=.cbc58cf4-d7ba-4783-8400-8643dc566839@github.com>

On Mon, 13 Oct 2025 20:34:20 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Trivial change to remove an unused line of code. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused argument

Aside from the JVM_FindClassFromLoader comment, this looks okay to me.

src/hotspot/share/include/jvm.h line 440:

> 438:  */
> 439: JNIEXPORT jclass JNICALL
> 440: JVM_FindClassFromLoader(JNIEnv *env, const char *name, jboolean init,

The function description still lists the caller class, you can remove that.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3334042977
PR Review Comment: https://git.openjdk.org/jdk/pull/27735#discussion_r2428019210

From krk at openjdk.org  Tue Oct 14 08:12:46 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 14 Oct 2025 08:12:46 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>

On Mon, 13 Oct 2025 11:26:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

src/hotspot/share/prims/jvmtiAgentList.cpp line 201:

> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
> 200:     st->print_cr("Not in live phase");
> 201:     return;

Will the agent be loaded later?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2426112848

From fandreuzzi at openjdk.org  Tue Oct 14 08:12:45 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:12:45 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
Message-ID: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>

In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.

Passes tier1 and tier2 (fastdebug).

-------------

Commit messages:
 - mv
 - nn
 - mv
 - fix check
 - macro
 - cc
 - nl
 - fix and test

Changes: https://git.openjdk.org/jdk/pull/27766/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359472
  Stats: 184 lines in 4 files changed: 184 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Tue Oct 14 08:12:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:12:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>
Message-ID: <R27ha-r4Rl-nFUgCRpKUzH17Ev0Rl50GbnMUvs1KDG4=.a392c37e-1edd-46a4-9983-6bd19a4d39f2@github.com>

On Mon, 13 Oct 2025 11:52:06 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
> 
>> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
>> 200:     st->print_cr("Not in live phase");
>> 201:     return;
> 
> Will the agent be loaded later?

No, but the client can retry later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2426122346

From fandreuzzi at openjdk.org  Tue Oct 14 08:17:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:17:19 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/941f9a67..49722e1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From sjohanss at openjdk.org  Tue Oct 14 08:28:51 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 14 Oct 2025 08:28:51 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v5]
In-Reply-To: <W5vyqV47498Jwpp9Au-b9-83haGln_fSRqAH_GjQO-I=.44c037c7-3367-4dcc-9ee2-0cdadab01b52@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
 <W5vyqV47498Jwpp9Au-b9-83haGln_fSRqAH_GjQO-I=.44c037c7-3367-4dcc-9ee2-0cdadab01b52@github.com>
Message-ID: <KhKmsZNfqPXArikHWe59YqxEZrMoqIPNd7aKv8BIvRE=.f3c6d7dd-249a-4758-a7cf-de45ded667f6@github.com>

On Mon, 13 Oct 2025 14:18:43 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
>> 
>> ---
>> 
>> Following the direction outlined in the issue description,
>> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
>> 
>> I've confirmed that it works without issues in my local tests.
>> 
>> Reviews and feedback are welcome.
>
> jonghoonpark has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove whitespace
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
>  - Apply suggestion from @kstefanj
>    
>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Marked as reviewed by sjohanss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27273#pullrequestreview-3334471081

From schernyshev at openjdk.org  Tue Oct 14 08:30:05 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 14 Oct 2025 08:30:05 GMT
Subject: RFR: 8349988: Change cgroup version detection logic to not depend
 on /proc/cgroups [v4]
In-Reply-To: <W66WwlqNJVlFGpBteLBkd7dD1U_wJhBLL3jmWluMzCk=.d1526d58-250d-4797-97fb-51d5c90d9197@github.com>
References: <BBLqBQtdYk7p51YvIOxll3Z4wLBFNENdMBpjzNB7w_c=.f853b012-994e-4292-b59d-0ea1b04ff7b6@github.com>
 <K7Q2MufSUokbS-cE9d6ByBUAg7MsM8UkHQ4qMzAOKAA=.90d30d0b-1d0d-4d9d-a5d7-5a929f7ba3d8@github.com>
 <WhKzdkTVXjZMdJeRzwIsWgkec2eO6N9UYsh0hmikxEI=.91d34204-b495-4c4d-b807-9197edef4720@github.com>
 <jRmq3zvJlWDVD4EybKhLt_tU0AJLkC24-FqwAEJgLdY=.2dbdee77-0137-453e-b180-60a0084eca7d@github.com>
 <W66WwlqNJVlFGpBteLBkd7dD1U_wJhBLL3jmWluMzCk=.d1526d58-250d-4797-97fb-51d5c90d9197@github.com>
Message-ID: <R1l20mIzyP0pVeE7OdIMQzEegqve5Dx82MoSKDdwekk=.4a3e485b-3183-4ab9-b881-799749b2756f@github.com>

On Thu, 8 May 2025 08:32:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> @jerboaa @fitzsim Does the current mainline code handles mixed configuration where in some controllers are v1 and others v2? For example cpu controller is mounted as v1 while memory controller as v2. If yes, does this patch continue to support such configuration?
>> 
>> The current code does not allow mixed configuration for "relevant" controllers (essentially cpu and memory). That is, they ought to be v1 or v2. In the hybrid case (systemd running on unified), it's considered v1. I don't think this patch changes any of it.
>
>> @jerboaa @fitzsim, is there any plan to backport this fix (to 21)?
> 
> Eventually yes. But this change hasn't seen a lot of real-world exposure yet. It would be good to have that before attempting a backport.

Hi @jerboaa,
We are recieving multiple customer reports on the issue with 6.14 HWE kernels.
I would like to backport this to 21.0.10 & 17.0.18. Do you think it could be safe for the upcoming January update release?

@fitzsim Please let me know if you plan to work on the backports.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23811#issuecomment-3400690893

From luhenry at openjdk.org  Tue Oct 14 08:37:24 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 14 Oct 2025 08:37:24 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler [v2]
In-Reply-To: <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
 <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>
Message-ID: <5W0cWsJKgzoxT9RfXRtHHkLh_LMobmI-0gx4rDRZzsw=.1766c429-91df-4d90-a36a-93486b181aed@github.com>

On Mon, 13 Oct 2025 15:27:04 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
>> 
>> Testing:
>> - [x] tier1-3
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27757#pullrequestreview-3334502958

From sgehwolf at openjdk.org  Tue Oct 14 08:51:37 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Oct 2025 08:51:37 GMT
Subject: RFR: 8349988: Change cgroup version detection logic to not depend
 on /proc/cgroups [v4]
In-Reply-To: <W66WwlqNJVlFGpBteLBkd7dD1U_wJhBLL3jmWluMzCk=.d1526d58-250d-4797-97fb-51d5c90d9197@github.com>
References: <BBLqBQtdYk7p51YvIOxll3Z4wLBFNENdMBpjzNB7w_c=.f853b012-994e-4292-b59d-0ea1b04ff7b6@github.com>
 <K7Q2MufSUokbS-cE9d6ByBUAg7MsM8UkHQ4qMzAOKAA=.90d30d0b-1d0d-4d9d-a5d7-5a929f7ba3d8@github.com>
 <WhKzdkTVXjZMdJeRzwIsWgkec2eO6N9UYsh0hmikxEI=.91d34204-b495-4c4d-b807-9197edef4720@github.com>
 <jRmq3zvJlWDVD4EybKhLt_tU0AJLkC24-FqwAEJgLdY=.2dbdee77-0137-453e-b180-60a0084eca7d@github.com>
 <W66WwlqNJVlFGpBteLBkd7dD1U_wJhBLL3jmWluMzCk=.d1526d58-250d-4797-97fb-51d5c90d9197@github.com>
Message-ID: <DP8SOCC2ZNI6jVQhM2iwNY1DdYQo-N4U8wW3s5wGsT4=.640b0d54-a7a7-4c72-829f-af30ec093e22@github.com>

On Thu, 8 May 2025 08:32:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> @jerboaa @fitzsim Does the current mainline code handles mixed configuration where in some controllers are v1 and others v2? For example cpu controller is mounted as v1 while memory controller as v2. If yes, does this patch continue to support such configuration?
>> 
>> The current code does not allow mixed configuration for "relevant" controllers (essentially cpu and memory). That is, they ought to be v1 or v2. In the hybrid case (systemd running on unified), it's considered v1. I don't think this patch changes any of it.
>
>> @jerboaa @fitzsim, is there any plan to backport this fix (to 21)?
> 
> Eventually yes. But this change hasn't seen a lot of real-world exposure yet. It would be good to have that before attempting a backport.

> Hi @jerboaa,
> We are recieving multiple customer reports on the issue with 6.14 HWE kernels.
> I would like to backport this to 21.0.10 & 17.0.18. Do you think it could be safe for the upcoming January update release?

I tend to agree. Note that it's an issue on *how* the actual kernel is configured. But Ubuntu 24.04 LTS is affected. Noted as such in the bug recently: https://bugs.openjdk.org/browse/JDK-8349988

First step would be JDK 21. JDK 17 I'm not sure. It'll depend how the patch will look like.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23811#issuecomment-3400771974

From cstein at openjdk.org  Tue Oct 14 08:57:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Oct 2025 08:57:51 GMT
Subject: Integrated: 8369488: Update to use jtreg 8.1
In-Reply-To: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
References: <sOPec8-bHYBEeO0B03RF4Y_DqaYopYk2KSuIK2vb4sk=.d0c3f336-fd1d-472d-9d9f-1a1b469a585b@github.com>
Message-ID: <byRybe7y0ps0If8AgyIT1AR0OspYl6T2dJrqtKvEjuI=.e2bdd8ac-d0fa-4faa-95a6-a9ce92de25e6@github.com>

On Thu, 9 Oct 2025 09:34:11 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `8.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 702179e7
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8369488: Update to use jtreg 8.1

Reviewed-by: iris, erikj, jpai, syan

-------------

PR: https://git.openjdk.org/jdk/pull/27719

From duke at openjdk.org  Tue Oct 14 09:04:52 2025
From: duke at openjdk.org (duke)
Date: Tue, 14 Oct 2025 09:04:52 GMT
Subject: RFR: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib [v5]
In-Reply-To: <W5vyqV47498Jwpp9Au-b9-83haGln_fSRqAH_GjQO-I=.44c037c7-3367-4dcc-9ee2-0cdadab01b52@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
 <W5vyqV47498Jwpp9Au-b9-83haGln_fSRqAH_GjQO-I=.44c037c7-3367-4dcc-9ee2-0cdadab01b52@github.com>
Message-ID: <wdj7vk9upQtSdLfSs2iL83qWbGPQaZQFYkVHSYFNYzQ=.905612fd-4068-4e37-8fb2-3b2158ad5856@github.com>

On Mon, 13 Oct 2025 14:18:43 GMT, jonghoonpark <duke at openjdk.org> wrote:

>> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
>> 
>> ---
>> 
>> Following the direction outlined in the issue description,
>> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
>> 
>> I've confirmed that it works without issues in my local tests.
>> 
>> Reviews and feedback are welcome.
>
> jonghoonpark has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove whitespace
>    
>    Signed-off-by: jonghoonpark <dev at jonghoonpark.com>
>  - Apply suggestion from @kstefanj
>    
>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

@dev-jonghoonpark 
Your change (at version e82154fd77a347dfbf076c097344d2a89308637c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3400811002

From duke at openjdk.org  Tue Oct 14 09:13:31 2025
From: duke at openjdk.org (jonghoonpark)
Date: Tue, 14 Oct 2025 09:13:31 GMT
Subject: Integrated: 8366716: Move SmapsParser from
 runtime/os/TestTracePageSizes.java into testlib
In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com>
Message-ID: <Uvn5R3zVUsufVy8-Z3augK4_8AQX0iXNfx9-Q4cXrio=.80468f0d-3712-4c8b-ad26-8e0d18661d31@github.com>

On Sun, 14 Sep 2025 08:35:53 GMT, jonghoonpark <duke at openjdk.org> wrote:

> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716
> 
> ---
> 
> Following the direction outlined in the issue description,
> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library.
> 
> I've confirmed that it works without issues in my local tests.
> 
> Reviews and feedback are welcome.

This pull request has now been integrated.

Changeset: 90cf3a20
Author:    jonghoonpark <dev at jonghoonpark.com>
Committer: Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90cf3a2086cb0705dd519ff327be350e24a83af5
Stats:     510 lines in 3 files changed: 255 ins; 243 del; 12 mod

8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: sjohanss, syan

-------------

PR: https://git.openjdk.org/jdk/pull/27273

From mdoerr at openjdk.org  Tue Oct 14 09:16:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Oct 2025 09:16:36 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
 <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>
Message-ID: <mU48NDUCGLq6A_5lNanvl3eNoMo_buLWIrFOlhtXSgI=.d10f9b4a-6894-44b7-ac15-b78a177e99d2@github.com>

On Mon, 13 Oct 2025 21:33:56 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove blank lines
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2272:
> 
>> 2270:   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>> 2271: 
>> 2272:   Label Lclinit_barrier_slow, Ldone;
> 
> Minor comment: why don't you use `L_name` instead? `Lname` is a new idiom for naming labels on most of the platforms. (The convention is either `L_name` or simply `name` almost everywhere.)

Sorry, I guess that was my mistake. Changing it would be fine with me. Not a big deal, though.

> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2289:
> 
>> 2287: 
>> 2288:   // Class initialization barrier for static methods
>> 2289:   if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {
> 
> FTR `VM_Version::supports_fast_class_init_checks()` is redundant in platform-specific code. 
> 
> The method is intended to be used in shared code to support dispatching between 2 execution modes, but for each platform is it known well ahead whether fast class init checks are supported or not.
> 
> (It does make sense to keep it as an assert through.)

True, but I also like the current implementation from a readability perspective.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2428462998
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2428468108

From mchevalier at openjdk.org  Tue Oct 14 09:22:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 14 Oct 2025 09:22:32 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <gW0LvUknSvsYrYfi6ARSEeT_vjKzgv0AOtP7ULNHKwM=.0f6a165e-0fc7-4d82-be90-0755f9608792@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>
 <QENriVylwLRHp05UlYy-YA2kyqrfVNJcGgOHAR6IyTA=.f26a6227-bb3c-4e62-9aac-6f170f0c4d05@github.com>
 <gW0LvUknSvsYrYfi6ARSEeT_vjKzgv0AOtP7ULNHKwM=.0f6a165e-0fc7-4d82-be90-0755f9608792@github.com>
Message-ID: <ZmIx7WhOfwoZDhVodTtWYz0vVExfDWLyid0kS7AASKU=.638fc1a9-9285-4877-a147-d6def1225273@github.com>

On Mon, 13 Oct 2025 14:35:30 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> They would have to all go through that transition.

For consistency yes. But yet, I think I recall some functions that are not called with a compile-time constant, so we can't do that everywhere. Technically, calling a function that takes it as parameter from the templated version, and just passing our template argument is fine. What is not (easily) possible is normal parameter -> template. But again, that was just "for fun".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3400894799

From fyang at openjdk.org  Tue Oct 14 09:30:30 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Oct 2025 09:30:30 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>

On Tue, 30 Sep 2025 11:25:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 73:

> 71:     // For non-ext flags, they don't have dependency relationship among each other,
> 72:     // in this situation, just return the default value -1.
> 73:     virtual int dependent_index() { return -1; }

I wonder if we can make this feature index a bit more general. Currently, we only have `_cpu_feature_index` for subclass RVExtFeatureValue. But I think extensions and non-extensions could both have their own feature index for their group respectively. So maybe we can add a `_feature_index` member here for this base class and a `feature_index()` method, which seems cleaner to me.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 106:

> 104:     }
> 105: 
> 106:     void verify_deps(RVFeatureValue* dep0, ...) {

Since this method is only for debug purposes, we should put it under `#ifndef PRODUCT`.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 143:

> 141:   void update_flag() {                                                                                      \
> 142:       assert(enabled(), "Must be.");                                                                        \
> 143:       verify_deps(dep0, ##__VA_ARGS__);                                                                     \

Suggestion: `DEBUG_ONLY(verify_deps(dep0, ##__VA_ARGS__));`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428412983
PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428417019
PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428443386

From fyang at openjdk.org  Tue Oct 14 09:31:45 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Oct 2025 09:31:45 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler [v2]
In-Reply-To: <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
 <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>
Message-ID: <NuJZFqg7REWAl3NnqWmtUIO0vRF8JO2act0XkUJWnDI=.824cf46c-e5bc-4cc3-b8e4-a3a7e6d54890@github.com>

On Mon, 13 Oct 2025 15:27:04 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
>> 
>> Testing:
>> - [x] tier1-3
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27757#pullrequestreview-3334702700

From jsikstro at openjdk.org  Tue Oct 14 09:38:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 14 Oct 2025 09:38:53 GMT
Subject: RFR: 8369811: ZGC: Robust NUMA configuration detection
Message-ID: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>

Hello,

When page allocation was overhauled in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), NUMA support in ZGC was also significantly overhauled. The concept of a partition was introduced as a one-to-one mapping between NUMA nodes and a subset of the Java heap. The number of partitions is ideally the same number of NUMA nodes the Java process is bound to use.

Using ZGC and binding the Java process to only use a subset of the available NUMA nodes on a system with more than 2 NUMA nodes, there will be a mismatch between the internal representation and the configured one. The internal representation ends up having as many partitions as there are NUMA nodes on the system, not how many NUMA nodes the Java process will actually use.

To solve this, we create a mapping between what we refer to as "NUMA id" and "NUMA node", where NUMA id is the internal representation, i.e., the id of a partition, and the NUMA node is the actual NUMA node memory is allocated on. The mapping is used to translate between the two when syscalls are made, so that the internal representation always works with NUMA ids and syscalls work with the actual, or desired, NUMA node.

Before:

$ numactl --cpunodebind=0,2 --membind=0,2 ./jdk-25/bin/java -Xms200M -Xmx200M -XX:+AlwaysPretouch -XX:+UseZGC -Xlog:gc+init Forever.java
[0.236s][info][gc,init] NUMA Support: Enabled
[0.237s][info][gc,init] NUMA Nodes: 4

$ cat /proc/$(pidof java)/numa_maps | grep java_heap
40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N0=12800 kernelpagesize_kB=4
401f1000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N1=12800 kernelpagesize_kB=4
403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N2=12800 kernelpagesize_kB=4
405d3000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N3=12800 kernelpagesize_kB=4


After:

$ numactl --cpunodebind=0,2 --membind=0,2 ./jdk/bin/java -Xms200M -Xmx200M -XX:+AlwaysPreTouch -XX:+UseZGC -Xlog:gc+init Forever.java
[0.236s][info][gc,init] NUMA Support: Enabled
[0.237s][info][gc,init] NUMA Nodes: 2

$ cat /proc/$(pidof java)/numa_maps | grep java_heap
40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N0=25600 kernelpagesize_kB=4
403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N2=25600 kernelpagesize_kB=4


Testing:
* Functional testing on a QEMU VM with 4 NUMA nodes
* Oracle's tier1-2 on a NUMA system with `-XX:+UseZGC`

-------------

Commit messages:
 - 8369811: ZGC: Robust NUMA configuration detection

Changes: https://git.openjdk.org/jdk/pull/27792/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369811
  Stats: 49 lines in 6 files changed: 40 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27792/head:pull/27792

PR: https://git.openjdk.org/jdk/pull/27792

From epeter at openjdk.org  Tue Oct 14 09:43:41 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Oct 2025 09:43:41 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v4]
In-Reply-To: <VpbUCxh6209-ARkz9a8Kch9_50FBuBRcu2thAxrJpdM=.3a700c3b-aef1-4052-8073-eb80a39eab68@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <VpbUCxh6209-ARkz9a8Kch9_50FBuBRcu2thAxrJpdM=.3a700c3b-aef1-4052-8073-eb80a39eab68@github.com>
Message-ID: <tbpTM77zvgntla5fKbKK3hgCXif7pGYrDean1AsVtFk=.9bfc66c8-a0ac-49f7-bbca-217158e340ec@github.com>

On Mon, 13 Oct 2025 14:38:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change refactor code that's similar for LShiftINode and
>> LShiftLNode into shared methods. I also added extra test cases to
>> cover all transformations.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - review
>  - Merge branch 'master' into JDK-8369167
>  - review
>  - sort headers
>  - more
>  - more
>  - more
>  - more
>  - more
>  - fix

Seems good to me, thanks for this cleanup @rwestrel ! I have only a few minor suggestions.

src/hotspot/share/opto/mulnode.cpp line 1082:

> 1080:       // Left input is an add of a constant?
> 1081:       const TypeInteger* t12 = phase->type(add1->in(2))->isa_integer(bt);
> 1082:       if (t12 && t12->is_con()) { // Left input is an add of a con?

Suggestion:

      if (t12 != nullptr && t12->is_con()) { // Left input is an add of a con?

Implicit null check not allowed by hotspot style guide, so we should fix it when we touch it ;)

src/hotspot/share/opto/mulnode.cpp line 1084:

> 1082:       if (t12 && t12->is_con()) { // Left input is an add of a con?
> 1083:         // Compute X << con0
> 1084:         Node *lsh = phase->transform(LShiftNode::make( add1->in(1), in(2), bt));

Suggestion:

        Node* lsh = phase->transform(LShiftNode::make(add1->in(1), in(2), bt));

src/hotspot/share/opto/mulnode.cpp line 1086:

> 1084:         Node *lsh = phase->transform(LShiftNode::make( add1->in(1), in(2), bt));
> 1085:         // Compute X<<con0 + (con1<<con0)
> 1086:         return AddNode::make( lsh, phase->integercon(java_shift_left(t12->get_con_as_long(bt), con, bt), bt), bt);

Suggestion:

        return AddNode::make(lsh, phase->integercon(java_shift_left(t12->get_con_as_long(bt), con, bt), bt), bt);

Fixing spaces

src/hotspot/share/opto/mulnode.cpp line 1189:

> 1187: Node* LShiftINode::Ideal(PhaseGVN *phase, bool can_reshape) {
> 1188:   return IdealIL(phase, can_reshape, T_INT);
> 1189: }

I fear that putting the comments here will make them go out of date quicker than putting them at `IdealIL`.

Seems the list here may not even be complete. What about this one? `((x >> C1) & Y) << C2` There could be more.

src/hotspot/share/opto/mulnode.cpp line 1225:

> 1223: 
> 1224:   uint shift = r2->get_con();
> 1225:   shift &= bits_per_java_integer(bt)-1;  // semantics of Java shifts

Suggestion:

  shift &= bits_per_java_integer(bt) - 1;  // semantics of Java shifts

src/hotspot/share/opto/mulnode.cpp line 1256:

> 1254: 
> 1255: //------------------------------Value------------------------------------------
> 1256: // A LShiftINode shifts its input2 left by input1 amount.

I would remove such a comment, it is rather useless here. If anything, such a comment belongs at the class definition.

src/hotspot/share/opto/mulnode.cpp line 1282:

> 1280: // Also collapse nested left-shifts with constant rhs:
> 1281: // (X << con1) << con2 ==> X << (con1 + con2)
> 1282: Node* LShiftLNode::Ideal(PhaseGVN* phase, bool can_reshape) {

Same here: comment will go out of sync because it is not close to the implementation. I would move it closer to the implementation.

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27725#pullrequestreview-3334118372
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428076140
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428076683
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428079381
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428512329
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428518490
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428527472
PR Review Comment: https://git.openjdk.org/jdk/pull/27725#discussion_r2428531179

From mli at openjdk.org  Tue Oct 14 09:45:38 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 09:45:38 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags
In-Reply-To: <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
Message-ID: <nGyVSMyjnsSkq0-noyxznZOmcSu-paLi5L-2WymiaNE=.09b77b6f-8521-410d-8617-d8f9899d730d@github.com>

On Tue, 14 Oct 2025 08:55:14 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 106:
> 
>> 104:     }
>> 105: 
>> 106:     void verify_deps(RVFeatureValue* dep0, ...) {
> 
> Since this method is only for debug purposes, we should put it under `#ifndef PRODUCT`.

make sense, will fix.

> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 143:
> 
>> 141:   void update_flag() {                                                                                      \
>> 142:       assert(enabled(), "Must be.");                                                                        \
>> 143:       verify_deps(dep0, ##__VA_ARGS__);                                                                     \
> 
> Suggestion: `DEBUG_ONLY(verify_deps(dep0, ##__VA_ARGS__));`

make sense, will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428546984
PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428547216

From mli at openjdk.org  Tue Oct 14 09:48:41 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 09:48:41 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags
In-Reply-To: <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
Message-ID: <ZI-JKIIT5Pd8yhtJHCeqLXm5LEOJaslgKZUEpeF1-bk=.9451df3f-59a6-4970-8991-df29bda9ec92@github.com>

On Tue, 14 Oct 2025 08:53:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 73:
> 
>> 71:     // For non-ext flags, they don't have dependency relationship among each other,
>> 72:     // in this situation, just return the default value -1.
>> 73:     virtual int dependent_index() { return -1; }
> 
> I wonder if we can make this feature index a bit more general. Currently, we only have `_cpu_feature_index` for subclass RVExtFeatureValue. But I think extensions and non-extensions could both have their own feature index for their group respectively. So maybe we can add a `_feature_index` member here for this base class and a `feature_index()` method, which seems cleaner to me.

I see what you mean.
I have a another idea. As these dependency checks are only used in extension related scenarios (ie. RVExtFeatureValue), how about we move all these things into RVExtFeatureValue, including `dependent_index`, `deps_all_enabled`, `deps_string` and `verify_deps`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428554904

From ayang at openjdk.org  Tue Oct 14 09:53:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 09:53:39 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering
Message-ID: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>

This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.

Test: tier1-5

-------------

Commit messages:
 - remove
 - g1-card-mark-follow

Changes: https://git.openjdk.org/jdk/pull/27794/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369814
  Stats: 20 lines in 3 files changed: 0 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27794/head:pull/27794

PR: https://git.openjdk.org/jdk/pull/27794

From mli at openjdk.org  Tue Oct 14 10:09:42 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 10:09:42 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:

 - move dependency checks into RVExtFeatureValue
 - only verify_deps when debug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27572/files
  - new: https://git.openjdk.org/jdk/pull/27572/files/3205c38c..8da2ee7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=00-01

  Stats: 105 lines in 1 file changed: 52 ins; 52 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572

PR: https://git.openjdk.org/jdk/pull/27572

From mli at openjdk.org  Tue Oct 14 10:09:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 10:09:44 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <ZI-JKIIT5Pd8yhtJHCeqLXm5LEOJaslgKZUEpeF1-bk=.9451df3f-59a6-4970-8991-df29bda9ec92@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
 <ZI-JKIIT5Pd8yhtJHCeqLXm5LEOJaslgKZUEpeF1-bk=.9451df3f-59a6-4970-8991-df29bda9ec92@github.com>
Message-ID: <5lGwuP7lIiMCQs_zfzIUPhpL5rfDLGb6PGGDSF8W0AU=.af17835f-cdea-4f81-8f84-a1f45f84d5d0@github.com>

On Tue, 14 Oct 2025 09:45:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 73:
>> 
>>> 71:     // For non-ext flags, they don't have dependency relationship among each other,
>>> 72:     // in this situation, just return the default value -1.
>>> 73:     virtual int dependent_index() { return -1; }
>> 
>> I wonder if we can make this feature index a bit more general. Currently, we only have `_cpu_feature_index` for subclass RVExtFeatureValue. But I think extensions and non-extensions could both have their own feature index for their group respectively. So maybe we can add a `_feature_index` member here for this base class and a `feature_index()` method, which seems cleaner to me.
>
> I see what you mean.
> I have a another idea. As these dependency checks are only used in extension related scenarios (ie. RVExtFeatureValue), how about we move all these things into RVExtFeatureValue, including `dependent_index`, `deps_all_enabled`, `deps_string` and `verify_deps`?

please have a look at the second commit, currently only RVExtFeatureValue needs a (cpu) feature index and depenecny checks, so seems it's better to keep it inside RVExtFeatureValue. let me know how you think about it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428610145

From adinn at openjdk.org  Tue Oct 14 10:34:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 14 Oct 2025 10:34:46 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions
In-Reply-To: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
Message-ID: <Oa6_2j1Tm2JYxrAPj8D4M08evpBIg-7d-pq6JnFPF7Q=.3ad303df-1af4-48fb-a993-84cffaf62a50@github.com>

On Mon, 6 Oct 2025 15:14:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
> 
> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.

I did not expect to be saying this but it looks much better with templates!

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27649#pullrequestreview-3334922589

From tschatzl at openjdk.org  Tue Oct 14 10:36:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 10:36:39 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <VkLENN70uwegelyOrE2wdSsQK_8FQ2RL4XyWfmXNjzo=.f0ff07e7-7638-4ad5-9533-f3807b901696@github.com>

On Tue, 14 Oct 2025 09:46:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

I think this PR should also clean up all the deferred card mark code, i.e. everything related to `DeferInitialCardMark` flag.
Since it is `false` by default, `CardTableBarrierSet::_defer_initial_card_mark` is also always `false` now.

There does not seem to be a reason to keep it and surrounding code just for the sake of the flag. This flag is also diagnostic, and can be removed too.

Great find btw!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3401156972
PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3401162268

From mgronlun at openjdk.org  Tue Oct 14 11:05:39 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Oct 2025 11:05:39 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <mG8MDF3qLQHiDX9vUniODhKdXFcajmCXI4fXvQBIudk=.c1aed4d9-e797-471b-86ee-54f12a62f92d@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <2EF1whYIVC4qpXKNQJIYsxK6eLqfI89YWn0HjCxNjH4=.053b510f-fbd0-4ccd-a835-c235a35716c9@github.com>
 <mG8MDF3qLQHiDX9vUniODhKdXFcajmCXI4fXvQBIudk=.c1aed4d9-e797-471b-86ee-54f12a62f92d@github.com>
Message-ID: <KxQIM5j2ZK9FE3AmZouXuf9T_r0paudgP0o2CeT1t4Y=.6cac4c98-2cba-41c3-bddc-76d42d87e705@github.com>

On Fri, 10 Oct 2025 15:13:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Can you please give an example URL for a class definition? I am concerned about whether this is high cardinality strings (for path/name.class) or a lot of reuse (for paths). We should only represent a URL once, which makes me think that the field type should be symbol instead of string.
> 
> Run with `-Xlog:class+load` to see examples of the code source. For classes loaded from modules in the run-time image then you'll see values of the form `jrt:/$MODULE`, e.g. `jrt:/java.base` or `jrt:/java.destop` (classes loaded from the AOT have something like "shared objects file"). The code source for classes loaded from JAR files is the path to the JAR file, e.g. `file:/lib/foo.jar`. When classes loaded from the file system then it will be the directory specified to the class path, e.g. `file:/d/classes/`.

Thanks.

Looks like the source is a low cardinality property.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3401254061

From wenanjian at openjdk.org  Tue Oct 14 11:07:43 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Tue, 14 Oct 2025 11:07:43 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <awsyLcrSdQHwSbPZC1mtAuIEsck_2Ng_2UNCySDylAU=.bcc75894-3826-4fd6-9849-2db9fa9d856b@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
 <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
 <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>
 <awsyLcrSdQHwSbPZC1mtAuIEsck_2Ng_2UNCySDylAU=.bcc75894-3826-4fd6-9849-2db9fa9d856b@github.com>
Message-ID: <h8TmlmXesAwID7Mnl8qFcWg2ZaYlFfcr72XByVvtrxo=.15f70e6f-9f13-4a1f-a4da-ae26b2d27f87@github.com>

On Fri, 10 Oct 2025 10:48:34 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> Sorry, I did not mean you should delete the `AvoidUnalignedAccesses`. I just don't know the exact rule about how to delete it.
>> Please hold on for a while to get a comment on this part of change from others.
>
> Oh, I misunderstood, I will try to check the rule and test tier1

This AvoidUnalignedAccesses Flag is defined in ARCH_FLAGS, I think it will only affect riscv arch. and after using the alternative flag !UseUnalignedAccesses, it seems there is no need for it in the hotspot/cpu/riscv, we can hold on for a while to wait for others comments.

besides, I have  test-tier1 tests passed with or without deleting this  : )

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2428753821

From dholmes at openjdk.org  Tue Oct 14 11:07:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 11:07:47 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <XSak1YrP_B846xlT_rbM8gF8ssAbl9CypoqqCSWozBY=.dc8c9638-85cf-4510-8114-d02075f597d1@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

Hotspot changes look fine. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335034246

From ayang at openjdk.org  Tue Oct 14 11:27:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 11:27:20 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/e424e898..1eed131b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=00-01

  Stats: 89 lines in 7 files changed: 0 ins; 85 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27794/head:pull/27794

PR: https://git.openjdk.org/jdk/pull/27794

From vyazici at openjdk.org  Tue Oct 14 11:33:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:33:20 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <2Ij8EYFqIDDqSIA7QCNejs8yMSVeKeLywF82ayw8DzQ=.7fa24297-a8f0-414c-8253-1e2ffd81b60b@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 80:

> 78: 
> 79:     /**
> 80:      * Test executable JAR with code thatyses  Lookup.unreflectSetter to get MH to a

Suggestion:

     * Test executable JAR with code that uses Lookup.unreflectSetter to get MH to a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2428816748

From vyazici at openjdk.org  Tue Oct 14 11:38:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:38:11 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <A6-9e6Q2pHdZNJSkxX7iMj_jetrLXfMAIc_bdx8jAGA=.87d14a7a-58e0-419d-bac9-27a056e1218e@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

I've reviewed the `test/` changes, and they LGTM.

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335136796

From roland at openjdk.org  Tue Oct 14 11:42:53 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 14 Oct 2025 11:42:53 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v5]
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <MpWykGcYpjtWXrXpLWJerOyZ2E3zZcdz1DbvQNy4Qwk=.74c277e6-b8f8-4e6e-855a-93bb318d7d78@github.com>

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/hotspot/share/opto/mulnode.cpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - Update src/hotspot/share/opto/mulnode.cpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - Update src/hotspot/share/opto/mulnode.cpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - Update src/hotspot/share/opto/mulnode.cpp
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27725/files
  - new: https://git.openjdk.org/jdk/pull/27725/files/040d8541..6865e1c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27725/head:pull/27725

PR: https://git.openjdk.org/jdk/pull/27725

From tschatzl at openjdk.org  Tue Oct 14 11:48:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 11:48:05 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
Message-ID: <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>

On Tue, 14 Oct 2025 11:27:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 116:

> 114:   }
> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
> 116:     // Arrays of non-references don't need a post-barrier.

Pre-existing: Maybe `CardTable::is_in_young()` can be made `protected` instead of `public`.

src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 117:

> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
> 116:     // Arrays of non-references don't need a post-barrier.
> 117:     // The deferred_card_mark region should be empty

The `Thread::_deferred_card_mark` member and related can also be removed, because nobody writes to it afaict.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335148410
PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428845167
PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428847124

From roland at openjdk.org  Tue Oct 14 11:59:27 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 14 Oct 2025 11:59:27 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v6]
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <jqyEnHmReYSIkeKgzS-0AoKLeoWKoHJvA1qiOnlAsqA=.a77a5e99-202d-4994-b06d-dde2934845f8@github.com>

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27725/files
  - new: https://git.openjdk.org/jdk/pull/27725/files/6865e1c4..29edbe64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27725&range=04-05

  Stats: 15 lines in 1 file changed: 1 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27725/head:pull/27725

PR: https://git.openjdk.org/jdk/pull/27725

From roland at openjdk.org  Tue Oct 14 11:59:30 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 14 Oct 2025 11:59:30 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v4]
In-Reply-To: <tbpTM77zvgntla5fKbKK3hgCXif7pGYrDean1AsVtFk=.9bfc66c8-a0ac-49f7-bbca-217158e340ec@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <VpbUCxh6209-ARkz9a8Kch9_50FBuBRcu2thAxrJpdM=.3a700c3b-aef1-4052-8073-eb80a39eab68@github.com>
 <tbpTM77zvgntla5fKbKK3hgCXif7pGYrDean1AsVtFk=.9bfc66c8-a0ac-49f7-bbca-217158e340ec@github.com>
Message-ID: <QWmqzjYdZ65c_5asI2RU0p7lJTgY1wARNec5M31x_48=.51150059-12a5-41ad-942b-91de99618482@github.com>

On Tue, 14 Oct 2025 09:40:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8369167
>>  - review
>>  - sort headers
>>  - more
>>  - more
>>  - more
>>  - more
>>  - more
>>  - fix
>
> Seems good to me, thanks for this cleanup @rwestrel ! I have only a few minor suggestions.

@eme64 new commit should address you comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3401421638

From ayang at openjdk.org  Tue Oct 14 12:01:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:01:28 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v3]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <Tnop7AqNmjBkOXYL0G0xqL9BQd0P9T4-P1z0n0zxyf0=.35d2834d-87dc-467d-ba86-15d2350d1255@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/1eed131b..a54bc3b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=01-02

  Stats: 12 lines in 2 files changed: 0 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27794/head:pull/27794

PR: https://git.openjdk.org/jdk/pull/27794

From ayang at openjdk.org  Tue Oct 14 12:01:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:01:30 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
 <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>
Message-ID: <6-qg1bpwB642J9vT37Hbp5joiCrkOMlEMXREhzeKwJw=.36e10b36-be06-4433-91fe-fef1c77336f7@github.com>

On Tue, 14 Oct 2025 11:43:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 116:
> 
>> 114:   }
>> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
>> 116:     // Arrays of non-references don't need a post-barrier.
> 
> Pre-existing: Maybe `CardTable::is_in_young()` can be made `protected` instead of `public`.

Need to be public; otherwise, build error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428885012

From ayang at openjdk.org  Tue Oct 14 12:09:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:09:41 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v4]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/a54bc3b6..d79b1577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27794/head:pull/27794

PR: https://git.openjdk.org/jdk/pull/27794

From fyang at openjdk.org  Tue Oct 14 12:13:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Oct 2025 12:13:05 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
Message-ID: <pkT8_XngbeMcqaoZv_uiYc4RKPciX5QsQ_3V5x8-jUY=.ab3df583-d7d2-409b-8a82-91380d78ad26@github.com>

On Tue, 14 Oct 2025 10:09:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move dependency checks into RVExtFeatureValue
>  - only verify_deps when debug

Thanks for the quick update. This reminds me of the order in which we enable these ISA features in `RiscvHwprobe::add_features_from_query_result`. In your previous PR https://github.com/openjdk/jdk/pull/27562, we reorder the declarations. But we should sync `RiscvHwprobe::add_features_from_query_result` with that new order at the same time, right?

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 130:

> 128:       _cpu_feature_index(cpu_feature_index) {
> 129:     }
> 130:     int dependent_index() {

Or simply `feature_index`? Or `cpu_feature_index`? This is also used for other purpose like in AOT support.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27572#pullrequestreview-3335209196
PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428881985

From fyang at openjdk.org  Tue Oct 14 12:13:06 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Oct 2025 12:13:06 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <5lGwuP7lIiMCQs_zfzIUPhpL5rfDLGb6PGGDSF8W0AU=.af17835f-cdea-4f81-8f84-a1f45f84d5d0@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <cCuLBghtBC43Bse3ImSBD1fvU1tKPhGDc-mUcorTjbE=.8e1281a5-7f18-458d-8aa5-2616fe0b7613@github.com>
 <ZI-JKIIT5Pd8yhtJHCeqLXm5LEOJaslgKZUEpeF1-bk=.9451df3f-59a6-4970-8991-df29bda9ec92@github.com>
 <5lGwuP7lIiMCQs_zfzIUPhpL5rfDLGb6PGGDSF8W0AU=.af17835f-cdea-4f81-8f84-a1f45f84d5d0@github.com>
Message-ID: <WMKZxtvsENbR63OMT5qEXOLIlKaP4xteeBXOoIuRRtI=.a6dc5853-22f8-4b21-9425-55cc7193aacb@github.com>

On Tue, 14 Oct 2025 10:06:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> I see what you mean.
>> I have a another idea. As these dependency checks are only used in extension related scenarios (ie. RVExtFeatureValue), how about we move all these things into RVExtFeatureValue, including `dependent_index`, `deps_all_enabled`, `deps_string` and `verify_deps`?
>
> please have a look at the second commit, currently only RVExtFeatureValue needs a (cpu) feature index and depenecny checks, so seems it's better to keep it inside RVExtFeatureValue. let me know how you think about it.

That make sense to me. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2428925110

From mli at openjdk.org  Tue Oct 14 12:41:55 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 12:41:55 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <pkT8_XngbeMcqaoZv_uiYc4RKPciX5QsQ_3V5x8-jUY=.ab3df583-d7d2-409b-8a82-91380d78ad26@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
 <pkT8_XngbeMcqaoZv_uiYc4RKPciX5QsQ_3V5x8-jUY=.ab3df583-d7d2-409b-8a82-91380d78ad26@github.com>
Message-ID: <p70hG1OPx4a_cYw5w7Kx45fnW6qpX-mwShP_RZh3jQo=.809e59ad-9b74-4b03-b12b-8d4ff372856e@github.com>

On Tue, 14 Oct 2025 11:56:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move dependency checks into RVExtFeatureValue
>>  - only verify_deps when debug
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 130:
> 
>> 128:       _cpu_feature_index(cpu_feature_index) {
>> 129:     }
>> 130:     int dependent_index() {
> 
> Or simply `feature_index`? Or `cpu_feature_index`? This is also used for other purpose like in AOT support.

make sense, will modify it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2429014158

From tschatzl at openjdk.org  Tue Oct 14 12:43:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 12:43:03 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v4]
In-Reply-To: <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>
Message-ID: <P0SezRifAElovW5Mdi40eSdUbRqNps7eIUY7bGrLHLc=.da68fe8e-af49-49d1-8671-333293104736@github.com>

On Tue, 14 Oct 2025 12:09:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I think there is an assert using the deferred card mark stuff in Shenandoah too (ShenandoahBarrierSet::on_slowpath_allocation_exit())

That will make the gha build fail.

Otherwise lgtm - thanks for cleaning this up!

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335404193

From ayang at openjdk.org  Tue Oct 14 12:49:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:49:22 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/d79b1577..cf3ea34b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27794&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27794/head:pull/27794

PR: https://git.openjdk.org/jdk/pull/27794

From tschatzl at openjdk.org  Tue Oct 14 12:49:23 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 12:49:23 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <fqdCJ-AuRkn8rQ3wrD9msnrnGLOPYfNAKwOpBmkmvb8=.0187139e-36a0-4277-acd3-36fbd234615a@github.com>

On Tue, 14 Oct 2025 12:46:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

lgtm!

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335427722

From mli at openjdk.org  Tue Oct 14 12:55:24 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 12:55:24 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v3]
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <hr8n1eg5Syx_rwdPG5vUfibg-jdK4RzDoNMPYH4x_6A=.f4065a06-1751-4cf3-8500-a412252d2865@github.com>

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  rename

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27572/files
  - new: https://git.openjdk.org/jdk/pull/27572/files/8da2ee7d..58627d3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572

PR: https://git.openjdk.org/jdk/pull/27572

From mli at openjdk.org  Tue Oct 14 12:55:25 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 12:55:25 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
Message-ID: <3owdP0eYorHp7kuf6j7gMJqQiK_rQAndrc6sHdtkahI=.e6f2e1fc-37d8-481c-ba7a-665fe767099b@github.com>

On Tue, 14 Oct 2025 10:09:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move dependency checks into RVExtFeatureValue
>  - only verify_deps when debug

> Thanks for the quick update. This reminds me of the order in which we enable these ISA features in `RiscvHwprobe::add_features_from_query_result`. In your previous PR #27562, we reorder the declarations. But we should sync `RiscvHwprobe::add_features_from_query_result` with that new order at the same time, right?

Not sure if I understand you correctly.

I think it's not necessary to do so, take `v` and `zvfh` as example, if in `RiscvHwprobe::add_features_from_query_result`, `zvfh` is enabled detected and enabled before `v`, and `v` is disabled by hw probe, then in the while loop of `VM_Version::setup_cpu_available_features`, `zvfh` will still be diabled because of `v` disabling. So the order in the`RiscvHwprobe::add_features_from_query_result` will not affect the correctness of dependency check.

Or  do you mean we should keep the same order of extensions and non-extensions in `RiscvHwprobe::add_features_from_query_result` as in `RV_EXT_FEATURE_FLAGS` and `RV_NON_EXT_FEATURE_FLAGS` for readability or some other reasons? I can also do it in this pr, just note it's not necessary to do so. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27572#issuecomment-3401650455

From asmehra at openjdk.org  Tue Oct 14 13:16:20 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 13:16:20 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <mU48NDUCGLq6A_5lNanvl3eNoMo_buLWIrFOlhtXSgI=.d10f9b4a-6894-44b7-ac15-b78a177e99d2@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
 <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>
 <mU48NDUCGLq6A_5lNanvl3eNoMo_buLWIrFOlhtXSgI=.d10f9b4a-6894-44b7-ac15-b78a177e99d2@github.com>
Message-ID: <onvpkmhYsXrL2Ym5n-evHpiOqqCxbQZKeNgf3MMvX88=.2c0146a5-b67c-4d12-90b1-31a03814b6fd@github.com>

On Tue, 14 Oct 2025 09:12:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2272:
>> 
>>> 2270:   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
>>> 2271: 
>>> 2272:   Label Lclinit_barrier_slow, Ldone;
>> 
>> Minor comment: why don't you use `L_name` instead? `Lname` is a new idiom for naming labels on most of the platforms. (The convention is either `L_name` or simply `name` almost everywhere.)
>
> Sorry, I guess that was my mistake. Changing it would be fine with me. Not a big deal, though.

I will update the label names to use the convention `L_name`.

>> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2289:
>> 
>>> 2287: 
>>> 2288:   // Class initialization barrier for static methods
>>> 2289:   if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {
>> 
>> FTR `VM_Version::supports_fast_class_init_checks()` is redundant in platform-specific code. 
>> 
>> The method is intended to be used in shared code to support dispatching between 2 execution modes, but for each platform is it known well ahead whether fast class init checks are supported or not.
>> 
>> (It does make sense to keep it as an assert through.)
>
> True, but I also like the current implementation from a readability perspective.

Let's keep it for now. I will remove `VM_Version::supports_fast_class_init_checks()` from platform-specific code in a follow-up PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429118079
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429123973

From ayang at openjdk.org  Tue Oct 14 13:35:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 13:35:12 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - ... and 7 more: https://git.openjdk.org/jdk/compare/40320d03...273c2003

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/a6bafe71..273c2003

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=11-12

  Stats: 10072 lines in 144 files changed: 6226 ins; 3462 del; 384 mod
  Patch: https://git.openjdk.org/jdk/pull/26700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700

PR: https://git.openjdk.org/jdk/pull/26700

From jcking at openjdk.org  Tue Oct 14 13:35:20 2025
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Oct 2025 13:35:20 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp
Message-ID: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>

Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.

-------------

Commit messages:
 - Generalize bytes.hpp

Changes: https://git.openjdk.org/jdk/pull/27801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369828
  Stats: 1204 lines in 9 files changed: 229 ins; 973 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27801/head:pull/27801

PR: https://git.openjdk.org/jdk/pull/27801

From alanb at openjdk.org  Tue Oct 14 13:47:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 13:47:55 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v9]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <3JlQE_SY_oPghJ13xGjdALIADPSp4dajFsMfrw3vCA0=.434d3878-0d61-4518-af3c-636817cbf3dc@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - Add testUnreflectExpectingWarning
 - ... and 34 more: https://git.openjdk.org/jdk/compare/90cf3a20...1d0cb6c9

-------------

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=08
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

PR: https://git.openjdk.org/jdk/pull/25115

From fjiang at openjdk.org  Tue Oct 14 13:53:06 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 14 Oct 2025 13:53:06 GMT
Subject: Integrated: 8369616: JavaFrameAnchor on RISC-V has unnecessary
 barriers and wrong store order in MacroAssembler
In-Reply-To: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
Message-ID: <be982unIbw5nD-jc5ZW14n21lcltyUdbSWcTwIN4_0Y=.72cfb722-11c3-4629-86e8-a60254ebc37e@github.com>

On Sat, 11 Oct 2025 12:48:46 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> Same as [JDK-8369190](https://bugs.openjdk.org/browse/JDK-8369190), but for the RISC-V port.
> 
> Testing:
> - [x] tier1-3

This pull request has now been integrated.

Changeset: 72663695
Author:    Feilong Jiang <fjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72663695da9a51c8eefbd496f14a6d1625ad7b42
Stats:     19 lines in 2 files changed: 9 ins; 9 del; 1 mod

8369616: JavaFrameAnchor on RISC-V has unnecessary barriers and wrong store order in MacroAssembler

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/27757

From fjiang at openjdk.org  Tue Oct 14 13:53:03 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 14 Oct 2025 13:53:03 GMT
Subject: RFR: 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers
 and wrong store order in MacroAssembler [v2]
In-Reply-To: <5W0cWsJKgzoxT9RfXRtHHkLh_LMobmI-0gx4rDRZzsw=.1766c429-91df-4d90-a36a-93486b181aed@github.com>
References: <tjQkhlDuUAAQl8wDeKvGzAfsggWFhIka3tfoNQvUhR8=.5b6a189c-141c-4e74-95cd-777423d1c0fa@github.com>
 <157BJaL8xVZD0E6egVi2JQAnuOvMdg7xm1fjpOKZRmI=.a2692324-ea79-47ae-8aa1-d8b1776e0e53@github.com>
 <5W0cWsJKgzoxT9RfXRtHHkLh_LMobmI-0gx4rDRZzsw=.1766c429-91df-4d90-a36a-93486b181aed@github.com>
Message-ID: <OSEh-eIsHgjF0B-nhIZiV2umhduazTzD0pX3uOEjyeM=.d3c9fa53-e486-4609-b717-59bd8084e24e@github.com>

On Tue, 14 Oct 2025 08:34:47 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comments
>
> Marked as reviewed by luhenry (Committer).

@luhenry @RealFYang Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27757#issuecomment-3401987826

From asmehra at openjdk.org  Tue Oct 14 14:09:30 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 14:09:30 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v11]
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Rename labels
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27676/files
  - new: https://git.openjdk.org/jdk/pull/27676/files/5ddd660d..ef89c4d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27676&range=09-10

  Stats: 60 lines in 5 files changed: 0 ins; 0 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/27676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27676/head:pull/27676

PR: https://git.openjdk.org/jdk/pull/27676

From fyang at openjdk.org  Tue Oct 14 14:12:10 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Oct 2025 14:12:10 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <3owdP0eYorHp7kuf6j7gMJqQiK_rQAndrc6sHdtkahI=.e6f2e1fc-37d8-481c-ba7a-665fe767099b@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
 <3owdP0eYorHp7kuf6j7gMJqQiK_rQAndrc6sHdtkahI=.e6f2e1fc-37d8-481c-ba7a-665fe767099b@github.com>
Message-ID: <pNEyN-oSMfPDSFrDGwG7O1Qx4VusYVquMMNVssycKsE=.a2cf396a-b025-4f4c-a98d-ec33f22c87ce@github.com>

On Tue, 14 Oct 2025 12:50:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Thanks for the quick update. This reminds me of the order in which we enable these ISA features in `RiscvHwprobe::add_features_from_query_result`. In your previous PR #27562, we reorder the declarations. But we should sync `RiscvHwprobe::add_features_from_query_result` with that new order at the same time, right?
> 
> Not sure if I understand you correctly.
> 
> I think it's not necessary to do so, take `v` and `zvfh` as example, if in `RiscvHwprobe::add_features_from_query_result`, `zvfh` is enabled detected and enabled before `v`, and `v` is disabled by hw probe, then in the while loop of `VM_Version::setup_cpu_available_features`, `zvfh` will still be diabled because of `v` disabling. So the order in the`RiscvHwprobe::add_features_from_query_result` will not affect the correctness of dependency check.
> 
> Or do you mean we should keep the same order of extensions and non-extensions in `RiscvHwprobe::add_features_from_query_result` as in `RV_EXT_FEATURE_FLAGS` and `RV_NON_EXT_FEATURE_FLAGS` for readability or some other reasons? I can also do it in this pr, just note it's not necessary to do so. :)

Here is what I am thinking: Your `verify_deps` only ensures that the declarations of the extensions are in the correct order (as indicated by the `_cpu_feature_index`). And that is the order in which we should follow when enabling these extensions. So for this to work, the order should be refected by `RiscvHwprobe::add_features_from_query_result` which does the work. For safety, I think we should always sync them. Make sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27572#issuecomment-3402077819

From asmehra at openjdk.org  Tue Oct 14 14:20:39 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 14:20:39 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v4]
In-Reply-To: <sqDmiXFnu8xAe864MVJthP10edSqDiYBnp1joTJ7kRY=.8c27e8bf-6ed4-4aca-9d10-4c54be0d5bef@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <12KKmOjGgmL0zq4dOBdN70mCfPWZ-Q8TQgreXwtE7sM=.6cc424d2-5db6-4739-9ead-00b933762025@github.com>
 <21EpYq87F2K7cADKmXUa5QyUju64TwlITkTeVbuZgJ4=.9ee6c5df-9458-483a-b43c-1f0da00a254f@github.com>
 <a70cfi4qdXz2ageu56LR-Yucx2xhlZCQLFOgGTuCQw8=.d6afcb25-0d9e-4c3f-a433-009a80fe72c8@github.com>
 <sqDmiXFnu8xAe864MVJthP10edSqDiYBnp1joTJ7kRY=.8c27e8bf-6ed4-4aca-9d10-4c54be0d5bef@github.com>
Message-ID: <zNVnxGjsFZ7X8NcHVo5OsPbFgSsdWdvaiAqWXVxnwYo=.64c5b84c-1d9d-498b-a397-d30247b80a66@github.com>

On Wed, 8 Oct 2025 19:43:10 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> My proposal avoids it by jumping over it. Is that better or at least less confusing? 
>> 
>> I think it makes sense. On returning from `resolve_from_cache` the class must have been initialized. So the fast path check can be skipped. Do you agree with this change? @iwanowww
>
>> My proposal avoids it by jumping over it. Is that better or at least less confusing?
> 
> @TheRealMDoerr it looks fine to me.

@iwanowww I addressed your suggestion to rename the labels.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3402119589

From asmehra at openjdk.org  Tue Oct 14 14:20:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 14:20:41 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <onvpkmhYsXrL2Ym5n-evHpiOqqCxbQZKeNgf3MMvX88=.2c0146a5-b67c-4d12-90b1-31a03814b6fd@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
 <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>
 <mU48NDUCGLq6A_5lNanvl3eNoMo_buLWIrFOlhtXSgI=.d10f9b4a-6894-44b7-ac15-b78a177e99d2@github.com>
 <onvpkmhYsXrL2Ym5n-evHpiOqqCxbQZKeNgf3MMvX88=.2c0146a5-b67c-4d12-90b1-31a03814b6fd@github.com>
Message-ID: <kF9y4WWpt3p6mla6J4eFJ7HYpEIdGvLREUJg82FDbZc=.b7af031b-5be0-4f50-a9d7-811531aa1916@github.com>

On Tue, 14 Oct 2025 13:12:10 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Sorry, I guess that was my mistake. Changing it would be fine with me. Not a big deal, though.
>
> I will update the label names to use the convention `L_name`.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429376416

From mdoerr at openjdk.org  Tue Oct 14 14:28:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Oct 2025 14:28:59 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v11]
In-Reply-To: <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
Message-ID: <I35lZpR2m7g9mPln7YFvyEqXSONq10Rtj_rfyOMf2uA=.561105e3-1dc0-4f1d-81ab-e34e4a91393d@github.com>

On Tue, 14 Oct 2025 14:09:30 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename labels
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3335990595

From matsaave at openjdk.org  Tue Oct 14 14:55:05 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 14 Oct 2025 14:55:05 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>

> Trivial change to remove an unused line of code. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  David and Alan comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27735/files
  - new: https://git.openjdk.org/jdk/pull/27735/files/da3fe2d6..881c3675

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27735&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27735&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27735/head:pull/27735

PR: https://git.openjdk.org/jdk/pull/27735

From mli at openjdk.org  Tue Oct 14 15:22:05 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 15:22:05 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v4]
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <OwUIC8SuSi71Ibg8aVPTPmVN2EH_xFhwD9UaQ1sPLQ4=.10d423d3-8689-4069-8d9f-5441dbfe2ddd@github.com>

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

Hamlin Li 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 19 additional commits since the last revision:

 - reorder
 - Merge branch 'master' into fix-out-of-order-declarations
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - rename
 - move dependency checks into RVExtFeatureValue
 - only verify_deps when debug
 - initial commit
 - initial commit
 - ... and 9 more: https://git.openjdk.org/jdk/compare/efa3c9f3...d8f39f70

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27572/files
  - new: https://git.openjdk.org/jdk/pull/27572/files/58627d3a..d8f39f70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=02-03

  Stats: 28501 lines in 792 files changed: 17421 ins; 7382 del; 3698 mod
  Patch: https://git.openjdk.org/jdk/pull/27572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572

PR: https://git.openjdk.org/jdk/pull/27572

From mli at openjdk.org  Tue Oct 14 15:22:07 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Oct 2025 15:22:07 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v2]
In-Reply-To: <pNEyN-oSMfPDSFrDGwG7O1Qx4VusYVquMMNVssycKsE=.a2cf396a-b025-4f4c-a98d-ec33f22c87ce@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <ejHTtRspLCKoQaTWQtNFYCqz7mzmFY9I-8W6_-9P8Eg=.ed4c10e7-6ede-4b7d-b3be-6324919c9c5a@github.com>
 <3owdP0eYorHp7kuf6j7gMJqQiK_rQAndrc6sHdtkahI=.e6f2e1fc-37d8-481c-ba7a-665fe767099b@github.com>
 <pNEyN-oSMfPDSFrDGwG7O1Qx4VusYVquMMNVssycKsE=.a2cf396a-b025-4f4c-a98d-ec33f22c87ce@github.com>
Message-ID: <gvai1Kj97ojOxDcpinMNrd6FgmQACLAibd8pIqDTmak=.e6054bc1-883a-4a7a-8671-a6c69fdaed75@github.com>

On Tue, 14 Oct 2025 14:09:09 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Here is what I am thinking: Your `verify_deps` only ensures that the declarations of the extensions are in the correct order (as indicated by the `_cpu_feature_index`). And that is the order in which we should follow when enabling these extensions. So for this to work, the order should be refected by `RiscvHwprobe::add_features_from_query_result` which does the work. For safety, I think we should always sync them. Make sense?

OK, I'll reorder it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27572#issuecomment-3402377615

From jcking at openjdk.org  Tue Oct 14 15:12:13 2025
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Oct 2025 15:12:13 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
Message-ID: <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>

> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Qualify identifiers
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27801/files
  - new: https://git.openjdk.org/jdk/pull/27801/files/92248c44..6080b03a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27801/head:pull/27801

PR: https://git.openjdk.org/jdk/pull/27801

From alanb at openjdk.org  Tue Oct 14 15:56:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 15:56:53 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
Message-ID: <gdL-a42x1yiX11rOeieYrdKvPNPiosTQ727RAt6oBGU=.d55303ac-8084-41fa-af1c-be6ed8baba0f@github.com>

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3336386436

From epeter at openjdk.org  Tue Oct 14 15:57:55 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Oct 2025 15:57:55 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v4]
In-Reply-To: <QWmqzjYdZ65c_5asI2RU0p7lJTgY1wARNec5M31x_48=.51150059-12a5-41ad-942b-91de99618482@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <VpbUCxh6209-ARkz9a8Kch9_50FBuBRcu2thAxrJpdM=.3a700c3b-aef1-4052-8073-eb80a39eab68@github.com>
 <tbpTM77zvgntla5fKbKK3hgCXif7pGYrDean1AsVtFk=.9bfc66c8-a0ac-49f7-bbca-217158e340ec@github.com>
 <QWmqzjYdZ65c_5asI2RU0p7lJTgY1wARNec5M31x_48=.51150059-12a5-41ad-942b-91de99618482@github.com>
Message-ID: <WbIhob-mMOb2yhD4kHRwnJ-nqNDLa-hcLJmxxWiYeYE=.2b26ed74-335f-45d7-b8ca-54cd87c24884@github.com>

On Tue, 14 Oct 2025 11:55:36 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Seems good to me, thanks for this cleanup @rwestrel ! I have only a few minor suggestions.
>
> @eme64 new commit should address you comments.

@rwestrel thanks for the updates! The code looks good to me now. I'm running internal testing again before approval :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3402552149

From vlivanov at openjdk.org  Tue Oct 14 15:58:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Oct 2025 15:58:56 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v11]
In-Reply-To: <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
Message-ID: <FvUeV4TC1FIK8sDGBgQa02xpKTGHgKPvjDBmOm-eedY=.9b81a50d-31d1-4b3b-966e-428bc7e17589@github.com>

On Tue, 14 Oct 2025 14:09:30 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename labels
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by vlivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27676#pullrequestreview-3336397515

From vlivanov at openjdk.org  Tue Oct 14 15:58:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Oct 2025 15:58:58 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v10]
In-Reply-To: <onvpkmhYsXrL2Ym5n-evHpiOqqCxbQZKeNgf3MMvX88=.2c0146a5-b67c-4d12-90b1-31a03814b6fd@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Y85v_5exk3-wKIZTL9kg_mtbdc-BWX0CFHKcCLxDpiQ=.34a67318-bcfd-453a-ab3e-a6805fbdf2e8@github.com>
 <nPTyLB27QnTyccjRwgtrxsN6IJsCTJe6hjy6x0bGUbE=.5372192d-6a4e-4dc0-bbef-342f9028b436@github.com>
 <mU48NDUCGLq6A_5lNanvl3eNoMo_buLWIrFOlhtXSgI=.d10f9b4a-6894-44b7-ac15-b78a177e99d2@github.com>
 <onvpkmhYsXrL2Ym5n-evHpiOqqCxbQZKeNgf3MMvX88=.2c0146a5-b67c-4d12-90b1-31a03814b6fd@github.com>
Message-ID: <7kObhycs2_V9ZvqsAI1fLz-g8jnBN5EPyI2gI3T1BdM=.4a40c277-4b35-443b-b687-97c75aa962df@github.com>

On Tue, 14 Oct 2025 13:13:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> True, but I also like the current implementation from a readability perspective.
>
> Let's keep it for now. I will remove `VM_Version::supports_fast_class_init_checks()` from platform-specific code in a follow-up PR.

Sounds good, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429687510

From kvn at openjdk.org  Tue Oct 14 15:59:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 14 Oct 2025 15:59:57 GMT
Subject: RFR: 8369742 link aot linked classes at vm bootstrap
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <ksL8a0AIvK48glnSuY_MFruZ8XuH33PSTAt97r6t6RI=.74faf1d8-ec52-4602-a13e-a4ba71960be1@github.com>

On Tue, 14 Oct 2025 04:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

This assumes that `Foo.doit()` can be called before `Foo.<clinit>` class initialization when `static Bar b = new Bar();` is executed and `Bar` class is initialized. Which should not happened (call `doit()` before `<clinit>`) AFAIU. Do I miss something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27783#issuecomment-3402567420

From kvn at openjdk.org  Tue Oct 14 16:05:15 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 14 Oct 2025 16:05:15 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v11]
In-Reply-To: <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
Message-ID: <PEK9Kgy1pxO-Q-3LDNBuBmQNyk2tC8eBmdZ3kv-iz8c=.b54d6426-b539-471a-8ad1-23671c6815a6@github.com>

On Tue, 14 Oct 2025 14:09:30 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename labels
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

No code change after v08 (only labels were renamed and empty lines removed) - no need to re-test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3402608863

From liach at openjdk.org  Tue Oct 14 16:09:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 Oct 2025 16:09:09 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
Message-ID: <zkoAw_4A5jgg3oVyzVbnobXXjP7ReC1bawrnKo2BRR8=.91a39fc0-e654-4ed8-82f1-8968942ed29b@github.com>

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

A reasonable cleanup.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3336446430

From iklam at openjdk.org  Tue Oct 14 16:44:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Oct 2025 16:44:38 GMT
Subject: RFR: 8369742 link aot linked classes at vm bootstrap
In-Reply-To: <ksL8a0AIvK48glnSuY_MFruZ8XuH33PSTAt97r6t6RI=.74faf1d8-ec52-4602-a13e-a4ba71960be1@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <ksL8a0AIvK48glnSuY_MFruZ8XuH33PSTAt97r6t6RI=.74faf1d8-ec52-4602-a13e-a4ba71960be1@github.com>
Message-ID: <paeLPHIrc2qoXBDWqG_1aS3LNsw8PxsVgCiJsnuSdIk=.0ecee384-284a-45ea-81c0-5a2ba318fb63@github.com>

On Tue, 14 Oct 2025 15:57:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This assumes that `Foo.doit()` can be called before `Foo.<clinit>` class initialization when `static Bar b = new Bar();` is executed and `Bar` class is initialized. Which should not happened (call `doit()` before `<clinit>`) AFAIU. Do I miss something?

If the `Foo` class was cached in AOT-initialized state, then `Foo.<clinit>` is executed only once, during the assembly phase. `Foo.b` will be stored inside the AOT cache. In the production run,  `Foo.<clinit>` is not executed and `Foo.b` will not be re-initialized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27783#issuecomment-3402763634

From tschatzl at openjdk.org  Tue Oct 14 17:09:33 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 17:09:33 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates
Message-ID: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>

Hi all,

  please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.

I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.

That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).

This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.

There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.

The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.

Testing: mentioned test case now behaving correctly, tier1-5

Thanks,
  Thomas

-------------

Commit messages:
 - 8369111

Changes: https://git.openjdk.org/jdk/pull/27789/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369111
  Stats: 111 lines in 9 files changed: 35 ins; 8 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/27789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27789/head:pull/27789

PR: https://git.openjdk.org/jdk/pull/27789

From pchilanomate at openjdk.org  Tue Oct 14 17:18:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 17:18:17 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
Message-ID: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>

If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.

As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.

This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.

### Summary of implementation

The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.

If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 

### Notes

`InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `InterpreterMacroAssembler::call_VM_preemptable_helper` and generalized for calls that take more than one argument, and that can return oops and throw exceptions. Method `InterpreterMacroAssembler::call_VM_preemptable` is now a wrapper that calls the helper, following the pattern of `MacroAssembler::call_VM` and `MacroAssembler::call_VM_helper` methods.

As with platform threads, a virtual thread preempted at `wait_uninterruptibly` that is interrupted will not throw IE, and will preserve the interrupted status. Member `_interruptible` was added to `ObjectWaiter` to differentiate this case against `Object.wait`. Also field `interruptableWait` was added to VirtualThread class, mainly to avoid an interrupted virtual thread in `wait_uninterruptibly` to keep looping and submitting the continuation to the scheduler queue until the class is waiting for is initialized.

Currently (and still with this change), when the thread responsible for initializing a class finishes executing the class initializer, it will set the initialization lock to null so the object can be GC'ed. For platform threads blocked waiting on the initialization lock, the `Handle` in `InstanceKlass::initialize_impl` will still protect the object from being collected until the last thread exits the monitor. For preempted virtual threads though, that `Handle` would have already been destroyed. In order to protect the init_lock from being collected while there are still virtual threads using the associated `ObjectMonitor`, the first preempted virtual thread will put the oop in an `OopHandle` in the `ObjectMonitor` (see `ObjectMonitor::set_object_strong()`), which will be released later when the monitor is deflated.

Preempting at `invokestatic` means the top frame in the `stackChunk` can now have the callee?s arguments at the top of the expression stack, which during gc, will need to be processed as part of that frame (no callee yet). Class `SmallRegisterMap` was therefore modified so that we now have two static instances, one where `include_argument_oops()` returns true and is used when processing the top frame on this case, and the regular one where it return false and it?s used everywhere else. Also, because `InterpretedArgumentOopFinder` calculates the address of oops as offsets from the top of the expression stack, we need to correct possible added alignment after the top frame is thawed, since we can safepoint while redoing the VM call. Class `AnchorMark` was added to deal with this.

### Testing

The changes have been running in the Loom pipeline for several months now. They include new test `KlassInit.java` which exercises preemption on different class initialization cases. Also, the current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time.

-------------

Commit messages:
 - RISC-V support
 - Fix whitespaces
 - v1

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369238
  Stats: 1979 lines in 94 files changed: 1628 ins; 86 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From kvn at openjdk.org  Tue Oct 14 17:28:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 14 Oct 2025 17:28:46 GMT
Subject: RFR: 8369742 link aot linked classes at vm bootstrap
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <2GgcLeRf6a_flBolLQBGI5wcxNOItiI-kCR0d_CFkAI=.1f25843f-b2cd-4e46-900e-1d4ea302f32e@github.com>

On Tue, 14 Oct 2025 04:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 61:

> 59: //
> 60: // Note: we can't link the classes yet because SharedRuntime is not yet ready to generate adapters.
> 61: void AOTLinkedClassBulkLoader::preload_classes(JavaThread* current) {

Why we not ready for adapters? I see `SharedRuntime::init_adapter_library()` is called in from `init_globals()` and `preload_classes()` is called from `init_globals2()` when `universe2_init()` is called.

`SharedRuntime::init_adapter_library()` should populate table with AOT adapters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2429938652

From kbarrett at openjdk.org  Tue Oct 14 18:12:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Oct 2025 18:12:35 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
Message-ID: <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>

On Tue, 14 Oct 2025 15:12:13 GMT, Justin King <jcking at openjdk.org> wrote:

>> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Qualify identifiers
>   
>   Signed-off-by: Justin King <jcking at google.com>

Changes requested by kbarrett (Reviewer).

src/hotspot/share/utilities/bytes.hpp line 81:

> 79: 
> 80:     if (Endian::is_Java_byte_ordering_different()) {
> 81:       x = byteswap(x);

If a little-endian platform doesn't support unaligned accesses, this
restucturing results in this being a byteswap of a byte-by-byte copied value.
Are compilers smart enough to merge those? I think affected platforms are arm,
riscv64, and zero. The old arm and zero code avoids calling byteswap. The old
riscv64 does just use the byteswap approach.

src/hotspot/share/utilities/unalignedAccess.hpp line 53:

> 51:   static void store(void* ptr, T value) {
> 52:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
> 53:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);

I'm not seeing why we should care about trivially default-constructible here?

src/hotspot/share/utilities/unalignedAccess.hpp line 61:

> 59:   static T load(const void* ptr) {
> 60:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
> 61:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);

Don't use `STATIC_ASSERT` in new code; use `static_assert`. C++17 changed `static_assert` to
support uses without a message string.

src/hotspot/share/utilities/unalignedAccess.hpp line 143:

> 141:   }
> 142: };
> 143: #endif

Please add a comment about what condition is being closed.

src/hotspot/share/utilities/unalignedAccess.hpp line 146:

> 144: 
> 145: template<size_t byte_size>
> 146: struct UnalignedAccess::StoreImpl {

These general implementations never get used in the ASAN-specialized case.  Maybe the `#endif`
a few lines back should be an `#else` instead, and just suppress these general implementations
in that case.

src/hotspot/share/utilities/unalignedAccess.hpp line 155:

> 153:     // the actual call to memcpy. On platforms which allow unaligned access,
> 154:     // the compiler will emit a normal store instruction.
> 155:     memcpy(ptr, &value, sizeof(T));

In slowdebug builds this will be pretty terrible, but presumably there aren't enough uses of these
functions for that to matter.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27801#pullrequestreview-3336164044
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2430011521
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2430032532
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2429529774
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2429967249
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2430004064
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2430035937

From asmehra at openjdk.org  Tue Oct 14 18:17:58 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 18:17:58 GMT
Subject: RFR: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field [v11]
In-Reply-To: <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
 <Es9B0vmFGJLSjnivUkZRZMpqxWGkFa5jSXl1tuTY_qg=.0d0f44be-0a15-4706-b038-ab69b8b06cad@github.com>
Message-ID: <SPHfTYoRfaJVtU7xpwTJhYgsNGNVID4ULt5pf9dIGUQ=.5e9c0ad3-a876-4e7f-a462-5ffffafa8dad@github.com>

On Tue, 14 Oct 2025 14:09:30 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename labels
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

okay, lets get this in. Thanks everyone for the reviews and suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3403063807

From asmehra at openjdk.org  Tue Oct 14 18:17:59 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 14 Oct 2025 18:17:59 GMT
Subject: Integrated: 8369296: Add fast class init checks in interpreter for
 resolving ConstantPool entries for static field
In-Reply-To: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
References: <5VZIN2nrMYlpRAOdfsyVCho0ayNDmgFicrHvlhlSxX4=.f97547b7-2467-4a9a-97eb-56cd6cb92155@github.com>
Message-ID: <mWp6a6b9PU8RU79MIWFpWVCjFjzp2xezDRHZ1CTMMyk=.223b5494-29b8-4366-a3c6-5ef3380f701e@github.com>

On Tue, 7 Oct 2025 14:25:47 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
> 
> Testing: tested x86-64 by running `hotspot_runtime` group
> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`

This pull request has now been integrated.

Changeset: 622a611c
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/622a611c338ba766bc1a70c95e8241d1bddf6add
Stats:     228 lines in 6 files changed: 126 ins; 64 del; 38 mod

8369296: Add fast class init checks in interpreter for resolving ConstantPool entries for static field

Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, vlivanov, kvn, amitkumar, fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/27676

From mdoerr at openjdk.org  Tue Oct 14 19:30:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Oct 2025 19:30:05 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <zzGalP0qaZEuS1TsUAVZl82qZrU8FG8s4jRMl4O9GLM=.a772aa70-0dd6-4daa-bc69-bb5d8205d6cc@github.com>

On Tue, 14 Oct 2025 13:42:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

https://github.com/openjdk/jdk/pull/27676 has been integrated which requires resolution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3403294086

From iklam at openjdk.org  Tue Oct 14 19:54:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Oct 2025 19:54:02 GMT
Subject: RFR: 8369742 link aot linked classes at vm bootstrap
In-Reply-To: <2GgcLeRf6a_flBolLQBGI5wcxNOItiI-kCR0d_CFkAI=.1f25843f-b2cd-4e46-900e-1d4ea302f32e@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <2GgcLeRf6a_flBolLQBGI5wcxNOItiI-kCR0d_CFkAI=.1f25843f-b2cd-4e46-900e-1d4ea302f32e@github.com>
Message-ID: <42lD8HcKkSMV7QH5kWxftwD70HV1N_rYCBnnwTCPE2Q=.1ae4c583-21fb-43b0-9970-cab727f01fa9@github.com>

On Tue, 14 Oct 2025 17:26:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 61:
> 
>> 59: //
>> 60: // Note: we can't link the classes yet because SharedRuntime is not yet ready to generate adapters.
>> 61: void AOTLinkedClassBulkLoader::preload_classes(JavaThread* current) {
> 
> Why we not ready for adapters? I see `SharedRuntime::init_adapter_library()` is called in from `init_globals()` and `preload_classes()` is called from `init_globals2()` when `universe2_init()` is called.
> 
> `SharedRuntime::init_adapter_library()` should populate table with AOT adapters.

The current call sequence is:

- SharedRuntime::init_adapter_library()
- AOTLinkedClassBulkLoader::preload_classes()
- MethodHandles::generate_adapters()
- AOTLinkedClassBulkLoader::link_classes()

Method linking calls `Interpreter::entry_for_method()` which looks up from `AbstractInterpreter::_entry_table`. However, this table is not yet initialized when `AOTLinkedClassBulkLoader::preload_classes()` is called. It's initialized inside `MethodHandles::generate_adapters()` which happens much later.

This table doesn't seem to be initialized by `SharedRuntime::init_adapter_library()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2430266856

From vlivanov at openjdk.org  Tue Oct 14 20:07:13 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Oct 2025 20:07:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
Message-ID: <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>

On Tue, 14 Oct 2025 19:48:47 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vmIntrinsics.hpp updates

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AESCrypt extends SymmetricCipher {

Should the class be named `AES_Crypt` instead?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:

> 1406:      */
> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);

There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430292341
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430306371

From pchilanomate at openjdk.org  Tue Oct 14 20:23:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 20:23:33 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8369238
 - RISC-V support
 - Fix whitespaces
 - v1

-------------

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=01
  Stats: 1979 lines in 94 files changed: 1628 ins; 86 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Tue Oct 14 20:23:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 20:23:34 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: <zzGalP0qaZEuS1TsUAVZl82qZrU8FG8s4jRMl4O9GLM=.a772aa70-0dd6-4daa-bc69-bb5d8205d6cc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <zzGalP0qaZEuS1TsUAVZl82qZrU8FG8s4jRMl4O9GLM=.a772aa70-0dd6-4daa-bc69-bb5d8205d6cc@github.com>
Message-ID: <sJzFRqYl_RYBg6PMCb0IjOrWPyrLQMx8iVqpWwcba4k=.1cf5f930-8529-4367-9b7a-ee7dc070f111@github.com>

On Tue, 14 Oct 2025 19:27:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> #27676 has been integrated which requires resolution.
>
Thanks, merged with latest master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3403481837

From liach at openjdk.org  Tue Oct 14 23:12:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 Oct 2025 23:12:34 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang 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 16 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Ioi review
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
 - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Variable name improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - ... and 6 more: https://git.openjdk.org/jdk/compare/336f1cad...25972f2d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/a659f538..25972f2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=05-06

  Stats: 244224 lines in 3760 files changed: 182111 ins; 40283 del; 21830 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From fyang at openjdk.org  Wed Oct 15 02:29:10 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Oct 2025 02:29:10 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v4]
In-Reply-To: <OwUIC8SuSi71Ibg8aVPTPmVN2EH_xFhwD9UaQ1sPLQ4=.10d423d3-8689-4069-8d9f-5441dbfe2ddd@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <OwUIC8SuSi71Ibg8aVPTPmVN2EH_xFhwD9UaQ1sPLQ4=.10d423d3-8689-4069-8d9f-5441dbfe2ddd@github.com>
Message-ID: <evVS5g5uzJq-QgBgHwFX8Xs3Ya9v4A3oIotfcOys754=.3d5de430-f845-4411-9ab5-34391baac52b@github.com>

On Tue, 14 Oct 2025 15:22:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li 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 19 additional commits since the last revision:
> 
>  - reorder
>  - Merge branch 'master' into fix-out-of-order-declarations
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - rename
>  - move dependency checks into RVExtFeatureValue
>  - only verify_deps when debug
>  - initial commit
>  - initial commit
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/492b4569...d8f39f70

Latest version LGTM. Thanks.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 175:

> 173:     }
> 174: 
> 175: #ifndef PRODUCT

Nit: can we switch to use `#ifdef ASSERT` instead in order to better match `DEBUG_ONLY` at the use site?


 #ifdef ASSERT
 #define DEBUG_ONLY(code) code
 #define NOT_DEBUG(code)
 #define NOT_DEBUG_RETURN  /*next token must be ;*/
 #else // ASSERT
 #define DEBUG_ONLY(code)
 #define NOT_DEBUG(code) code
 #define NOT_DEBUG_RETURN {}
 #endif // ASSERT

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27572#pullrequestreview-3338128745
PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2430939120

From kbarrett at openjdk.org  Wed Oct 15 02:37:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 15 Oct 2025 02:37:55 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v3]
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <yHYm5xCFMriiNOPbCUg77EpsRlse1TjArvREZopD2vU=.bf587fc8-e1c4-41f5-9d53-58cf3ab08fc4@github.com>

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

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 13 additional commits since the last revision:

 - Merge branch 'master' into atomic-template-tag-select
 - Merge branch 'master' into atomic-template-tag-select
 - add reference to gcc bug we're working around
 - fix typo in comment
 - update copyrights
 - update FreeListAllocator
 - update nonblockingQueue
 - update LockFreeStack
 - convert StringDedupTable
 - convert SingleWriterSynchronizer
 - ... and 3 more: https://git.openjdk.org/jdk/compare/37effba4...67616416

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27539/files
  - new: https://git.openjdk.org/jdk/pull/27539/files/8cdc458d..67616416

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=01-02

  Stats: 15408 lines in 395 files changed: 9724 ins; 4616 del; 1068 mod
  Patch: https://git.openjdk.org/jdk/pull/27539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27539/head:pull/27539

PR: https://git.openjdk.org/jdk/pull/27539

From fyang at openjdk.org  Wed Oct 15 03:13:07 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Oct 2025 03:13:07 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>

On Mon, 13 Oct 2025 13:02:50 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 201:

> 199:   if (UseZicboz && zicboz_block_size.enabled()) {
> 200:     assert(is_power_of_2(zicboz_block_size.value()) &&
> 201:            zicboz_block_size.value() > 0, "Sanity");

Note the previous discussion about why we need this `> 0` check [1].
@robehn mentions that the kernel seems to have a bug: if it can't retrive those value it will return 0 as value for those.

So maybe simply do:

if (UseZicboz && zicboz_block_size.value() > 0) {
  assert(is_power_of_2(zicboz_block_size.value()), "Sanity");
  ......


[1] https://github.com/openjdk/jdk/pull/27155#issuecomment-3270608461

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:

> 158:       RVExtFeatures::current()->clear_feature(_cpu_feature_index);
> 159:     }
> 160:     int64_t value() { return enabled(); }

Seems redundant in functionality with `enabled()` for extension features. I think this `value()` method should only apply to non-extension features.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 165:

> 163:   class RVNonExtFeatureValue : public RVFeatureValue {
> 164:     int64_t _value;
> 165:     static const int64_t DISABLED_VALUE = -1;

I am not sure but is it better to rename it as `DEFAULT_VALUE`?

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 171:

> 169:       _value(DISABLED_VALUE) {
> 170:     }
> 171:     bool enabled() { return _value != DISABLED_VALUE; }

Do we really need this `enabled()` method for non-extension features? I think this `enabled()` method should only apply to extension features.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 172:

> 170:     }
> 171:     bool enabled() { return _value != DISABLED_VALUE; }
> 172:     void enable_feature(int64_t value) { _value = value; }

Can you add an assertion to make sure that the passed `value` won't equal to the default value -1?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2430978496
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2430990502
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2430979297
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2430987912
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2430981579

From fyang at openjdk.org  Wed Oct 15 03:22:06 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Oct 2025 03:22:06 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <XcJlM3nl16rnId7eeLmnG2qjMLCIc0HrD6h9Vb0tdg0=.4a6b996c-aa37-498a-89b6-cb302c3bc544@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <XcJlM3nl16rnId7eeLmnG2qjMLCIc0HrD6h9Vb0tdg0=.4a6b996c-aa37-498a-89b6-cb302c3bc544@github.com>
Message-ID: <VLKuOxiPgGmw4yUYferGBRZysVRzYC3NFc1NXMJU3Ho=.39cf2a59-66e8-42f8-a42a-38b8bed67371@github.com>

On Fri, 10 Oct 2025 09:44:02 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modify the global flag change

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 161:

> 159:   }
> 160: 
> 161:   if (UseUnalignedAccesses) {

This doesn't look right to me. Because `UseUnalignedAccesses` is used before properly assigned. This option is set at L171.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2431000527

From duke at openjdk.org  Wed Oct 15 05:28:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:31 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v3]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <pvGmT_u4TE-_gtt7yhf058HoRipYgkQVI8oYbkEV1SY=.5b4110d3-06bb-4acd-b505-56d93502fb67@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with two additional commits since the last revision:

 - encryptBlock/decryptBlock methods set to package-private
 - Revert AESCrypt to AES_Crypt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/af0f9c4c..07003719

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Wed Oct 15 05:28:34 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:34 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
 <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>
Message-ID: <D2KZsuYONV7RWb5pLafjRBxTUuduVnH4yy78DUFc0vQ=.43c62b91-7a35-40c1-a24c-dbd9ab669b59@github.com>

On Tue, 14 Oct 2025 19:59:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add vmIntrinsics.hpp updates
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AESCrypt extends SymmetricCipher {
> 
> Should the class be named `AES_Crypt` instead?

Yes, you're right.  I'm not sure how it reverted back to AESCrypt.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:
> 
>> 1406:      */
>> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
>> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);
> 
> There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

Good catch, I will leave it as package-private then.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431157744
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431158083

From duke at openjdk.org  Wed Oct 15 05:51:40 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:51:40 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Add remaining files to be staged

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/07003719..3fc25aef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=02-03

  Stats: 30 lines in 12 files changed: 0 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From sspitsyn at openjdk.org  Wed Oct 15 06:09:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 06:09:16 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
Message-ID: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>

On Tue, 14 Oct 2025 23:12:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang 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 16 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Ioi review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Variable name improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e7527539...25972f2d

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:

> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
> 94:                         // Remove dummy field

Q: Is this dummy field removed or added? Seems to be a mismatch between the comment and the real action.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102:

> 100:     // Extracts ClassVersion values from the provided class bytes.
> 101:     private static int getClassBytesVersion(byte[] classBytes) {
> 102:         ClassModel clazz = ClassFile.of().parse(classBytes);

Nit: Better to make it consistent with the case below and call it `classModel` instead of `clazz`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431212827
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431217408

From sspitsyn at openjdk.org  Wed Oct 15 06:09:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 06:09:17 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
 <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
Message-ID: <YhG4F1UYY6fAnKDDQ96AgMA76qah89ew1ZNER3_ctEE=.234eca17-5377-431b-a11c-59765da9838f@github.com>

On Wed, 15 Oct 2025 06:03:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang 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 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Ioi review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Variable name improvements
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e7527539...25972f2d
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102:
> 
>> 100:     // Extracts ClassVersion values from the provided class bytes.
>> 101:     private static int getClassBytesVersion(byte[] classBytes) {
>> 102:         ClassModel clazz = ClassFile.of().parse(classBytes);
> 
> Nit: Better to make it consistent with the case below and call it `classModel` instead of `clazz`.

BTW, thank you for previous re-naming.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431221860

From rehn at openjdk.org  Wed Oct 15 06:11:03 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 15 Oct 2025 06:11:03 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <FelQRr9BGmaQC0RIxGg9dIkhzSNLk_eHcbBymWr9H34=.4f89aa00-3c9e-46ae-a680-533c4b32d38e@github.com>

On Mon, 13 Oct 2025 13:02:50 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 110:

> 108:   if (mvendorid.value() == RIVOS) {
> 109:     if (FLAG_IS_DEFAULT(UseConservativeFence)) {
> 110:       FLAG_SET_DEFAULT(UseConservativeFence, false);

I change UseConservativeFence default to false, but I forgot to remove this.
So you can just remove this part instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431220709

From rehn at openjdk.org  Wed Oct 15 06:11:05 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 15 Oct 2025 06:11:05 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled
In-Reply-To: <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
Message-ID: <ZMDX9XMw8CTHGcT25KkmjBnfoURA-d-fFzRoQZQKlOs=.b50b0fe4-2f56-413f-9e86-9e5f27a0d356@github.com>

On Wed, 15 Oct 2025 02:56:30 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> @RealFYang 
>> 
>> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
>> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
>> And also do some simple refactoring related to enable/disable/enabled and so on.
>> 
>> Thanks
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 201:
> 
>> 199:   if (UseZicboz && zicboz_block_size.enabled()) {
>> 200:     assert(is_power_of_2(zicboz_block_size.value()) &&
>> 201:            zicboz_block_size.value() > 0, "Sanity");
> 
> Note the previous discussion about why we need this `> 0` check [1].
> @robehn mentions that the kernel seems to have a bug: if it can't retrive those value it will return 0 as value for those.
> 
> So maybe simply do:
> 
> if (UseZicboz && zicboz_block_size.value() > 0) {
>   assert(is_power_of_2(zicboz_block_size.value()), "Sanity");
>   ......
> 
> 
> [1] https://github.com/openjdk/jdk/pull/27155#issuecomment-3270608461

Yes, it seems like we need to check these for a non 0 value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431223102

From schernyshev at openjdk.org  Wed Oct 15 06:28:20 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 15 Oct 2025 06:28:20 GMT
Subject: RFR: 8349988: Change cgroup version detection logic to not depend
 on /proc/cgroups [v4]
In-Reply-To: <DP8SOCC2ZNI6jVQhM2iwNY1DdYQo-N4U8wW3s5wGsT4=.640b0d54-a7a7-4c72-829f-af30ec093e22@github.com>
References: <BBLqBQtdYk7p51YvIOxll3Z4wLBFNENdMBpjzNB7w_c=.f853b012-994e-4292-b59d-0ea1b04ff7b6@github.com>
 <K7Q2MufSUokbS-cE9d6ByBUAg7MsM8UkHQ4qMzAOKAA=.90d30d0b-1d0d-4d9d-a5d7-5a929f7ba3d8@github.com>
 <WhKzdkTVXjZMdJeRzwIsWgkec2eO6N9UYsh0hmikxEI=.91d34204-b495-4c4d-b807-9197edef4720@github.com>
 <jRmq3zvJlWDVD4EybKhLt_tU0AJLkC24-FqwAEJgLdY=.2dbdee77-0137-453e-b180-60a0084eca7d@github.com>
 <W66WwlqNJVlFGpBteLBkd7dD1U_wJhBLL3jmWluMzCk=.d1526d58-250d-4797-97fb-51d5c90d9197@github.com>
 <DP8SOCC2ZNI6jVQhM2iwNY1DdYQo-N4U8wW3s5wGsT4=.640b0d54-a7a7-4c72-829f-af30ec093e22@github.com>
Message-ID: <gB0PeLrYF7raFAsyEsvbw-FS0DAQ2JmRpnuv7Zu1wEc=.201ed5e9-e17f-4fb0-a7c2-83e85b48fe77@github.com>

On Tue, 14 Oct 2025 08:49:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> First step would be JDK 21. JDK 17 I'm not sure. It'll depend how the patch will look like.

JDK 21 patch is mostly clean (minor context issue). I will do the backport next week, if @fitzsim does not take it over. JDK 17 backport won't be clean, JDK 17 doesn't have [JDK-8301479](https://bugs.openjdk.org/browse/JDK-8301479) and [JDK-8238161](https://bugs.openjdk.org/browse/JDK-8238161) (NULLs were replaced with nullptr, fopens with os::fopen, both are irrelevant to this patch), [JDK-8347129](https://bugs.openjdk.org/browse/JDK-8347129) (backport is underway) and [JDK-8261242](https://bugs.openjdk.org/browse/JDK-8261242) which I consider a context conflict, not really a dependency (only the variable name has changed).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23811#issuecomment-3404754072

From mli at openjdk.org  Wed Oct 15 08:17:38 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:17:38 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v5]
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  minor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27572/files
  - new: https://git.openjdk.org/jdk/pull/27572/files/d8f39f70..a1dd8de0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572

PR: https://git.openjdk.org/jdk/pull/27572

From mli at openjdk.org  Wed Oct 15 08:17:42 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:17:42 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v4]
In-Reply-To: <evVS5g5uzJq-QgBgHwFX8Xs3Ya9v4A3oIotfcOys754=.3d5de430-f845-4411-9ab5-34391baac52b@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <OwUIC8SuSi71Ibg8aVPTPmVN2EH_xFhwD9UaQ1sPLQ4=.10d423d3-8689-4069-8d9f-5441dbfe2ddd@github.com>
 <evVS5g5uzJq-QgBgHwFX8Xs3Ya9v4A3oIotfcOys754=.3d5de430-f845-4411-9ab5-34391baac52b@github.com>
Message-ID: <AHqWuVvxvR2fQhKaD18WSKnHwgr9cfyBrF5x6w0Oi7U=.e6f7c1fd-4a5f-4003-8ada-bf72d82d0914@github.com>

On Wed, 15 Oct 2025 02:20:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li 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 19 additional commits since the last revision:
>> 
>>  - reorder
>>  - Merge branch 'master' into fix-out-of-order-declarations
>>  - Merge branch 'openjdk:master' into master
>>  - Merge branch 'openjdk:master' into master
>>  - Merge branch 'openjdk:master' into master
>>  - rename
>>  - move dependency checks into RVExtFeatureValue
>>  - only verify_deps when debug
>>  - initial commit
>>  - initial commit
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/7f9bbe17...d8f39f70
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 175:
> 
>> 173:     }
>> 174: 
>> 175: #ifndef PRODUCT
> 
> Nit: can we switch to use `#ifdef ASSERT` instead in order to better match `DEBUG_ONLY` at the use site?
> 
> 
>  #ifdef ASSERT
>  #define DEBUG_ONLY(code) code
>  #define NOT_DEBUG(code)
>  #define NOT_DEBUG_RETURN  /*next token must be ;*/
>  #else // ASSERT
>  #define DEBUG_ONLY(code)
>  #define NOT_DEBUG(code) code
>  #define NOT_DEBUG_RETURN {}
>  #endif // ASSERT

sure, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27572#discussion_r2431552745

From dlunden at openjdk.org  Wed Oct 15 08:23:34 2025
From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=)
Date: Wed, 15 Oct 2025 08:23:34 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with HotSpot
 coding style
Message-ID: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>

A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.

### Changeset
- Rename methods in `regmask.hpp` to conform with HotSpot coding style.
- Similarly rename directly related methods in `chaitin.hpp`.
- Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
- Fix a few additional code style issues at lines touched by the changeset.

Note: this is a syntax-only changeset (no functional changes).

### Testing

- [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
- `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

-------------

Commit messages:
 - Fix issue

Changes: https://git.openjdk.org/jdk/pull/27817/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369569
  Stats: 624 lines in 31 files changed: 12 ins; 0 del; 612 mod
  Patch: https://git.openjdk.org/jdk/pull/27817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27817/head:pull/27817

PR: https://git.openjdk.org/jdk/pull/27817

From wenanjian at openjdk.org  Wed Oct 15 08:35:15 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Wed, 15 Oct 2025 08:35:15 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <VLKuOxiPgGmw4yUYferGBRZysVRzYC3NFc1NXMJU3Ho=.39cf2a59-66e8-42f8-a42a-38b8bed67371@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <XcJlM3nl16rnId7eeLmnG2qjMLCIc0HrD6h9Vb0tdg0=.4a6b996c-aa37-498a-89b6-cb302c3bc544@github.com>
 <VLKuOxiPgGmw4yUYferGBRZysVRzYC3NFc1NXMJU3Ho=.39cf2a59-66e8-42f8-a42a-38b8bed67371@github.com>
Message-ID: <UxykvDuZGbPR5w7GXqFqZ85Yc0Uht9CqDAN8bdLB3rc=.7cd69734-45be-4896-ab50-77b4044046c9@github.com>

On Wed, 15 Oct 2025 03:17:59 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify the global flag change
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 161:
> 
>> 159:   }
>> 160: 
>> 161:   if (UseUnalignedAccesses) {
> 
> This doesn't look right to me. Because `UseUnalignedAccesses` is used before properly assigned. This option is set at L171.

I get it, can we just move this set after L171 since there is no other place set UsePoly1305Intrinsics?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2431621669

From mli at openjdk.org  Wed Oct 15 08:42:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:42:03 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <38EnYU2ou3fnkZl47w2YKvr7mPFLibLozZznoVDxnO4=.53eb238f-2c91-45db-9c8e-41e7e16b7213@github.com>

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27771/files
  - new: https://git.openjdk.org/jdk/pull/27771/files/48c78ad9..50bc9bb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=00-01

  Stats: 19 lines in 2 files changed: 3 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27771/head:pull/27771

PR: https://git.openjdk.org/jdk/pull/27771

From mli at openjdk.org  Wed Oct 15 08:42:06 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:42:06 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <FelQRr9BGmaQC0RIxGg9dIkhzSNLk_eHcbBymWr9H34=.4f89aa00-3c9e-46ae-a680-533c4b32d38e@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <FelQRr9BGmaQC0RIxGg9dIkhzSNLk_eHcbBymWr9H34=.4f89aa00-3c9e-46ae-a680-533c4b32d38e@github.com>
Message-ID: <TbvSVcpTS1INQsPDWi2zc_3dIUPe3uQKLETIsv137eY=.c3fe2ca7-6397-48ad-9113-97b214b67eff@github.com>

On Wed, 15 Oct 2025 06:06:05 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 110:
> 
>> 108:   if (mvendorid.value() == RIVOS) {
>> 109:     if (FLAG_IS_DEFAULT(UseConservativeFence)) {
>> 110:       FLAG_SET_DEFAULT(UseConservativeFence, false);
> 
> I change UseConservativeFence default to false, but I forgot to remove this.
> So you can just remove this part instead.

sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431641694

From mli at openjdk.org  Wed Oct 15 08:42:09 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:42:09 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <ZMDX9XMw8CTHGcT25KkmjBnfoURA-d-fFzRoQZQKlOs=.b50b0fe4-2f56-413f-9e86-9e5f27a0d356@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <ZMDX9XMw8CTHGcT25KkmjBnfoURA-d-fFzRoQZQKlOs=.b50b0fe4-2f56-413f-9e86-9e5f27a0d356@github.com>
Message-ID: <y_tQVrfxV6EOsNyAzheuHSr8en-dq5oy9HY9O2KqtWk=.bc91fd22-a39e-46ca-a455-fb65769a8738@github.com>

On Wed, 15 Oct 2025 06:07:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 201:
>> 
>>> 199:   if (UseZicboz && zicboz_block_size.enabled()) {
>>> 200:     assert(is_power_of_2(zicboz_block_size.value()) &&
>>> 201:            zicboz_block_size.value() > 0, "Sanity");
>> 
>> Note the previous discussion about why we need this `> 0` check [1].
>> @robehn mentions that the kernel seems to have a bug: if it can't retrive those value it will return 0 as value for those.
>> 
>> So maybe simply do:
>> 
>> if (UseZicboz && zicboz_block_size.value() > 0) {
>>   assert(is_power_of_2(zicboz_block_size.value()), "Sanity");
>>   ......
>> 
>> 
>> [1] https://github.com/openjdk/jdk/pull/27155#issuecomment-3270608461
>
> Yes, it seems like we need to check these for a non 0 value.

OK, will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431639081

From mli at openjdk.org  Wed Oct 15 08:42:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:42:18 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
Message-ID: <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>

On Wed, 15 Oct 2025 03:07:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:
> 
>> 158:       RVExtFeatures::current()->clear_feature(_cpu_feature_index);
>> 159:     }
>> 160:     int64_t value() { return enabled(); }
> 
> Seems redundant in functionality with `enabled()` for extension features. I think this `value()` method should only apply to non-extension features.

Same as the above one. In `VM_Version::setup_cpu_available_features()`, we still need it.

> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 165:
> 
>> 163:   class RVNonExtFeatureValue : public RVFeatureValue {
>> 164:     int64_t _value;
>> 165:     static const int64_t DISABLED_VALUE = -1;
> 
> I am not sure but is it better to rename it as `DEFAULT_VALUE`?

will change it.

> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 171:
> 
>> 169:       _value(DISABLED_VALUE) {
>> 170:     }
>> 171:     bool enabled() { return _value != DISABLED_VALUE; }
> 
> Do we really need this `enabled()` method for non-extension features? I think this `enabled()` method should only apply to extension features.

Currently, yes.
In `VM_Version::setup_cpu_available_features()`, we still need it.

> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 172:
> 
>> 170:     }
>> 171:     bool enabled() { return _value != DISABLED_VALUE; }
>> 172:     void enable_feature(int64_t value) { _value = value; }
> 
> Can you add an assertion to make sure that the passed `value` won't equal to the default value -1?

sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431641458
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431639422
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431640732
PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2431639676

From mli at openjdk.org  Wed Oct 15 08:45:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 15 Oct 2025 08:45:26 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v6]
In-Reply-To: <UxykvDuZGbPR5w7GXqFqZ85Yc0Uht9CqDAN8bdLB3rc=.7cd69734-45be-4896-ab50-77b4044046c9@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <XcJlM3nl16rnId7eeLmnG2qjMLCIc0HrD6h9Vb0tdg0=.4a6b996c-aa37-498a-89b6-cb302c3bc544@github.com>
 <VLKuOxiPgGmw4yUYferGBRZysVRzYC3NFc1NXMJU3Ho=.39cf2a59-66e8-42f8-a42a-38b8bed67371@github.com>
 <UxykvDuZGbPR5w7GXqFqZ85Yc0Uht9CqDAN8bdLB3rc=.7cd69734-45be-4896-ab50-77b4044046c9@github.com>
Message-ID: <7h9BXzDdq-ThB-h4fsLMQhp1ensDEGZB78sktgR-QOY=.2f8e367d-213e-4ce3-a20b-7f95aa4a847e@github.com>

On Wed, 15 Oct 2025 08:32:40 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 161:
>> 
>>> 159:   }
>>> 160: 
>>> 161:   if (UseUnalignedAccesses) {
>> 
>> This doesn't look right to me. Because `UseUnalignedAccesses` is used before properly assigned. This option is set at L171.
>
> I get it, can we just move this set after L171 since there is no other place set UsePoly1305Intrinsics?

Nice catch.

Yes, this needs to be moved after L171.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2431655796

From fandreuzzi at openjdk.org  Wed Oct 15 08:57:56 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 08:57:56 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>

> `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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:

 - remove dead code
 - revert
 - Merge branch 'master' into JDK-8369734
 - use

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/ad416a98..8fbf7599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=00-01

  Stats: 5110 lines in 177 files changed: 1555 ins; 3254 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/27777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777

PR: https://git.openjdk.org/jdk/pull/27777

From fandreuzzi at openjdk.org  Wed Oct 15 09:00:03 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:00:03 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used
In-Reply-To: <gabbHqM7XDza_MsjQWTDUs-JeLr521xrM-Im3BGBi_c=.0c3f26ba-387e-437d-a804-f895a855e71c@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <gabbHqM7XDza_MsjQWTDUs-JeLr521xrM-Im3BGBi_c=.0c3f26ba-387e-437d-a804-f895a855e71c@github.com>
Message-ID: <7bwGb0-sxPKYEcK7XXUa9XiPjeft5hUAsh_fX2VFTVI=.67b62c75-c78f-4d3c-8b9a-de63f213c2b9@github.com>

On Tue, 14 Oct 2025 05:37:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Sorry for ping-ponging on the serviceability labeling. I'm not sure this is the right fix. The logic to return a value from `post_class_file_load_hook` was added way back in JDK 9 by [JDK-8171008](https://bugs.openjdk.org/browse/JDK-8171008) as part of the original AOT compiler effort. But at that time no changes were made to any of the callers to use the new return value! That means this aspect of the code is completely untested - and it is also completely undocumented.
> 
> I'd be more inclined to treat the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ?

Thanks for the feedback @dholmes-ora and @sspitsyn, I removed the dead code in 8fbf759.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405308607

From duke at openjdk.org  Wed Oct 15 09:07:52 2025
From: duke at openjdk.org (=?UTF-8?B?QW50w7Nu?= Seoane Ampudia)
Date: Wed, 15 Oct 2025 09:07:52 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style
In-Reply-To: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
Message-ID: <NBw6QBm3lqHeFTRz1stJcaN3jraHkXRsTFE75X4hc4s=.226c60ef-51cc-4817-89cc-f022c0dc9fa8@github.com>

On Wed, 15 Oct 2025 08:14:26 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
> 
> ### Changeset
> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
> - Similarly rename directly related methods in `chaitin.hpp`.
> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
> - Fix a few additional code style issues at lines touched by the changeset.
> 
> Note: this is a syntax-only changeset (no functional changes).
> 
> ### Testing
> 
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

Marked as reviewed by anton-seoane at github.com (no known OpenJDK username).

Looks good!

-------------

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3339236292
PR Comment: https://git.openjdk.org/jdk/pull/27817#issuecomment-3405337479

From mdoerr at openjdk.org  Wed Oct 15 09:21:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 09:21:55 GMT
Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers
 [v5]
In-Reply-To: <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
 <eg9Nn7IAi0g2s98lDjeX0V3oEG-5hZHgPV2_X5eBLlY=.f520f79c-f4ab-4e53-986a-5acd59a4cc32@github.com>
Message-ID: <wqDj-Jj9_-ZCPTj9wC2HrgqEHPstqDaKONtp0jhDhZY=.3cc39565-36a1-44ac-931d-6ef1cd6cf604@github.com>

On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage.
>
> Martin Doerr 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 remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Move nmethod entry barrier code up in the signal handler.
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - 8334247: [PPC64] Consider trap based nmethod entry barriers

Got the confirmation that the bad performance numbers in the picture above are not a reproducible regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3405393540

From mdoerr at openjdk.org  Wed Oct 15 09:22:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 09:22:53 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <6-SGkLGIijJHm6qmQ8ro-SX9sFIEumElgIsyR2w4aJE=.64499300-2d0d-4cec-a98f-76af77f49cc6@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

I've rerun tests and haven't seen any issues on SAP supported platforms (including linux and AIX on PPC64).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3405412507

From mdoerr at openjdk.org  Wed Oct 15 09:21:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 09:21:55 GMT
Subject: Integrated: 8334247: [PPC64] Consider trap based nmethod entry
 barriers
In-Reply-To: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
Message-ID: <_-ZcNSj4PqHF9dAatV-jvHv80E1TRDLsx5I0DD0JUv4=.35c195f1-07cf-49f6-aa21-daaa458de78d@github.com>

On Thu, 20 Mar 2025 15:41:56 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage.

This pull request has now been integrated.

Changeset: 112d8852
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/112d88523d9d75829594da466c9b66dfe157cc3e
Stats:     67 lines in 8 files changed: 46 ins; 2 del; 19 mod

8334247: [PPC64] Consider trap based nmethod entry barriers

Reviewed-by: ssarathi, rrich

-------------

PR: https://git.openjdk.org/jdk/pull/24135

From sspitsyn at openjdk.org  Wed Oct 15 09:27:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 09:27:41 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
Message-ID: <gS-j63ZrX4rTb9cGfUAuEHH6YB0st1S16AjB59pGcGU=.7788359b-dbaa-4701-8429-4acdee0a9364@github.com>

On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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:
> 
>  - remove dead code
>  - revert
>  - Merge branch 'master' into JDK-8369734
>  - use

Thank you for taking care about this and update!
Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3339340217

From fandreuzzi at openjdk.org  Wed Oct 15 09:32:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:32:19 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v3]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  don't return

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/8fbf7599..8f7f0feb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777

PR: https://git.openjdk.org/jdk/pull/27777

From fandreuzzi at openjdk.org  Wed Oct 15 09:32:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:32:22 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
Message-ID: <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>

On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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:
> 
>  - remove dead code
>  - revert
>  - Merge branch 'master' into JDK-8369734
>  - use

Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405455797

From kevinw at openjdk.org  Wed Oct 15 10:08:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:08:23 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <MVJQcBy20VCW_1d6FPkMG_o4OnH_z5GpEio-LvSqfJk=.8c300a68-6295-411e-94a2-7b7188d3cafd@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

A possible more generic api doc:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> This is the CPU time used by all garbage collection activity, 
	 * including any overhead, which means the result may be non-zero 
	 * even if no GC has occurred. 
	 *
	 * This method may return {@code -1} if the
     * platform does not support this operation or the information is not available at any time.
	 *
     * @implNote Reported time will include relevant implementation-specific details such as
	 * driver threads, workers, VM Operations and string deduplication (if enabled). 
	 * This method will return -1 if called during shutdown.
     *
	 * @return the total accumulated CPU time for garbage collection
     * in nanoseconds, or -1
     * 
     * @since 26
     */
	 public long getTotalGcCpuTime();

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405609355

From kevinw at openjdk.org  Wed Oct 15 10:17:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:17:35 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Or:


     * @implNote Time calculation is implementation-specific, and may include details
	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405648131

From fyang at openjdk.org  Wed Oct 15 10:51:42 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Oct 2025 10:51:42 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v5]
In-Reply-To: <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
Message-ID: <okE5hQclXhDuljp_c3uXmXFznwE0-iQF5_zyjU-2Wts=.fff59af2-b5da-4a8e-9f2a-9d7dd9414c5d@github.com>

On Wed, 15 Oct 2025 08:17:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27572#pullrequestreview-3339754177

From dholmes at openjdk.org  Wed Oct 15 12:03:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Oct 2025 12:03:09 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
Message-ID: <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>

On Tue, 14 Oct 2025 14:55:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David and Alan comments

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27735#pullrequestreview-3340007656

From dholmes at openjdk.org  Wed Oct 15 12:40:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Oct 2025 12:40:00 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v3]
In-Reply-To: <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
Message-ID: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>

On Wed, 15 Oct 2025 09:32:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't return

LGTM. Thanks

src/hotspot/share/prims/jvmtiExport.cpp line 985:

> 983:     }
> 984:     if (new_data != nullptr) {
> 985:       // this agent has modified class data.

The comment could stay.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3340151397
PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432392717

From jcking at openjdk.org  Wed Oct 15 13:50:27 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Oct 2025 13:50:27 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
 <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
Message-ID: <hR0BdgBPqubbS3L71_mkylcelI0PZPO1l7ZcP1zASvo=.596fe639-7a0a-4fe4-813f-30449f3f3828@github.com>

On Tue, 14 Oct 2025 17:57:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Qualify identifiers
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/bytes.hpp line 81:
> 
>> 79: 
>> 80:     if (Endian::is_Java_byte_ordering_different()) {
>> 81:       x = byteswap(x);
> 
> If a little-endian platform doesn't support unaligned accesses, this
> restucturing results in this being a byteswap of a byte-by-byte copied value.
> Are compilers smart enough to merge those? I think affected platforms are arm,
> riscv64, and zero. The old arm and zero code avoids calling byteswap. The old
> riscv64 does just use the byteswap approach.

Godbolt

Clang ARM 32-bit:



new_get_Java_u4(void const*):
        ldrb    r1, [r0]
        ldrb    r2, [r0, #1]
        ldrb    r3, [r0, #2]
        ldrb    r0, [r0, #3]
        orr     r1, r1, r2, lsl #8
        orr     r0, r3, r0, lsl #8
        orr     r0, r1, r0, lsl #16
        rev     r0, r0
        bx      lr

old_get_Java_u4(unsigned char*):
        ldrb    r2, [r0, #1]
        ldrb    r1, [r0]
        ldrb    r3, [r0, #2]
        lsl     r2, r2, #16
        orr     r1, r2, r1, lsl #24
        ldrb    r0, [r0, #3]
        orr     r1, r1, r3, lsl #8
        orr     r0, r1, r0
        bx      lr


GCC ARM 32-bit:


new_get_Java_u4(void const*):
        ldr     r0, [r0]  @ unaligned
        rev     r0, r0
        bx      lr
old_get_Java_u4(unsigned char*):
        ldr     r0, [r0]  @ unaligned
        rev     r0, r0
        bx      lr

> src/hotspot/share/utilities/unalignedAccess.hpp line 53:
> 
>> 51:   static void store(void* ptr, T value) {
>> 52:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
>> 53:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);
> 
> I'm not seeing why we should care about trivially default-constructible here?

This is more just for language correctness, in case somebody tries to use this with a class or struct that is non-trivial.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432636278
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432638366

From fandreuzzi at openjdk.org  Wed Oct 15 13:52:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 13:52:11 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  restore comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/8f7f0feb..37817420

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27777&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777

PR: https://git.openjdk.org/jdk/pull/27777

From fandreuzzi at openjdk.org  Wed Oct 15 13:52:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 13:52:13 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
 <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>
Message-ID: <8ofLOCG9laKHDsIkzUfXzP8om2uYZ8ouWT72U5gXI5s=.cbffb1ba-244b-4fbb-ad2e-cf036613422d@github.com>

On Wed, 15 Oct 2025 12:35:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore comment
>
> src/hotspot/share/prims/jvmtiExport.cpp line 985:
> 
>> 983:     }
>> 984:     if (new_data != nullptr) {
>> 985:       // this agent has modified class data.
> 
> The comment could stay.

378174203615473d5216cc67fbde50933c3c1c87

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432637267

From jcking at openjdk.org  Wed Oct 15 13:58:42 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Oct 2025 13:58:42 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v3]
In-Reply-To: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
Message-ID: <Omk6jMCx7V5HS_5V5LEK5LAqEPEhUowmKGAUZYE3LnQ=.ebf62d2a-e922-48bf-90aa-0694780c600f@github.com>

> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Replace STATIC_ASSERT with static_assert
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27801/files
  - new: https://git.openjdk.org/jdk/pull/27801/files/6080b03a..b5ee743c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=01-02

  Stats: 20 lines in 1 file changed: 1 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27801/head:pull/27801

PR: https://git.openjdk.org/jdk/pull/27801

From jcking at openjdk.org  Wed Oct 15 13:58:45 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Oct 2025 13:58:45 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v3]
In-Reply-To: <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
 <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
Message-ID: <QRByAFZM3wSDFy2hFTkaR1uMT6Lvyzc4YyuLEZBigu4=.59abb266-fca0-4401-ae55-1171d3f94182@github.com>

On Tue, 14 Oct 2025 15:03:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace STATIC_ASSERT with static_assert
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/unalignedAccess.hpp line 61:
> 
>> 59:   static T load(const void* ptr) {
>> 60:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
>> 61:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);
> 
> Don't use `STATIC_ASSERT` in new code; use `static_assert`. C++17 changed `static_assert` to
> support uses without a message string.

Ah, just assumed we were still using STATIC_ASSERT style-wise. Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432659753

From jcking at openjdk.org  Wed Oct 15 13:58:51 2025
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Oct 2025 13:58:51 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
 <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
Message-ID: <VqVxP5g0RPQcuje_SKclJXRtG6z5C-dLt19x0e5IMho=.75aebefa-3804-44ec-a0ba-936dd6a63807@github.com>

On Tue, 14 Oct 2025 17:38:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Qualify identifiers
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/unalignedAccess.hpp line 143:
> 
>> 141:   }
>> 142: };
>> 143: #endif
> 
> Please add a comment about what condition is being closed.

Done.

> src/hotspot/share/utilities/unalignedAccess.hpp line 146:
> 
>> 144: 
>> 145: template<size_t byte_size>
>> 146: struct UnalignedAccess::StoreImpl {
> 
> These general implementations never get used in the ASAN-specialized case.  Maybe the `#endif`
> a few lines back should be an `#else` instead, and just suppress these general implementations
> in that case.

Fair point. Moved them to an `#else`.

> src/hotspot/share/utilities/unalignedAccess.hpp line 155:
> 
>> 153:     // the actual call to memcpy. On platforms which allow unaligned access,
>> 154:     // the compiler will emit a normal store instruction.
>> 155:     memcpy(ptr, &value, sizeof(T));
> 
> In slowdebug builds this will be pretty terrible, but presumably there aren't enough uses of these
> functions for that to matter.

Per godbolt it does not look like any of the compilers, even in `-O0`, ever emit an actual call to `memcpy`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432660235
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432660965
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432650160

From mdoerr at openjdk.org  Wed Oct 15 14:03:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 14:03:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
SIGSEGV in caller_is_deopted:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c



R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
{0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
 - ---- fields (total size 5 words):
 - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
 - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
 - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
 - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
 - transient 'size' 'I' @24  60 (0x0000003c)
 - transient 'modCount' 'I' @28  60 (0x0000003c)
 - 'threshold' 'I' @32  96 (0x00000060)
 - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
R1 =0x0000001fd503201f is an unknown value
R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
 total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
 main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
 stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
 mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
 relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
 metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
 immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
 dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
 scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
 scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
 speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
--------------------------------------------------------------------------------
R3 =0x0000f7cf03817578 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00
R4 =0x0000f7cf038f3040 points into unknown readable memory: 0x0000000100000008 | 08 00 00 00 01 00 00 00
R5 =0x0000f7cf14430000 points into unknown readable memory: 0x0706050403020100 | 00 01 02 03 04 05 06 07
R6 =0x0000000000000006 is an unknown value
R7 =0x000000000000016c is an unknown value
R8 =0x0000f7cf1484ca18 is pointing into the stack for thread: 0x0000f7cf100305c0
R9 =0x0 is null
R10=0x0000f7cf1484c140 is pointing into the stack for thread: 0x0000f7cf100305c0
R11=0x000000000000003d is an unknown value
R12=0x000000000000003c is an unknown value
R13=0x0000f7cf1484ca60 is pointing into the stack for thread: 0x0000f7cf100305c0
R14=0x0000000000000008 is an unknown value
R15=0x0000f7cf15ef5ed9: <offset 0x00000000015c5ed9> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000
R16=0x0000000000000001 is an unknown value
R17=0x0000f7cf1602a6f4: __pthread_mutex_unlock+0x0000000000000000 in /lib/aarch64-linux-gnu/libc.so.6 at 0x0000f7cf15fa0000
R18=0x0000f7cf15ef5e01: <offset 0x00000000015c5e01> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000
R19=0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
Compiled method (c1) 5973 2946       1       java.util.HashMap::values (25 bytes)
 total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
 main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
 stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
 mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
 relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
 metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
 immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
 dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
 scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
 scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
 speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
--------------------------------------------------------------------------------
R20=0x0000f7cf1484ca18 is pointing into the stack for thread: 0x0000f7cf100305c0
R21=0x0000f7cf1484ca98 is pointing into the stack for thread: 0x0000f7cf100305c0
R22=0x0000f7cf1484d380 is pointing into the stack for thread: 0x0000f7cf100305c0
R23=0x0000f7cf1484d370 is pointing into the stack for thread: 0x0000f7cf100305c0
R24=0x0000f7cf1484d470 is pointing into the stack for thread: 0x0000f7cf100305c0
R25=0x000000000000000a is an unknown value
R26=0x000000ff0052b2b8 is pointing into metadata
R27=0x0 is null
R28=0x0000f7cf100305c0 is a thread
R29=0x0000f7cf1484c9d0 is pointing into the stack for thread: 0x0000f7cf100305c0
R30=0x0000f7cf14e83058: <offset 0x0000000000553058> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3406595840

From matsaave at openjdk.org  Wed Oct 15 14:12:48 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:12:48 GMT
Subject: RFR: 8351595: JVM_FindClassFromCaller: unused var may be removed
 [v3]
In-Reply-To: <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
 <NVEWEAAogIzprT5s0z4cmrFh9PPJ0SccFlO4fdwzHJQ=.52891411-963d-463b-bdfa-535d27621d15@github.com>
 <0rnRO_-2MNLAqMn5-9b09DoN7EFJikRtKoNGxF0WKJ8=.75c1f1c4-3e17-4537-84ff-54e3dd3e65a8@github.com>
Message-ID: <l2k0AiDscmxlP-EdgwRaBXIuDn7OwhqQvlKRbtOX8us=.e7750c88-f826-46df-aed1-2c1190ec5546@github.com>

On Wed, 15 Oct 2025 12:00:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   David and Alan comments
>
> Marked as reviewed by dholmes (Reviewer).

Thank you for the comments and reviews @dholmes-ora @fandreuz @AlanBateman and @liach!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27735#issuecomment-3406624739

From matsaave at openjdk.org  Wed Oct 15 14:12:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Oct 2025 14:12:49 GMT
Subject: Integrated: 8351595: JVM_FindClassFromCaller: unused var may be
 removed
In-Reply-To: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
References: <6LlK6Z7XYN9QCQJHSCjtV19f-R7RTlzuJdX2e6B3Mpc=.890d94b6-430e-4b15-b863-18d6aec27289@github.com>
Message-ID: <X015pKujNmbYLYXdv1QQ8xkPM2wnadArlHp1xdByoFI=.3539fd44-05b2-4260-8b3d-0c0e0af76eb3@github.com>

On Thu, 9 Oct 2025 18:29:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This is a cleanup change to remove an unused field `from_class` and the associated argument `caller` from `JVM_FindClassFromCaller` and its callers.  The method `JVM_FindClassFromCaller` has been renamed with these new changes in consideration. Verified with tier1-5 tests.

This pull request has now been integrated.

Changeset: 784af438
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/784af438efd3f2cd8a4c0518b4aa06d496bd7846
Stats:     15 lines in 4 files changed: 0 ins; 5 del; 10 mod

8351595: JVM_FindClassFromCaller: unused var may be removed

Reviewed-by: dholmes, alanb, liach, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/27735

From eosterlund at openjdk.org  Wed Oct 15 15:20:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 15 Oct 2025 15:20:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Dont print error message when there are no archived objects
 - Fix issue in new test
 - Change is_aot_thread implementation
 - update AotJdk problem lists

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/23ef68fb..d6ff880b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=01-02

  Stats: 60 lines in 10 files changed: 28 ins; 4 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From qamai at openjdk.org  Wed Oct 15 16:15:05 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Oct 2025 16:15:05 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v3]
In-Reply-To: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
Message-ID: <pT_iHeVrGBEE0pc_YGYyiJ9iBmnwhNbUx75pOB5l2-Y=.e11d2ba3-03e0-4f84-a6ce-ea584e606c7f@github.com>

> Hi,
> 
> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - remove std::hash
 - remove unordered_map, add some comments for all_instances_size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27618/files
  - new: https://git.openjdk.org/jdk/pull/27618/files/b73850d1..513e3e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27618&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27618&range=01-02

  Stats: 56 lines in 2 files changed: 37 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27618/head:pull/27618

PR: https://git.openjdk.org/jdk/pull/27618

From qamai at openjdk.org  Wed Oct 15 16:15:07 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Oct 2025 16:15:07 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v2]
In-Reply-To: <FE8OfsDddEXs3FBSgUlzpctnhiP_13uBmwQyOk92LZE=.348ba41b-b389-4b79-a4f0-73094a0b8d45@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <JnzyKuGDew8h9oTRzan36PefgqeWPL8drD2ef4ov4zE=.a4ddbb0d-c21c-4bc7-9db6-4c8128dfc52d@github.com>
 <FE8OfsDddEXs3FBSgUlzpctnhiP_13uBmwQyOk92LZE=.348ba41b-b389-4b79-a4f0-73094a0b8d45@github.com>
Message-ID: <jzEVFwjO09KGAvWsRi_OzLVBvn_UKgf6mELzD3B--hQ=.5f7a334e-5449-4553-ad80-f8ae7fdcfdd3@github.com>

On Wed, 15 Oct 2025 12:59:04 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Emanuel's reviews
>
> Nice, thanks for all the updates. I responded to some of the points above.

@eme64 I have removed the usage of `std::unordered_map` as well as added comments explaining the values of `all_instances_size`. Do you have any other concern?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27618#issuecomment-3407258312

From qamai at openjdk.org  Wed Oct 15 16:15:08 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Oct 2025 16:15:08 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v3]
In-Reply-To: <N-REfGjVruI5CZhEvi0_kzRl9jsDDNBAQvyr9Y1Sn2I=.614550aa-fa2a-4076-bd90-f281f28fd89e@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <po2CkpI2NGlJN5VzzRCQvD_utB3SbxV_qQ0Ou7DCBdQ=.79768da3-6fd7-4dd6-b502-d69a583363e3@github.com>
 <lGXCugjzkI7C4JOhBJwyjwQgG61Ngb1sfdKNuFcTN-o=.0ff02050-ecdd-4b2b-8d3e-89461a41a971@github.com>
 <pxTzC3FfnjopfSN1RBqk59tpvBTHiMTLAJ7gHKtzA70=.c2035f53-b809-4f35-89e2-8ad92ecd9fa8@github.com>
 <JoXVIZQfTQWDunqWd_3QdixCUu8U-8zgIlraSdSluIo=.6d33201c-6d3d-4fff-b95e-d94e9175ec62@github.com>
 <odTJ_LfpNYcJSTjOPdsni6m9W5ujtTzbL0WGX7XQCnA=.44c0f8de-5647-491e-b793-605be06dfa76@github.com>
 <6de0G8wZZ7STOtX8_IdiE6ZRKmOC1Y6-559Q6Y2Uxxw=.bef6c2de-68f8-4cec-924e-dd42d7bd13e2@github.com>
 <N-REfGjVruI5CZhEvi0_kzRl9jsDDNBAQvyr9Y1Sn2I=.614550aa-fa2a-4076-bd90-f281f28fd89e@github.com>
Message-ID: <mLeMwIFAglnYMWYrnQvhW_7gHsWEhQ2hVp018CrIW9I=.dec9df1b-a7b6-451b-a1f3-0fd6e0d78118@github.com>

On Wed, 15 Oct 2025 15:36:18 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Not a review, just a drive-by comment, following up on @eme64 "They tell me its fine".
>> 
>> I do not think it's okay to use most standard library headers. Doing so can run into issues with things
>> like our forbidden function mechanism, assert macro collision, and others.  My opinion is the uses in
>> `jfr/test_networkUtilization.cpp` shouldn't be there, and aren't actually necessary.  I just did a spot check,
>> and the only "good" case I found is `test_codestrings.cpp` using `<regex>`, where there isn't any similar
>> functionality available in hotspot. The suggestion in the discussion @eme64 for a set is `RBTree`.  The O(1)
>> lookup by a hashtable is unlikely to matter to a gtest.
>> 
>> There is ongoing work updating our usage (see, for example, https://bugs.openjdk.org/browse/JDK-8369186)
>> and how to do that in a safe and consistent manner.
>
> Use `RBTreeCHeap`, if going the RBTree route. It's just the easiest way of using it.

Thanks for your inputs, I have removed the usage of `std::unordered_map` and replaced it with `RBTreeCHeap`. Is using `std::array` here fine?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27618#discussion_r2433203193

From jsjolen at openjdk.org  Wed Oct 15 16:29:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 16:29:16 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v3]
In-Reply-To: <mLeMwIFAglnYMWYrnQvhW_7gHsWEhQ2hVp018CrIW9I=.dec9df1b-a7b6-451b-a1f3-0fd6e0d78118@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <po2CkpI2NGlJN5VzzRCQvD_utB3SbxV_qQ0Ou7DCBdQ=.79768da3-6fd7-4dd6-b502-d69a583363e3@github.com>
 <lGXCugjzkI7C4JOhBJwyjwQgG61Ngb1sfdKNuFcTN-o=.0ff02050-ecdd-4b2b-8d3e-89461a41a971@github.com>
 <pxTzC3FfnjopfSN1RBqk59tpvBTHiMTLAJ7gHKtzA70=.c2035f53-b809-4f35-89e2-8ad92ecd9fa8@github.com>
 <JoXVIZQfTQWDunqWd_3QdixCUu8U-8zgIlraSdSluIo=.6d33201c-6d3d-4fff-b95e-d94e9175ec62@github.com>
 <odTJ_LfpNYcJSTjOPdsni6m9W5ujtTzbL0WGX7XQCnA=.44c0f8de-5647-491e-b793-605be06dfa76@github.com>
 <6de0G8wZZ7STOtX8_IdiE6ZRKmOC1Y6-559Q6Y2Uxxw=.bef6c2de-68f8-4cec-924e-dd42d7bd13e2@github.com>
 <N-REfGjVruI5CZhEvi0_kzRl9jsDDNBAQvyr9Y1Sn2I=.614550aa-fa2a-4076-bd90-f281f28fd89e@github.com>
 <mLeMwIFAglnYMWYrnQvhW_7gHsWEhQ2hVp018CrIW9I=.dec9df1b-a7b6-451b-a1f3-0fd6e0d78118@github.com>
Message-ID: <J6cgdbiWx1UbmgcLqw6Co9K7DOrIZfjc93v4EXPyDE4=.811ef2d8-f3c3-4a83-9627-8401c1f18f25@github.com>

On Wed, 15 Oct 2025 16:10:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Use `RBTreeCHeap`, if going the RBTree route. It's just the easiest way of using it.
>
> Thanks for your inputs, I have removed the usage of `std::unordered_map` and replaced it with `RBTreeCHeap`. Is using `std::array` here fine?

Hi @merykitty,

I think that we don't use the STL because we run without exceptions and because we want our production data structures to have custom allocators, and history :-). As `std::array` (AFAIU) is 'just' a typed and sized `T*`, I think it should be fine, as long as you avoid things that might throw!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27618#discussion_r2433256750

From liach at openjdk.org  Wed Oct 15 17:03:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 17:03:26 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Serguei reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/25972f2d..e31476b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=06-07

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From liach at openjdk.org  Wed Oct 15 17:03:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 17:03:33 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
 <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
Message-ID: <nBDHHCtDRuRHT8KW2ET2wynEcjRupIFKDOr1j9zAUdI=.efe054f1-b3b1-4269-a008-89040304508b@github.com>

On Wed, 15 Oct 2025 06:01:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang 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 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Ioi review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Variable name improvements
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/63a83778...25972f2d
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:
> 
>> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
>> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
>> 94:                         // Remove dummy field
> 
> Q: Is this dummy field removed or added? Seems to be a mismatch between the comment and the real action.

Updated to indicate this shuffle is done to shuffle constant pools.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433349624

From rrich at openjdk.org  Wed Oct 15 17:06:10 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Oct 2025 17:06:10 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
Message-ID: <Avv9PuWx1yWbVWOCtQswTv76NlctLw41UfhH2J_lLfU=.c995d998-df8c-4ec4-843a-68dffcbf6bb2@github.com>

On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into JDK-8369238
>  - RISC-V support
>  - Fix whitespaces
>  - v1

Great enhancement indeed @pchilano! The ppc part of it is almost finished. Unfortunately I'm stuck with a problem in verification code already in initial testing. Please see my comment on `verify_frame_kind`.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:

> 1749:                   RegisterMap::ProcessFrames::skip,
> 1750:                   RegisterMap::WalkContinuation::skip);
> 1751:       frame fr = top.sender(&reg_map);

I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.

I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.

It's not quite easy to fix though since `top` can also be on stack.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3341440114
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433336330

From jsjolen at openjdk.org  Wed Oct 15 17:32:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:32:05 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>

On Wed, 8 Oct 2025 22:11:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/oops/constantPool.cpp line 1626:
> 
>> 1624: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
>> 1625:                                  const constantPoolHandle& to_cp,
>> 1626:                                  TRAPS) {
> 
> Nit: Indent is not right.

These indentations faults have been all over (all my fault of course), thank you for spotting them.

> src/hotspot/share/oops/constantPool.inline.hpp line 90:
> 
>> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
>> 89: }
>> 90: 
> 
> Nit: Is this really needed?

I believe that the style is to have an empty line between the code and the endif, so this is a style fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433423167
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433420483

From kbarrett at openjdk.org  Wed Oct 15 17:37:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 15 Oct 2025 17:37:03 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <hR0BdgBPqubbS3L71_mkylcelI0PZPO1l7ZcP1zASvo=.596fe639-7a0a-4fe4-813f-30449f3f3828@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
 <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
 <hR0BdgBPqubbS3L71_mkylcelI0PZPO1l7ZcP1zASvo=.596fe639-7a0a-4fe4-813f-30449f3f3828@github.com>
Message-ID: <tZKx71hqVoA1GUI_YDChCvIql5_nHpYASHqorcsiUZo=.a1dfc22b-7378-4b3b-a265-319f78a74ee8@github.com>

On Wed, 15 Oct 2025 13:47:17 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/hotspot/share/utilities/unalignedAccess.hpp line 53:
>> 
>>> 51:   static void store(void* ptr, T value) {
>>> 52:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
>>> 53:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);
>> 
>> I'm not seeing why we should care about trivially default-constructible here?
>
> This is more just for language correctness, in case somebody tries to use this with a class or struct that is non-trivial.

I agree the `std::is_trivially_copyable` test should be there.
It's the `std::is_trivially_default_constructible` test that I'm questioning. I don't see anything in this code
that has that as a requirement. So I find it confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2433435457

From sspitsyn at openjdk.org  Wed Oct 15 17:39:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 17:39:10 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
 <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
Message-ID: <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>

On Wed, 15 Oct 2025 09:28:40 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?

It is because minimal does not include JVMTI.
A tweak is needed in `jvmtiExport.hpp` at line 383 as for all other functions returning `void`:
  `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3407564232

From kvn at openjdk.org  Wed Oct 15 17:41:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Oct 2025 17:41:10 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap
In-Reply-To: <42lD8HcKkSMV7QH5kWxftwD70HV1N_rYCBnnwTCPE2Q=.1ae4c583-21fb-43b0-9970-cab727f01fa9@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <2GgcLeRf6a_flBolLQBGI5wcxNOItiI-kCR0d_CFkAI=.1f25843f-b2cd-4e46-900e-1d4ea302f32e@github.com>
 <42lD8HcKkSMV7QH5kWxftwD70HV1N_rYCBnnwTCPE2Q=.1ae4c583-21fb-43b0-9970-cab727f01fa9@github.com>
Message-ID: <JdXFyfBaSSa9XhKM2qUFGG1mgP1ySd0MoOKBLmPtW-o=.34e95c31-7f4f-4e33-8958-8e4c0a203664@github.com>

On Tue, 14 Oct 2025 19:51:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 61:
>> 
>>> 59: //
>>> 60: // Note: we can't link the classes yet because SharedRuntime is not yet ready to generate adapters.
>>> 61: void AOTLinkedClassBulkLoader::preload_classes(JavaThread* current) {
>> 
>> Why we not ready for adapters? I see `SharedRuntime::init_adapter_library()` is called in from `init_globals()` and `preload_classes()` is called from `init_globals2()` when `universe2_init()` is called.
>> 
>> `SharedRuntime::init_adapter_library()` should populate table with AOT adapters.
>
> The current call sequence is:
> 
> - SharedRuntime::init_adapter_library()
> - AOTLinkedClassBulkLoader::preload_classes()
> - MethodHandles::generate_adapters()
> - AOTLinkedClassBulkLoader::link_classes()
> 
> Method linking calls `Interpreter::entry_for_method()` which looks up from `AbstractInterpreter::_entry_table`. However, this table is not yet initialized when `AOTLinkedClassBulkLoader::preload_classes()` is called. It's initialized inside `MethodHandles::generate_adapters()` which happens much later.
> 
> This table doesn't seem to be initialized by `SharedRuntime::init_adapter_library()`.

You are right, `MethodHandles::generate_adapters()` is called after `universe2_init()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2433447974

From jsjolen at openjdk.org  Wed Oct 15 17:41:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:41:49 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v13]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <tfCV4U5zP2PfKhHYECcwSnZvhoSqzvjKMBhAS7Q_s9k=.30587383-a834-4c87-a0d7-5fcb710df4c4@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Some nits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/bb3a014d..5e72da4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=11-12

  Stats: 15 lines in 4 files changed: 3 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

PR: https://git.openjdk.org/jdk/pull/27198

From jsjolen at openjdk.org  Wed Oct 15 17:41:51 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:41:51 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
 <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
 <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>
Message-ID: <GH9p2YVtLxbA4u7HL71A_nDn1fel0dIrhuXqoXV2Y6c=.700b1dfb-98ce-4a67-a824-f3c65e86b360@github.com>

On Wed, 8 Oct 2025 20:15:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>>One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management.
>> 
>> I haven'e done any performance testing. I was considering doing so, but the majority of the work that has potentially been slowed down is when redefining classes via JVMTI, as this is when we got to do what essentially boiled down to a `memcpy`. My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?
>> 
>> Regardless, I'll have a look at doing some coarse-grained profiling via Aurora, and also have a look at the generated assembly. The goal of putting some of the functions in the inline file was to give enough context to the compiler so that it can do a good job of optimizing the code, we'll see if that was actually the case.
>
>> My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?
> 
> It depends. And no, it is not always 'human' level (debuggers, etc). It is used by profilers as well especially via Instrumentation API. And yes, JVMTI is that it's less performance sensitive than the usual JVM. However, it'd be nice to improve its performance, not degrade. :)

@sspitsyn , the points about detecting null are good. Let me look at those in more detail tomorrow. I need to a bit more fresh. You might be right, `guarantee` might be preferred here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3407569040

From aph at openjdk.org  Wed Oct 15 17:48:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 15 Oct 2025 17:48:08 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v16]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <z-21oPoL1K-CM4JvLKKTxzazrgIYpVK9OzEy8dHsAKU=.33d85a46-1a91-4fa2-a5a9-82648c0ecde7@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Check for working WX
 - Merge from master
 - Add logging for WX.
 - Add missing WX setter
 - Refactor, fix a couple of bugs introduced during review.
 - Test
 - Review feedback
 - Test
 - More
 - Fix test
 - ... and 24 more: https://git.openjdk.org/jdk/compare/376d77e8...ea6f2a86

-------------

Changes: https://git.openjdk.org/jdk/pull/26562/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=15
  Stats: 465 lines in 36 files changed: 393 ins; 28 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From sspitsyn at openjdk.org  Wed Oct 15 17:52:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 17:52:40 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
Message-ID: <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>

On Wed, 15 Oct 2025 17:03:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Serguei reviews

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:

> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
> 94:                         // Defer dummy fields to defer their associated constant pool entries

Nit: This comment is kind of confusing. What does it mean: `defer dummy fields`? Do you mean `defer adding dummy fields to the class file`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433474192

From valeriep at openjdk.org  Wed Oct 15 17:58:38 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 17:58:38 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AES_Crypt extends SymmetricCipher {

This internal class does not need to be public? I'd assume it's only used within the same package?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:

> 51:     public void setup() throws Exception {
> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});

Is the all-0s IV intentional?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:

> 80:     public byte[] testUseAesIntrinsics() throws Exception {
> 81:         return cipher.doFinal(ct);
> 82:     }

These 3 methods look same to me except for the method names?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433490853
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433487319
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433483607

From fitzsim at openjdk.org  Wed Oct 15 17:59:55 2025
From: fitzsim at openjdk.org (Thomas Fitzsimmons)
Date: Wed, 15 Oct 2025 17:59:55 GMT
Subject: RFR: 8349988: Change cgroup version detection logic to not depend
 on /proc/cgroups [v4]
In-Reply-To: <NlPOizh0GgyVIx1f1nsKN_Ri0LOyJFEj4mBXWHnCTcQ=.d6737cea-397a-4cd1-bfb9-acde2105ad67@github.com>
References: <BBLqBQtdYk7p51YvIOxll3Z4wLBFNENdMBpjzNB7w_c=.f853b012-994e-4292-b59d-0ea1b04ff7b6@github.com>
 <K7Q2MufSUokbS-cE9d6ByBUAg7MsM8UkHQ4qMzAOKAA=.90d30d0b-1d0d-4d9d-a5d7-5a929f7ba3d8@github.com>
 <WhKzdkTVXjZMdJeRzwIsWgkec2eO6N9UYsh0hmikxEI=.91d34204-b495-4c4d-b807-9197edef4720@github.com>
 <jRmq3zvJlWDVD4EybKhLt_tU0AJLkC24-FqwAEJgLdY=.2dbdee77-0137-453e-b180-60a0084eca7d@github.com>
 <NlPOizh0GgyVIx1f1nsKN_Ri0LOyJFEj4mBXWHnCTcQ=.d6737cea-397a-4cd1-bfb9-acde2105ad67@github.com>
Message-ID: <OeU3uCkochFT1PTwOKAlEqbv5cvxZpCF2HQh86hx6_8=.340ad1ec-30f6-40fa-a0ef-53e7fdf9637d@github.com>

On Wed, 2 Apr 2025 19:40:10 GMT, Thomas Fitzsimmons <fitzsim at openjdk.org> wrote:

>>> @jerboaa @fitzsim Does the current mainline code handles mixed configuration where in some controllers are v1 and others v2? For example cpu controller is mounted as v1 while memory controller as v2. If yes, does this patch continue to support such configuration?
>> 
>> The current code does not allow mixed configuration for "relevant" controllers (essentially cpu and memory). That is, they ought to be v1 or v2. In the hybrid case (systemd running on unified), it's considered v1. I don't think this patch changes any of it.
>
> Thank you for re-reviewing, @jerboaa and @ashu-mehra.  I have issued the `integrate` command.  Can one of you please sponsor the change?

> JDK 21 patch is mostly clean (minor context issue). I will do the backport next week, if @fitzsim does not take it over.

@sercher It's fine with me if @jerboaa or you do the backporting; thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23811#issuecomment-3407638104

From sspitsyn at openjdk.org  Wed Oct 15 18:01:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 18:01:45 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
 <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
Message-ID: <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>

On Wed, 15 Oct 2025 17:28:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.inline.hpp line 90:
>> 
>>> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
>>> 89: }
>>> 90: 
>> 
>> Nit: Is this really needed?
>
> I believe that the style is to have an empty line between the code and the endif, so this is a style fix.

The issue is this is the only fix in this file. Should we go and fix all style issues around?
In fact, I'm okay with this tweak. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433497456

From kvn at openjdk.org  Wed Oct 15 18:03:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Oct 2025 18:03:42 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <6O1YIclHxYSabUijnozdlGYxH8Oix1fUitciLeeW0M4=.f8c73353-e471-4932-ba63-71d1381cc670@github.com>

On Tue, 14 Oct 2025 04:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 350:

> 348: // With AOT-linked classes, we could compile nmethods before the ServiceThread
> 349: // has been started, so we must delay the events to be posted later.
> 350: void AOTLinkedClassBulkLoader::add_delayed_compiled_method_load_event(nmethod* nm) {

I don't think it should be done in `AOTLinkedClassBulkLoader`.  Please move it to `nmethod.*` files

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2433502378

From kvn at openjdk.org  Wed Oct 15 18:09:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Oct 2025 18:09:08 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap
In-Reply-To: <6O1YIclHxYSabUijnozdlGYxH8Oix1fUitciLeeW0M4=.f8c73353-e471-4932-ba63-71d1381cc670@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <6O1YIclHxYSabUijnozdlGYxH8Oix1fUitciLeeW0M4=.f8c73353-e471-4932-ba63-71d1381cc670@github.com>
Message-ID: <q4T04AWD85-d2VcH4XGVGqx58Lj3hys28gTNAkFGa3E=.23a94b4b-8c1f-4c5b-8582-59f0a4a1eeed@github.com>

On Wed, 15 Oct 2025 18:00:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 350:
> 
>> 348: // With AOT-linked classes, we could compile nmethods before the ServiceThread
>> 349: // has been started, so we must delay the events to be posted later.
>> 350: void AOTLinkedClassBulkLoader::add_delayed_compiled_method_load_event(nmethod* nm) {
> 
> I don't think it should be done in `AOTLinkedClassBulkLoader`.  Please move it to `nmethod.*` files

This only affects native wrappers as I understand which are generated by Shared runtime. JIT compilers are not initialized yet.  May be update comment to be clear: "With AOT-linked classes, we could compile wrappers for native methods before the ServiceThread"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2433513623

From liach at openjdk.org  Wed Oct 15 18:21:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 18:21:50 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Clarification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/e31476b1..697b8555

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From dbriemann at openjdk.org  Wed Oct 15 18:28:39 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 15 Oct 2025 18:28:39 GMT
Subject: RFR: 8307495: Specialize atomic bitset functions for aix-ppc [v8]
In-Reply-To: <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
 <jYuuGqzFq3do4urHaNrgoujYj1UDbGPUYYlKlknfCGU=.dd1f597a-4b05-4369-bad8-b9eb5ac4c7d1@github.com>
Message-ID: <A3-JBs0EhQ_WHW-ZZvWjpGQrCo1RSn3rbV0CbEsyfIk=.66d6b588-0b9d-4be7-81f7-9ea0ce66818e@github.com>

On Mon, 13 Oct 2025 07:16:06 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Add atomic bitset functions for PPC64.
>> Refactor so that inline assembler code is shared for all PPC64 platforms.
>> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Thank you both for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27650#issuecomment-3407739611

From dbriemann at openjdk.org  Wed Oct 15 18:32:58 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 15 Oct 2025 18:32:58 GMT
Subject: Integrated: 8307495: Specialize atomic bitset functions for aix-ppc
In-Reply-To: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
References: <oZxniq093eO9d3rUb6AW9k8rq5sUn5EFcYgciu6L67I=.ea309015-bcd2-4531-94e2-7437dd1fb9fa@github.com>
Message-ID: <2fZ4QRaNLatvdV_vUMDqCX1Z_sAsgcrCZ5Ptn4QoAUw=.19df6a7e-8ae4-4011-abcc-b2d2003d2f73@github.com>

On Mon, 6 Oct 2025 15:16:26 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Add atomic bitset functions for PPC64.
> Refactor so that inline assembler code is shared for all PPC64 platforms.
> Add back a missing "simple guard" to PlatformCpmxchg<1>. Remove some dead Power7 code.

This pull request has now been integrated.

Changeset: c9cbd31f
Author:    David Briemann <dbriemann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9cbd31f8575a25c4decd68dc645378c5ba2bad0
Stats:     1546 lines in 6 files changed: 649 ins; 878 del; 19 mod

8307495: Specialize atomic bitset functions for aix-ppc

Reviewed-by: mdoerr, rrich

-------------

PR: https://git.openjdk.org/jdk/pull/27650

From valeriep at openjdk.org  Wed Oct 15 18:48:29 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:48:29 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:

> 53: 
> 54:     private static final int AES_256_ROUNDS = 14;
> 55:     private static final int AES_256_NKEYS = 32;

The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433608974

From valeriep at openjdk.org  Wed Oct 15 18:53:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:53:55 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
Message-ID: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>

On Wed, 15 Oct 2025 18:45:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
> 
>> 53: 
>> 54:     private static final int AES_256_ROUNDS = 14;
>> 55:     private static final int AES_256_NKEYS = 32;
> 
> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433622686

From pchilanomate at openjdk.org  Wed Oct 15 19:35:50 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Oct 2025 19:35:50 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <Avv9PuWx1yWbVWOCtQswTv76NlctLw41UfhH2J_lLfU=.c995d998-df8c-4ec4-843a-68dffcbf6bb2@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
 <Avv9PuWx1yWbVWOCtQswTv76NlctLw41UfhH2J_lLfU=.c995d998-df8c-4ec4-843a-68dffcbf6bb2@github.com>
Message-ID: <h3n6l-iaeBBg-n2xDlHHb68PTO9BDJwy_Tp3rwxGjLU=.b6285e20-71cd-401c-b3a6-9c68b9893efd@github.com>

On Wed, 15 Oct 2025 16:54:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into JDK-8369238
>>  - RISC-V support
>>  - Fix whitespaces
>>  - v1
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:
> 
>> 1749:                   RegisterMap::ProcessFrames::skip,
>> 1750:                   RegisterMap::WalkContinuation::skip);
>> 1751:       frame fr = top.sender(&reg_map);
> 
> I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.
> 
> I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.
> 
> It's not quite easy to fix though since `top` can also be on stack.

Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?


diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 86c56fe583f..fb1f66c60f4 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
 static void log_frames(JavaThread* thread, bool dolog = true);
 static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
 static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
-static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
+static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);

 #define assert_pfl(p, ...) \
 do {                                           \
@@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
   return true;
 }

-static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
+static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
   Method* m;
   const char* code_name;
   int bci;
@@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
       RegisterMap reg_map(current,
                   RegisterMap::UpdateMap::skip,
                   RegisterMap::ProcessFrames::skip,
-                  RegisterMap::WalkContinuation::skip);
+                  RegisterMap::WalkContinuation::include);
+      if (top.is_heap_frame()) {
+        assert(chunk != nullptr, "");
+        reg_map.set_stack_chunk(chunk);
+        top = chunk->relativize(top);
+        top.set_frame_index(0);
+      }
       frame fr = top.sender(&reg_map);
       vframe*  vf  = vframe::new_vframe(&fr, &reg_map, current);
       compiledVFrame* cvf = compiledVFrame::cast(vf);
@@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) {
   Method* m = nullptr;
   const char* code_name = nullptr;
   int bci = InvalidFrameStateBci;
-  verify_frame_kind(top_frame, pk, &m, &code_name, &bci);
+  verify_frame_kind(top_frame, pk, &m, &code_name, &bci, cont.tail());
   assert(m != nullptr && code_name != nullptr && bci != InvalidFrameStateBci, "should be set");

   ResourceMark rm(current);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433721003

From liach at openjdk.org  Wed Oct 15 20:33:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 20:33:54 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
 <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>
Message-ID: <Dh6PDPXaJp6JgE4_EqUZ74GZQkxySel5Pdz-P9C2-wc=.d338007e-cf64-40b1-bc43-5087c80eb5f4@github.com>

On Wed, 15 Oct 2025 17:49:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Serguei reviews
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:
> 
>> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
>> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
>> 94:                         // Defer dummy fields to defer their associated constant pool entries
> 
> Nit: This comment is kind of confusing. What does it mean: `defer dummy fields`? Do you mean `defer adding dummy fields to the class file`?

I have updated this to indicate this is to hold on to the related constant pool entries and add them to the end instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433861767

From valeriep at openjdk.org  Wed Oct 15 20:48:45 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 20:48:45 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <pR3Bq_Jp14q-QJIxyEnudtV63OVd_BMavZJRfeBQXuM=.6344bb6b-7263-4628-af4a-3d1ed39f05fa@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:

> 918:             if (prevKey != null) {
> 919:                 Arrays.fill(prevKey, (byte) 0);
> 920:             }

Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433898660

From duke at openjdk.org  Wed Oct 15 21:31:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 21:31:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
Message-ID: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>

On Wed, 15 Oct 2025 17:54:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:
> 
>> 51:     public void setup() throws Exception {
>> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
>> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});
> 
> Is the all-0s IV intentional?

Yes, it's in keeping with the other benchmarks (e.g., test/micro/org/openjdk/bench/javax/crypto/AES.java).

> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
> 
>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>> 81:         return cipher.doFinal(ct);
>> 82:     }
> 
> These 3 methods look same to me except for the method names?

The forked arguments will test different levels of optimizations:
testBaseline: no optimizations
testUseAes: AES optimizations
testUseAesIntrinsics: AES machine instructions

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434006387
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434001817

From sspitsyn at openjdk.org  Wed Oct 15 21:49:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 21:49:20 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <HN_LsCjlBTXOdPYZvur9Z6G7EC6297Gey3et5KDqTN0=.f102b681-75cc-4f76-8c6e-c1b657329488@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Thank you for the updates! I'm okay with the fix assuming it was verified with the mach5 tiers 1-6.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3342461284

From duke at openjdk.org  Wed Oct 15 23:04:10 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/3fc25aef..f48160cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=03-04

  Stats: 31 lines in 1 file changed: 6 ins; 10 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Wed Oct 15 23:04:11 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
Message-ID: <ExNTY6lbqeXpuYF1Eo_wd0s0fKZ7wgq5OyQ57Ux3ja8=.44937ab1-2c2f-4ef5-a3ba-e33ca56f0950@github.com>

On Wed, 15 Oct 2025 17:55:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AES_Crypt extends SymmetricCipher {
> 
> This internal class does not need to be public? I'd assume it's only used within the same package?

You're right, it doesn't appear to be used externally.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:
> 
>> 918:             if (prevKey != null) {
>> 919:                 Arrays.fill(prevKey, (byte) 0);
>> 920:             }
> 
> Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

It can be and I agree.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164829
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434165068

From duke at openjdk.org  Wed Oct 15 23:04:13 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
 <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
Message-ID: <Tv0ojGuZQ_ououiASu5P4XEucY8dOVh3147dIjXVOdE=.cea0db2b-7bfa-4c4a-9dbf-03fce792d5b7@github.com>

On Wed, 15 Oct 2025 18:51:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
>> 
>>> 53: 
>>> 54:     private static final int AES_256_ROUNDS = 14;
>>> 55:     private static final int AES_256_NKEYS = 32;
>> 
>> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?
>
> Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

I've made the update that references the AESConstants to avoid duplication.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164972

From valeriep at openjdk.org  Wed Oct 15 23:31:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 23:31:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
 <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
Message-ID: <-4wxYGqcPRXJYZEXd91_MPCBd491IFjd7TOnMP_HdxE=.060bb090-1084-4a3b-8315-2116e73e69df@github.com>

On Wed, 15 Oct 2025 21:26:33 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
>> 
>>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>>> 81:         return cipher.doFinal(ct);
>>> 82:     }
>> 
>> These 3 methods look same to me except for the method names?
>
> The forked arguments will test different levels of optimizations:
> testBaseline: no optimizations
> testUseAes: AES optimizations
> testUseAesIntrinsics: AES machine instructions

Ah, I see, some has "+" vs some uses "-". My eye sights are getting worse. (sigh)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434206251

From jrose at openjdk.org  Thu Oct 16 00:18:06 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 16 Oct 2025 00:18:06 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v3]
In-Reply-To: <yHYm5xCFMriiNOPbCUg77EpsRlse1TjArvREZopD2vU=.bf587fc8-e1c4-41f5-9d53-58cf3ab08fc4@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <yHYm5xCFMriiNOPbCUg77EpsRlse1TjArvREZopD2vU=.bf587fc8-e1c4-41f5-9d53-58cf3ab08fc4@github.com>
Message-ID: <xLnwRHXMPitTBfdn5GB52nIcEQkCnP5vP6MDnzoq_-4=.ac5df860-035d-4b97-9665-2a0af1c40241@github.com>

On Wed, 15 Oct 2025 02:37:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds the type Atomic<T>, to use as the type
>> of a variable that is accessed (including writes) concurrently by multiple
>> threads. This is intended to replace (most) uses of the current HotSpot idiom
>> of declaring a variable volatile and accessing that variable using functions
>> from the AtomicAccess class.
>> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
>> 
>> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
>> 
>> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
>> operationally the same, with the same API, hence uses and gtests didn't need
>> to change in that respect. Thanks to @stefank for raising this issue, and for
>> some suggestions toward improvements.
>> 
>> * Changed how fetch_then_set for atomic translated types is handled, to avoid
>> having the function there at all if it isn't usable, rather than just removing
>> it via SFINAE, leaving an empty overload set.
>> 
>> * Added more gtests.
>> 
>> Testing: mach5 tier1-6, GHA sanity tests
>
> 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into atomic-template-tag-select
>  - Merge branch 'master' into atomic-template-tag-select
>  - add reference to gcc bug we're working around
>  - fix typo in comment
>  - update copyrights
>  - update FreeListAllocator
>  - update nonblockingQueue
>  - update LockFreeStack
>  - convert StringDedupTable
>  - convert SingleWriterSynchronizer
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1ac20fc3...67616416

My overall reaction is:  Yes, please, thank you Kim.  (I might have been one of the people who asked for this.)  Since we are using C++, of course we should tie together special data with special operations (in a class with non-static members), rather than relying on the mysteries of "volatile" hooking into an all-static API.

I'm glad we seem to be steering towards names and notations which are easier to learn, and also lead to code which is easier to read and reason about.  We have a code base which will live the better part of a century, which means code will be read many more times than written.

(And we shouldn't just use C++ atomics wholesale, because Java and HotSpot are extremely opinionated about concurrent memory access, down to the hardware level.  We need to set our own defaults and notations to dispel the bugs that are specific to our platform.)

So, I have run into "relaxed" and "opaque" many times in various related APIs.  (I remember RMO from SPARC days.)
I have been found both words hard to relate to the problems at hand, although I understand how they came about.
The arguments above against "relaxed" (at least two of them) seem to me worth considering.

I like Kim's suggestion of "unordered", meaning "no fences on this one".  ("Unfenced" also occurred to me FWIW.)
The bare names "load" and "store" are (by consensus) not explicit enough, and so we can't just drop the "fence modifier" from the function name.  Rather, we need a term which says in effect, "you were maybe expecting RELEASE-STORE, but there's no RELEASE, so it's just a a STORE; and that's why we call it UNORDERED-STORE".  (Or opaque or relaxed or unfenced or regular or whatever.)

Just my $0.02 on that naming point.  I will certainly defer to people who are working full time on the code base.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3408701008

From valeriep at openjdk.org  Thu Oct 16 00:21:12 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:21:12 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:

> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
> 895:             rounds = AES_128_ROUNDS;
> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;

Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434256434

From valeriep at openjdk.org  Thu Oct 16 00:42:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:42:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:

> 952:             }
> 953:             w[i] = w[i - nk] ^ tmp;
> 954:         }

Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
Same goes for the `i * WB` value from line 937-940

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434276514

From valeriep at openjdk.org  Thu Oct 16 00:45:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:45:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
Message-ID: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>

On Thu, 16 Oct 2025 00:38:09 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
> 
>> 952:             }
>> 953:             w[i] = w[i - nk] ^ tmp;
>> 954:         }
> 
> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
> Same goes for the `i * WB` value from line 937-940

On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434280527

From valeriep at openjdk.org  Thu Oct 16 00:51:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:51:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <Yi-i_G6rzZSf--f5B98FDZmpxH-hziNwnrw71ap4KbE=.987c1c0b-5184-40f2-82fa-54622f850943@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434286447

From valeriep at openjdk.org  Thu Oct 16 00:54:10 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:54:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <w6vLcHWKA1qYfAWNSHroBPE9koyKrHgcLtJLkYSCfPc=.8f1ce350-5856-4668-a3a5-8052e351d3a2@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

This method can be static?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434289681

From iklam at openjdk.org  Thu Oct 16 01:36:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 01:36:08 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
Message-ID: <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>

On Wed, 15 Oct 2025 15:20:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Dont print error message when there are no archived objects
>  - Fix issue in new test
>  - Change is_aot_thread implementation
>  - update AotJdk problem lists

Hi Eric, looks very good overall.

I have gone through some of the code and have some comments. More to come.

src/hotspot/share/cds/cds_globals.hpp line 79:

> 77:           "the CDS archive, in the specified file")                         \
> 78:                                                                             \
> 79:   product(bool, AOTStreamableObjects, true,                                 \

The default should be `false`, as that will be the mode that the user will get with no GC options are specified.

src/hotspot/share/cds/heapShared.cpp line 355:

> 353: }
> 354: 
> 355: bool HeapShared::is_loading_mapping_mode() {

I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.

Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:

- _is_loading_heap
- _is_loading_heap_streaming_mode

The first boolean is the main switch, but most of the code will be checking only the second boolean.

src/hotspot/share/cds/heapShared.cpp line 410:

> 408:       FLAG_SET_ERGO(AOTStreamableObjects, true);
> 409:       _heap_write_mode = HeapArchiveMode::_streaming;
> 410:       return;

This should be changed to `if (!UseZGC) {`, as all other GCs support writing the "mapping" format.

src/hotspot/share/cds/heapShared.cpp line 418:

> 416: 
> 417:   // Select default mode
> 418:   if (UseG1GC && UseCompressedOops) {

This is different than specified in JEP 516. The condition should be `if (UseCompressedOops)`.

test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 117:

> 115:                               small2,
> 116:                               coops,
> 117:                               "-XX:-AOTStreamableObjects",

Is this change necessary?

test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 147:

> 145:             // Regardless of which GC dumped the heap, there will be an object archive, either
> 146:             // created with mapping if dumped with G1, or streaming if dumped with serial GC.
> 147:             // At exec time, try to load them into a small SerialGC heap that may be too small.

Actually the original check of `dumpWithSerial == false` was obsolete, as SerialGC can also dump heap objects.  `dumpWithSerial == false` should be removed. The first two lines of comments should also be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3342741298
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434315273
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434294269
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434328432
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434316323
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434295055
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2434331254

From lmesnik at openjdk.org  Thu Oct 16 02:00:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:00:34 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from ProblemList-Virtual, 
 use requires instead
Message-ID: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>

The problemlist entries for incompatible tests are replaced with requires tag.
Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.

Tested by running these tests with virtual test tthread factory.

-------------

Commit messages:
 - copyrights updated
 - the jdk part
 - the hotspot part

Changes: https://git.openjdk.org/jdk/pull/27834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27834&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348844
  Stats: 61 lines in 16 files changed: 15 ins; 33 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27834/head:pull/27834

PR: https://git.openjdk.org/jdk/pull/27834

From lmesnik at openjdk.org  Thu Oct 16 02:09:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:09:46 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
Message-ID: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - copyrights updated
 - more tests removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27834/files
  - new: https://git.openjdk.org/jdk/pull/27834/files/2c882158..eafa8d21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27834&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27834&range=00-01

  Stats: 11 lines in 5 files changed: 2 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27834/head:pull/27834

PR: https://git.openjdk.org/jdk/pull/27834

From dholmes at openjdk.org  Thu Oct 16 02:29:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 02:29:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Seems reasonable.

Would be good to know why some tests have stopped failing though.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3342855898

From dlong at openjdk.org  Thu Oct 16 02:39:04 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 16 Oct 2025 02:39:04 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
Message-ID: <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>

On Sat, 11 Oct 2025 18:25:48 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update foundOne

src/hotspot/share/code/nmethod.cpp line 2599:

> 2597: // nmethods that don't seem to be all that relevant any longer.
> 2598: bool nmethod::is_cold() {
> 2599:   if (!MethodFlushing || (is_native_method() && is_in_use()) || is_not_installed()) {

So I guess we need to decide what to do about native wrappers that are still "in use", but are "cold" because they haven't been called in a while.  The above change would keep them around forever.  We could instead allow them to be cleaned up like regular nmethods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2434399527

From lmesnik at openjdk.org  Thu Oct 16 02:43:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:43:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
Message-ID: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>

On Thu, 16 Oct 2025 02:26:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems reasonable.
> 
> Would be good to know why some tests have stopped failing though.
> 
> Thanks
Thank you for reveiw.
For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3408951683

From wenanjian at openjdk.org  Thu Oct 16 02:53:36 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Thu, 16 Oct 2025 02:53:36 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v7]
In-Reply-To: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
Message-ID: <9LF0mPPgOWE4Ts4WMoRnoo5Bdq5C1p9u5H-P0iBJFgw=.72f9eb2a-8468-4e76-820a-9c29a9c97197@github.com>

> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  move the use of UseUnalignedAccesses flag after it properly assigned.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27510/files
  - new: https://git.openjdk.org/jdk/pull/27510/files/6eb1dd95..bdb18ae6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27510&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27510&range=05-06

  Stats: 16 lines in 2 files changed: 7 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27510/head:pull/27510

PR: https://git.openjdk.org/jdk/pull/27510

From asmehra at openjdk.org  Thu Oct 16 03:13:03 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 16 Oct 2025 03:13:03 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions
In-Reply-To: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
Message-ID: <w8e_eBQAu6dY6g24L5QYBkkZFTK9yhT3WgasCTgB5qw=.3cdf9d7c-4cc6-4126-a9ab-e571770e7a4e@github.com>

On Mon, 6 Oct 2025 15:14:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
> 
> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.

Marked as reviewed by asmehra (Committer).

This looks good to me.
I just want to note that with this patch the two parameter version of `MacroAssembler::target_addr_for_insn` is not needed anymore. So there is scope for a bit more cleanup of the dead code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27649#pullrequestreview-3342912347
PR Comment: https://git.openjdk.org/jdk/pull/27649#issuecomment-3408998188

From iklam at openjdk.org  Thu Oct 16 03:32:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 03:32:40 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v2]
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <DqXJhqYfXBS9xJewd3AAWVr621iOWTyVppkcE8IXoOk=.c80857a1-ce3c-42ca-ad53-2c3c72c549e4@github.com>

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @vnkozlov review -- updated comments; also added NO_CDS_RETURN

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27783/files
  - new: https://git.openjdk.org/jdk/pull/27783/files/2f164e58..1f3f9d44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27783/head:pull/27783

PR: https://git.openjdk.org/jdk/pull/27783

From iklam at openjdk.org  Thu Oct 16 03:56:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 03:56:49 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v3]
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <ozdlolzPMKpWpzqV0f9pPdyChsfG6gHQCoEjPrLG82I=.69f6d217-d7e2-4090-a8e8-debc86104619@github.com>

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @vnkozlov comment - move delay nmethod event posting to nmethod.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27783/files
  - new: https://git.openjdk.org/jdk/pull/27783/files/1f3f9d44..a3923263

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=01-02

  Stats: 83 lines in 6 files changed: 44 ins; 37 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27783/head:pull/27783

PR: https://git.openjdk.org/jdk/pull/27783

From iklam at openjdk.org  Thu Oct 16 03:56:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 03:56:49 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v3]
In-Reply-To: <q4T04AWD85-d2VcH4XGVGqx58Lj3hys28gTNAkFGa3E=.23a94b4b-8c1f-4c5b-8582-59f0a4a1eeed@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <6O1YIclHxYSabUijnozdlGYxH8Oix1fUitciLeeW0M4=.f8c73353-e471-4932-ba63-71d1381cc670@github.com>
 <q4T04AWD85-d2VcH4XGVGqx58Lj3hys28gTNAkFGa3E=.23a94b4b-8c1f-4c5b-8582-59f0a4a1eeed@github.com>
Message-ID: <hcFDhv8Y_Q4ONSNnn1-SU3qP3Vhz38E3f5OI_T5rGWc=.d5312a17-849f-4fcd-9e53-ac75e84db825@github.com>

On Wed, 15 Oct 2025 18:06:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 350:
>> 
>>> 348: // With AOT-linked classes, we could compile nmethods before the ServiceThread
>>> 349: // has been started, so we must delay the events to be posted later.
>>> 350: void AOTLinkedClassBulkLoader::add_delayed_compiled_method_load_event(nmethod* nm) {
>> 
>> I don't think it should be done in `AOTLinkedClassBulkLoader`.  Please move it to `nmethod.*` files
>
> This only affects native wrappers as I understand which are generated by Shared runtime. JIT compilers are not initialized yet.  May be update comment to be clear: "With AOT-linked classes, we could compile wrappers for native methods before the ServiceThread"

I moved the code into nmethod.cpp. I originally thought that there might be other events that need to be handled similarly, so aotLinkedClassBulkLoader.cpp seemed to be a good central place to do that.

However, after looking at all uses of `ServiceThread::enqueue_deferred_event()`, this seems to be the only cases that needs special handling. So nmethod.cpp is a good place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2434485324

From duke at openjdk.org  Thu Oct 16 04:04:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v6]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <D10CYOe7aMVvFnVLVSIC24rkS5X9Bn2ieVJzLhZGyp0=.f302f432-567b-4531-afe4-c93142842180@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/f48160cf..fbf2117f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=04-05

  Stats: 28 lines in 1 file changed: 1 ins; 10 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Thu Oct 16 04:04:25 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:25 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
Message-ID: <yHo_j7EhetLMz1IanELnanT28tBeCLmJaqVUgLxkBHc=.e74d74a3-1217-44fa-a5c8-e783cf46ada9@github.com>

On Thu, 16 Oct 2025 00:18:08 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:
> 
>> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
>> 895:             rounds = AES_128_ROUNDS;
>> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;
> 
> Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

Sounds reasonable.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

Actually I used Stallings' cryptography book specifically for the round key concepts, hence the variable name mismatch at least for 128 bit keys.  But after your suggestions is does look more like FIPS 192-upd 1 so I will reference the section ;)  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> This method can be static if you pass the `rounds` value as a method argument.

Yes and subWord() would also need to be static for this change.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497086
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497821
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434498001

From duke at openjdk.org  Thu Oct 16 04:04:27 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:27 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
 <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
Message-ID: <pa0LOr36bCeDYO7IvgvJ3drt327DMt4q8hyoXqnA5xI=.824d2138-c29d-4288-97a3-f50d9561bb44@github.com>

On Thu, 16 Oct 2025 00:42:20 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
>> 
>>> 952:             }
>>> 953:             w[i] = w[i - nk] ^ tmp;
>>> 954:         }
>> 
>> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
>> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
>> Same goes for the `i * WB` value from line 937-940
>
> On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

I've made these changes and used the 2nd approach for indexing key.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497439

From valeriep at openjdk.org  Thu Oct 16 04:52:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 04:52:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:

> 1030:      * @return the substituted word.
> 1031:      */
> 1032:     private int subByte(int state, byte[][] sub) {

Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434562796

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/fbf2117f..9f00c355

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=05-06

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>
Message-ID: <hKfLGz8VD8L74v1tnU6dKb_qBAhjU3zfbMxg_hFuc2A=.6f6a4d6a-a9f8-4ba4-a3b7-9e2b827cf015@github.com>

On Thu, 16 Oct 2025 04:49:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:
> 
>> 1030:      * @return the substituted word.
>> 1031:      */
>> 1032:     private int subByte(int state, byte[][] sub) {
> 
> Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
> This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
> nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

Good, it was a byte operation, but evolved to a word.
Last commit made it a static.
Yes, before I switched over to a LUT for the inverse mix column transform of the inverse key expansion it needed both, but doesn't anymore.
I'll switch from state to word then.
Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434594049

From alanb at openjdk.org  Thu Oct 16 05:35:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:35:03 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <kDmJ5o4QFqg8obNyDv-h2iRgOsEO1sOc0ylwJo8_pOQ=.ebc36fa0-13ca-40ab-8fd8-d80038bd9025@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

@lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409239412

From alanb at openjdk.org  Thu Oct 16 05:39:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:39:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <tTDpaMj7Jf8SLq4VToanf2gdX2jb6h8brmQxt6EqBPQ=.f4776444-7404-42d7-85a2-22936ee6ef88@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

Right, virtual threads did not capture the caller context (inherited AccessControlContext) and had no permissions when executing code that performed a privileged action. This is why some of the pre-existing tests that ran with a security manager couldn't run with JTREG_TEST_THREAD_FACTORY=Virtual.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409247117

From qamai at openjdk.org  Thu Oct 16 05:54:03 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 16 Oct 2025 05:54:03 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v3]
In-Reply-To: <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
 <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
 <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
Message-ID: <-VnYQl_DQoP7Ux6TaM08X5OuJsKSVCvuVXQm2cOe9Fg=.239a6a09-b6dd-4dac-b432-42c28015769e@github.com>

On Sat, 4 Oct 2025 01:07:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> release_store() is roughly like release(); store();

This would not be a good reason. A release store is not a release fence followed by a store, it only implies a happen-before relationship between itself and the acquire load that observes it. This means that a release store will act as if it is a plain store if the memory is not shared. Another way to look at it is that we invent the term "release_store" which is a release fence followed by a store, this is also not ideal because we are inventing a new definition of an existing term that is different from the existing definition in a subtle way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3409276449

From lmesnik at openjdk.org  Thu Oct 16 05:57:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 05:57:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

> @lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

I am going to mark with requires all incompatible tests. There are some tests that manually check if virtual thread is enabled and the tests that already have virtual thread cases. I'll clean up them later.

However, the ProblemList-Virtual  will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.
 The
`@requires test.thread.factory == null` 
means that test is incompatible with thread factory and unlikely is going to be fixed for this mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409283143

From alanb at openjdk.org  Thu Oct 16 06:06:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <B5m3Q1-vChX60xoKrHh0wpiSRZ1CA6ojSpsPtUFfs1E=.9d20fe9e-1479-4b24-94a1-e3d331116dd9@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343180403

From alanb at openjdk.org  Thu Oct 16 06:06:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
 <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>
Message-ID: <7DwLsAuTCiYYr6lPN9vlLT8SzjWMRoHphbFDuLQjenU=.8296b6bd-8460-440c-a4c8-daf3dfd49325@github.com>

On Thu, 16 Oct 2025 05:54:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> However, the ProblemList-Virtual will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.

Thanks for the clarification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409309033

From tschatzl at openjdk.org  Thu Oct 16 06:26:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 16 Oct 2025 06:26:03 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v3]
In-Reply-To: <xLnwRHXMPitTBfdn5GB52nIcEQkCnP5vP6MDnzoq_-4=.ac5df860-035d-4b97-9665-2a0af1c40241@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <yHYm5xCFMriiNOPbCUg77EpsRlse1TjArvREZopD2vU=.bf587fc8-e1c4-41f5-9d53-58cf3ab08fc4@github.com>
 <xLnwRHXMPitTBfdn5GB52nIcEQkCnP5vP6MDnzoq_-4=.ac5df860-035d-4b97-9665-2a0af1c40241@github.com>
Message-ID: <f6PF5IijEPPDxGiwcRaIckzgAcDa58eZ1lhInYq1sB8=.5b3b54cd-339b-4693-a1c6-8eff4c493a96@github.com>

On Thu, 16 Oct 2025 00:15:36 GMT, John R Rose <jrose at openjdk.org> wrote:

> I like Kim's suggestion of "unordered", meaning "no fences on this one". ("Unfenced" also occurred to me FWIW.)
> The bare names "load" and "store" are (by consensus) not explicit enough, and so we can't just drop the "fence modifier" from the function name. Rather, we need a term which says in effect, "you were maybe expecting RELEASE-STORE, but there's no RELEASE, so it's just a a STORE; and that's why we call it UNORDERED-STORE". (Or opaque or relaxed or unfenced or regular or whatever.)

+1 for `unordered`. Seems to be most clear and self-explaining to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3409352343

From syan at openjdk.org  Thu Oct 16 06:27:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Oct 2025 06:27:02 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <wszw7ZYo4T6lwhiwAv4C9eh5Ls-5DCMVmb35M5QGA8E=.934bce79-35f7-4a58-9599-1aa3b5406b74@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343230765

From dholmes at openjdk.org  Thu Oct 16 07:09:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 07:09:04 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v3]
In-Reply-To: <-VnYQl_DQoP7Ux6TaM08X5OuJsKSVCvuVXQm2cOe9Fg=.239a6a09-b6dd-4dac-b432-42c28015769e@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <uxG7_7zhOiRQh87wQgX4sDSK7maqpwI-rxOD6sgbZOQ=.a5dafcb9-56e1-4ca2-843a-1c2cb3e80258@github.com>
 <ynqWL2IA2kXVSH7OEubzx7DvoXpuGYV0lRm2IphWhms=.884f4fad-2183-40ac-8c28-f9b37c5a2b62@github.com>
 <hZmZ2OnF5XgxhwfYriFaKnxu3qqkLC2hlANQ4OkgJaY=.1f2455f9-b245-4c92-b29a-b05a622825cc@github.com>
 <ZrdQuKMacLUJYWDyQZ_mctN_oPZqFKe6EsM4W5qnRaM=.a81eb2a2-d123-496f-90e1-3673705498e4@github.com>
 <pmYUaEWxmCWPfCnPxYP9FCttDPp1junc372smAMNNTY=.f9340c68-1ae1-43b3-946b-f337cb171ee6@github.com>
 <COhVpVm8h4eVgI-sQYCc8eS_IqP-_6z745mv1cS456A=.8d365719-599e-4d2c-b3a7-d7d5c80490ed@github.com>
 <-VnYQl_DQoP7Ux6TaM08X5OuJsKSVCvuVXQm2cOe9Fg=.239a6a09-b6dd-4dac-b432-42c28015769e@github.com>
Message-ID: <TOq6uvW9iFrzHtpd5j7dtqr7d5hPO8KeP9selmwsCU4=.f0afb4db-c50e-4796-833a-724e1586f7e4@github.com>

On Thu, 16 Oct 2025 05:50:57 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > release_store() is roughly like release(); store();
> 
> This would not be a good reason. A release store is not a release fence followed by a store, it only implies a happen-before relationship between itself and the acquire load that observes it. This means that a release store will act as if it is a plain store if the memory is not shared. Another way to look at it is that we invent the term "release_store" which is a release fence followed by a store, this is also not ideal because we are inventing a new definition of an existing term that is different from the existing definition in a subtle way.

No we are not inventing something new - this already exists for a long time in Hotspot. Please see orderAccess.hpp

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3409472645

From rrich at openjdk.org  Thu Oct 16 07:18:11 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Oct 2025 07:18:11 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <h3n6l-iaeBBg-n2xDlHHb68PTO9BDJwy_Tp3rwxGjLU=.b6285e20-71cd-401c-b3a6-9c68b9893efd@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
 <Avv9PuWx1yWbVWOCtQswTv76NlctLw41UfhH2J_lLfU=.c995d998-df8c-4ec4-843a-68dffcbf6bb2@github.com>
 <h3n6l-iaeBBg-n2xDlHHb68PTO9BDJwy_Tp3rwxGjLU=.b6285e20-71cd-401c-b3a6-9c68b9893efd@github.com>
Message-ID: <Rj22ZFVQGHj-fAxKNGVyenbBfBRLK6ohHAC-stt7Rcw=.756f9248-132f-4a89-92e1-8db4cce36902@github.com>

On Wed, 15 Oct 2025 19:33:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751:
>> 
>>> 1749:                   RegisterMap::ProcessFrames::skip,
>>> 1750:                   RegisterMap::WalkContinuation::skip);
>>> 1751:       frame fr = top.sender(&reg_map);
>> 
>> I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`.
>> 
>> I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap.
>> 
>> It's not quite easy to fix though since `top` can also be on stack.
>
> Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?
> 
> 
> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> index 86c56fe583f..fb1f66c60f4 100644
> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
>  static void log_frames(JavaThread* thread, bool dolog = true);
>  static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
>  static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);
> 
>  #define assert_pfl(p, ...) \
>  do {                                           \
> @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
>    return true;
>  }
> 
> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
>    Method* m;
>    const char* code_name;
>    int bci;
> @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
>        RegisterMap reg_map(current,
>                    RegisterMap::UpdateMap::skip,
>                    RegisterMap::ProcessFrames::skip,
> -                  RegisterMap::WalkContinuation::skip);
> +                  RegisterMap::WalkContinuation::include);
> +      if (top.is_heap_frame()) {
> +        assert(chunk != nullptr, "");
> +        reg_map.set_stack_chunk(chunk);
> +        top = chunk->relativize(top);
> +        top.set_frame_index(0);
> +      }
>        frame fr = top.sender(&reg_map);
>        vframe*  vf  = vframe::new_vframe(&fr, &reg_map, current);
>        compiledVFrame* cvf = compiledVFrame::cast(vf);
> @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) {
>    Method* m = nullptr;
>    const char* code_name = nu...

Your patch fixes the issue. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2434828305

From epeter at openjdk.org  Thu Oct 16 07:21:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 16 Oct 2025 07:21:07 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v6]
In-Reply-To: <jqyEnHmReYSIkeKgzS-0AoKLeoWKoHJvA1qiOnlAsqA=.a77a5e99-202d-4994-b06d-dde2934845f8@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <jqyEnHmReYSIkeKgzS-0AoKLeoWKoHJvA1qiOnlAsqA=.a77a5e99-202d-4994-b06d-dde2934845f8@github.com>
Message-ID: <aIQcF9w8b8muG3XfBSk3WP4SHYKNhKnZZr9scelX18E=.33d3d7ad-48bf-479f-98ef-b028f532476d@github.com>

On Tue, 14 Oct 2025 11:59:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change refactor code that's similar for LShiftINode and
>> LShiftLNode into shared methods. I also added extra test cases to
>> cover all transformations.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Testing passed -> approved ? 

Thanks for the work @rwestrel !

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27725#pullrequestreview-3343391826

From roland at openjdk.org  Thu Oct 16 07:26:26 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 16 Oct 2025 07:26:26 GMT
Subject: RFR: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal [v2]
In-Reply-To: <ZmIx7WhOfwoZDhVodTtWYz0vVExfDWLyid0kS7AASKU=.638fc1a9-9285-4877-a147-d6def1225273@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
 <U13h8Ysi1Z-b6uWpKAJ9ybERRvuHGjkJEn3tZZoDDEQ=.9664eddb-8e45-40d3-8bfa-dd9f2c74ff95@github.com>
 <QENriVylwLRHp05UlYy-YA2kyqrfVNJcGgOHAR6IyTA=.f26a6227-bb3c-4e62-9aac-6f170f0c4d05@github.com>
 <gW0LvUknSvsYrYfi6ARSEeT_vjKzgv0AOtP7ULNHKwM=.0f6a165e-0fc7-4d82-be90-0755f9608792@github.com>
 <ZmIx7WhOfwoZDhVodTtWYz0vVExfDWLyid0kS7AASKU=.638fc1a9-9285-4877-a147-d6def1225273@github.com>
Message-ID: <8wMmXdDYSsHL7olSC92AmkyXDEEXCMZgGAJO4tRQwPQ=.3475c9c8-f18e-4b8c-9fed-806e5b318ee5@github.com>

On Tue, 14 Oct 2025 09:19:33 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>>> An idea (not a suggestion, just something that crossed my mind, take it more as a thought experiment): we could also parametrize everything not with a `BasicType` parameter but a template parameter (since `IdealIL` and co are invoked with literal values). It wouldn't change much, but for instance it would allow to replace the assert in `java_shift_left` and friends with static checks (I have a bias toward static checks).
>> 
>> I wondered about that too. There are many more methods that are parameterized by a `BasicType`. They would have to all go through that transition.
>
>> They would have to all go through that transition.
> 
> For consistency yes. But yet, I think I recall some functions that are not called with a compile-time constant, so we can't do that everywhere. Technically, calling a function that takes it as parameter from the templated version, and just passing our template argument is fine. What is not (easily) possible is normal parameter -> template. But again, that was just "for fun".

@marc-chevalier @eme64 thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27725#issuecomment-3409531060

From roland at openjdk.org  Thu Oct 16 07:26:27 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 16 Oct 2025 07:26:27 GMT
Subject: Integrated: 8369167: C2: refactor LShiftINode/LShiftLNode
 Value/Identity/Ideal
In-Reply-To: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
References: <8uDjc9ZiSz2ecT3_fLcx2R21eIGBNyUSa7BvbkU_CCY=.d7552391-c42a-4de8-9577-dec5913048ff@github.com>
Message-ID: <QY8dcUWPSWxiFvXE7SR_ntoEBo04G-Vj2EXoq6eCBRM=.0e6179b2-8557-4931-a37a-157a7c64567c@github.com>

On Thu, 9 Oct 2025 13:16:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This change refactor code that's similar for LShiftINode and
> LShiftLNode into shared methods. I also added extra test cases to
> cover all transformations.

This pull request has now been integrated.

Changeset: 7fe06657
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fe066573004a525673e4ec55df6783b13bfc189
Stats:     616 lines in 6 files changed: 334 ins; 172 del; 110 mod

8369167: C2: refactor LShiftINode/LShiftLNode Value/Identity/Ideal

Reviewed-by: epeter, mchevalier

-------------

PR: https://git.openjdk.org/jdk/pull/27725

From dholmes at openjdk.org  Thu Oct 16 07:42:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 07:42:19 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
Message-ID: <tvm7WeykkWNGC8M4ssWhU77Zg0avhIxA1nJxLSt_6_Y=.3f1ff410-659b-4191-80bb-ba507578bba8@github.com>

On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore comment

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3343463795

From mli at openjdk.org  Thu Oct 16 08:13:24 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 08:13:24 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <38EnYU2ou3fnkZl47w2YKvr7mPFLibLozZznoVDxnO4=.53eb238f-2c91-45db-9c8e-41e7e16b7213@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <38EnYU2ou3fnkZl47w2YKvr7mPFLibLozZznoVDxnO4=.53eb238f-2c91-45db-9c8e-41e7e16b7213@github.com>
Message-ID: <lT-E7ukAQz0vIKdWca1B-FXAcn7RL81aoc5lP8PCQKY=.169de568-0cfd-45f9-b212-1cdaf10d0e20@github.com>

On Wed, 15 Oct 2025 08:42:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> @RealFYang 
>> 
>> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
>> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
>> And also do some simple refactoring related to enable/disable/enabled and so on.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Hey @RealFYang @robehn Can you have another look? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27771#issuecomment-3409712634

From fandreuzzi at openjdk.org  Thu Oct 16 08:15:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 08:15:32 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
 <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
 <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>
Message-ID: <Jkvi_lJ3fKUn0-C7I29xXCKgbUR2w7nz-0GdYr2umsg=.642d5c9d-4a89-43e1-96f7-a6c5c4e14290@github.com>

On Wed, 15 Oct 2025 17:36:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?
>
>> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?
> 
> It is because minimal does not include JVMTI.
> A tweak is needed in `jvmtiExport.hpp` at line 383 to follow other functions returning `void`:
>   `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN`

Thanks for the review @sspitsyn and @dholmes-ora.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409720063

From duke at openjdk.org  Thu Oct 16 08:15:35 2025
From: duke at openjdk.org (duke)
Date: Thu, 16 Oct 2025 08:15:35 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
Message-ID: <mT2NHodFLytJj4gXKu01DauHf2HUQa84uRUd7OI9rrU=.95de2f86-fb65-4d19-b787-6114413b99fe@github.com>

On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore comment

@fandreuz 
Your change (at version 378174203615473d5216cc67fbde50933c3c1c87) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409722637

From fandreuzzi at openjdk.org  Thu Oct 16 08:20:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 08:20:47 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <gYU0cTn8WA4qju9TcHFs0eJZyTotnmp38b1l_-_C_wo=.4b4f6314-4b62-4d6c-b441-39c0528077c5@github.com>

On Tue, 14 Oct 2025 12:49:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3343613146

From dholmes at openjdk.org  Thu Oct 16 08:32:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 08:32:17 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
Message-ID: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>

On Tue, 14 Oct 2025 08:17:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   summary

Generally looks good. Not 100% sure on the test structure but serviceability folk can chime in there if needed.

Suggestion:

diff --git a/src/jdk.jcmd/share/man/jcmd.md b/src/jdk.jcmd/share/man/jcmd.md
index 4e67e7a4502..69784050984 100644
--- a/src/jdk.jcmd/share/man/jcmd.md
+++ b/src/jdk.jcmd/share/man/jcmd.md
@@ -551,7 +551,7 @@ ## Commands for jcmd
     events, use `JFR.view all-events`.
 
 `JVMTI.agent_load` [*arguments*]
-:   Loads JVMTI native agent.
+:   Loads JVMTI native agent. (Live phase only)
 
     Impact: Low

src/hotspot/share/prims/jvmtiAgentList.cpp line 200:

> 198:                                 const char* options, outputStream* st) {
> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
> 200:     st->print_cr("Not in live phase");

Suggestion:

    st->print_cr("Dynamic agent loading is only permitted in the live phase");

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 45:

> 43:                 "-agentpath:" + Utils.TEST_NATIVE_PATH + File.separator + System.mapLibraryName("EarlyDynamicLoad"),
> 44:                 "-version");
> 45:         pb.environment().put("MODE", "jcmd");

This env-var seems unused

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 50:

> 48: 
> 49:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 50:         output.shouldHaveExitValue(0);

Yes but more importantly we should be checking for the "not in live phase" error message.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3343557488
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2434967688
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435031512
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435035321

From aph at openjdk.org  Thu Oct 16 09:08:13 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 09:08:13 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
Message-ID: <XF5SX-T1nEDC9RiJ3qwvw_2iGLhFbX75b3A3Hswglzg=.cedaab94-b09a-4273-bd07-65b41aa2f014@github.com>

On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into JDK-8369238
>  - RISC-V support
>  - Fix whitespaces
>  - v1

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209:

> 207:     // the last_sp saved in the frame (remove possible alignment added while
> 208:     // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp
> 209:     // saved in the frame as it is not expected to be set in case we preempt again.

A bit stronger?
Suggestion:

    // saved in the frame because it must be clear if we freeze again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2435147223

From rehn at openjdk.org  Thu Oct 16 10:01:50 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Oct 2025 10:01:50 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v2]
In-Reply-To: <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
Message-ID: <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>

On Wed, 15 Oct 2025 08:38:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:
>> 
>>> 158:       RVExtFeatures::current()->clear_feature(_cpu_feature_index);
>>> 159:     }
>>> 160:     int64_t value() { return enabled(); }
>> 
>> Seems redundant in functionality with `enabled()` for extension features. I think this `value()` method should only apply to non-extension features.
>
> Same as the above one. In `VM_Version::setup_cpu_available_features()`, we still need it.

automatically C style conversion between booleans and integer should be avoided.
(pointer to as bool strictly no no)

And I'm confused:
Disabled value == DEFAULT_VALUE (-1)
But enabled returns 0 or 1 convertet from bool?

{ return enabled() ? _what_value_here : DEFAULT_VALUE; } ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2435304826

From dbriemann at openjdk.org  Thu Oct 16 10:07:13 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Thu, 16 Oct 2025 10:07:13 GMT
Subject: RFR: 8369979: Flag UsePopCountInstruction was accidentally disabled on
 PPC64
Message-ID: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>

Reenables the flag UsePopCountInstruction for PPC in `src/hotspot/cpu/ppc/vm_version_ppc.cpp` to reactivate the support for popcount intrinsics on PPC.

-------------

Commit messages:
 - 8369979: Flag UsePopCountInstruction was accidentally disabled on PPC64

Changes: https://git.openjdk.org/jdk/pull/27843/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27843&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369979
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27843/head:pull/27843

PR: https://git.openjdk.org/jdk/pull/27843

From aph at openjdk.org  Thu Oct 16 10:19:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 10:19:08 GMT
Subject: RFR: 8369979: Flag UsePopCountInstruction was accidentally
 disabled on PPC64
In-Reply-To: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
References: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
Message-ID: <kf_4VvOCnUfQ1YaPotnS6mm6DBEFVEDUFxdZrlZv-s0=.0d7427e3-9c21-4a5d-a782-583765880070@github.com>

On Thu, 16 Oct 2025 10:01:13 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Reenables the flag UsePopCountInstruction for PPC in `src/hotspot/cpu/ppc/vm_version_ppc.cpp` to reactivate the support for popcount intrinsics on PPC.

Oops.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27843#pullrequestreview-3344075690

From mdoerr at openjdk.org  Thu Oct 16 10:21:56 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Oct 2025 10:21:56 GMT
Subject: RFR: 8369979: Flag UsePopCountInstruction was accidentally
 disabled on PPC64
In-Reply-To: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
References: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
Message-ID: <2m4QOlaTMVbMxDc7YcB-m2A-B-356Jo9f2aokpaFPho=.bc35450f-207d-48d8-9ac5-daf70741dc16@github.com>

On Thu, 16 Oct 2025 10:01:13 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Reenables the flag UsePopCountInstruction for PPC in `src/hotspot/cpu/ppc/vm_version_ppc.cpp` to reactivate the support for popcount intrinsics on PPC.

Thanks for repairing it!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27843#pullrequestreview-3344084661

From qpzhang at openjdk.org  Thu Oct 16 10:30:22 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Thu, 16 Oct 2025 10:30:22 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v5]
In-Reply-To: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
Message-ID: <yKfmUX8UXVxmlSqh29BvgOynizuMWsEGiHUDSjYsUXY=.53448522-c344-4449-b49a-8ce3b56458fd@github.com>

> Issue: 
> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check.
> 
> This PR:
> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled.
> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization.
> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. 
> 
> Tests:
> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected.
> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks.

Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Benchmark MacroAssembler::zero_words calls
  
  Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26917/files
  - new: https://git.openjdk.org/jdk/pull/26917/files/f23abb94..04a01dac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=03-04

  Stats: 88 lines in 1 file changed: 88 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917

PR: https://git.openjdk.org/jdk/pull/26917

From fandreuzzi at openjdk.org  Thu Oct 16 10:30:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 10:30:32 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v3]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gVvybIYNjKA6Bb_l8muhJWff7rTiupvMsLWj1bZM4vg=.bb3a8951-820b-4a1a-983e-e9e808d053a4@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/prims/jvmtiAgentList.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/49722e1b..84f168b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Thu Oct 16 11:12:37 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:12:37 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v4]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <W_GY_grNidBN10kxjNEMKVpMy3LFnZwcAd5safYp7vc=.2696e7d5-7a8c-4b29-b9fe-cd95aea6af3f@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nn

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/84f168b6..2e21bc3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Thu Oct 16 11:12:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:12:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
Message-ID: <V_N8NCUbRDEZ6KlbYAP4JMLgs5KJzTe8h6ozx-4zewo=.c30fd640-821b-42b8-8b72-7bddc6511bd2@github.com>

On Thu, 16 Oct 2025 08:26:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 45:
> 
>> 43:                 "-agentpath:" + Utils.TEST_NATIVE_PATH + File.separator + System.mapLibraryName("EarlyDynamicLoad"),
>> 44:                 "-version");
>> 45:         pb.environment().put("MODE", "jcmd");
> 
> This env-var seems unused

Thanks, that's a leftover from an old iteration: 2e21bc3f38404183bb0677980732ba1487d110d0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435496765

From qpzhang at openjdk.org  Thu Oct 16 11:17:34 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Thu, 16 Oct 2025 11:17:34 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v6]
In-Reply-To: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
Message-ID: <qziyH6Z-6OjHwz7xfkLb5qJIZO8X1fJDN3kua6nJqtk=.026dc585-6120-499f-8f0a-0e1d45d96e52@github.com>

> Issue: 
> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check.
> 
> This PR:
> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled.
> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization.
> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. 
> 
> Tests:
> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected.
> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks.

Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:

  fixed format string to %zu for size_t unsigned size type
  
  Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26917/files
  - new: https://git.openjdk.org/jdk/pull/26917/files/04a01dac..c748d218

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917

PR: https://git.openjdk.org/jdk/pull/26917

From fandreuzzi at openjdk.org  Thu Oct 16 11:46:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:46:48 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v5]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <w5wf_ekwaYyrPzDpU3SkytOPiy_h2Po1EpKukd0HI8o=.b56bc090-430d-44cb-a200-2b0c20cc7660@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  errno

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/2e21bc3f..e9646e68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=03-04

  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Thu Oct 16 11:57:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:57:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v6]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <ihMM18M_Zrx28lg9GT4ioqDArXAswLLuUcH5wP6vpck=.967549aa-5665-4d15-8a9a-e8115479049e@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  ops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/e9646e68..cbbbf8a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=04-05

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From aph at openjdk.org  Thu Oct 16 12:07:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 12:07:35 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v17]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <K_qneA2TP94_jHDa-s2XTP3PTMtFkM6DHnJHvI7B5Oc=.3475b917-c301-42a2-a080-57272ce1425b@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Check for working WX
 - Check for working WX

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/ea6f2a86..e1c6882a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=15-16

  Stats: 84 lines in 4 files changed: 64 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From aph at openjdk.org  Thu Oct 16 12:12:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 12:12:58 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v18]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <QBPj2qIaHENNErdCgADFt8JIT83A7J3M6stljMnZoIQ=.70c7d498-b0a4-404a-bdcd-6ff215f8507b@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Check for working WX

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/e1c6882a..c2d9049c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=16-17

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From luhenry at openjdk.org  Thu Oct 16 13:18:48 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 16 Oct 2025 13:18:48 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v5]
In-Reply-To: <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
Message-ID: <JQZM8Q3rcockhfR4nvxh1cnbLGvCxMvSGjL5rqI613g=.52ae57b7-1b50-4704-b4c6-c52ceb1132e1@github.com>

On Wed, 15 Oct 2025 08:17:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27572#pullrequestreview-3344799654

From jcking at openjdk.org  Thu Oct 16 13:44:45 2025
From: jcking at openjdk.org (Justin King)
Date: Thu, 16 Oct 2025 13:44:45 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v4]
In-Reply-To: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
Message-ID: <n72O_lX1Olq7_BkQZM8LursGApg5p5zAMQ2DHIt4O_o=.3b190fb0-a838-4289-ad71-719350df1c0a@github.com>

> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove std::is_trivially_default_constructible
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27801/files
  - new: https://git.openjdk.org/jdk/pull/27801/files/b5ee743c..d2030a3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27801&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27801/head:pull/27801

PR: https://git.openjdk.org/jdk/pull/27801

From jcking at openjdk.org  Thu Oct 16 13:44:47 2025
From: jcking at openjdk.org (Justin King)
Date: Thu, 16 Oct 2025 13:44:47 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]
In-Reply-To: <tZKx71hqVoA1GUI_YDChCvIql5_nHpYASHqorcsiUZo=.a1dfc22b-7378-4b3b-a265-319f78a74ee8@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <Uxiv8OIG0FUPKmCmHa7v1XLJVNITEm71j3fyOAp89tk=.a41a9cd5-e6ee-4e7c-bac1-c86023018b6c@github.com>
 <LtFuFOIgX3jj6c-J2dXYma_0BB627rsQHa4h2eIlRSg=.14f617a8-ff30-4217-b9a1-aea4cd377344@github.com>
 <hR0BdgBPqubbS3L71_mkylcelI0PZPO1l7ZcP1zASvo=.596fe639-7a0a-4fe4-813f-30449f3f3828@github.com>
 <tZKx71hqVoA1GUI_YDChCvIql5_nHpYASHqorcsiUZo=.a1dfc22b-7378-4b3b-a265-319f78a74ee8@github.com>
Message-ID: <U6EfUwkkt7m9XvxXwnK-SPeQKAdbnZMJ8u0lue2ZJCo=.fd2bcec2-ea47-4bd7-8c2c-b1b29b750d77@github.com>

On Wed, 15 Oct 2025 17:33:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is more just for language correctness, in case somebody tries to use this with a class or struct that is non-trivial.
>
> I agree the `std::is_trivially_copyable` test should be there.
> It's the `std::is_trivially_default_constructible` test that I'm questioning. I don't see anything in this code
> that has that as a requirement. So I find it confusing.

I think `std::is_trivially_copyable` should be enough, on second look. Removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2435958855

From mli at openjdk.org  Thu Oct 16 14:03:10 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 14:03:10 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v3]
In-Reply-To: <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
Message-ID: <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>

On Thu, 16 Oct 2025 09:58:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Same as the above one. In `VM_Version::setup_cpu_available_features()`, we still need it.
>
> automatically C style conversion between booleans and integer should be avoided.
> (pointer to as bool strictly no no)
> 
> And I'm confused:
> Disabled value == DEFAULT_VALUE (-1)
> But enabled returns 0 or 1 convertet from bool?
> 
> { return enabled() ? _what_value_here : DEFAULT_VALUE; } ?

@robehn Thanks for the offline discussion!
It makes sense to me to use DEFAULT_VALUE in `RVExtFeatureValue::value()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2436040024

From mli at openjdk.org  Thu Oct 16 14:03:10 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 14:03:10 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v3]
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <U6rqcgT3k8Rb3KqOuXQk83XKPxVF5BEXRuRm6fdBhhI=.1ca79227-9ce2-4bbe-acca-4ca8c1b6b902@github.com>

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  use DEFAULT_VALUE for RVExtFeatureValue::value()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27771/files
  - new: https://git.openjdk.org/jdk/pull/27771/files/50bc9bb2..66b69a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27771/head:pull/27771

PR: https://git.openjdk.org/jdk/pull/27771

From mli at openjdk.org  Thu Oct 16 14:05:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 14:05:03 GMT
Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags [v5]
In-Reply-To: <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
 <qbbUbZcTBmeS-6B6Vw7W1WZE4_cm-OFBoS72zQo6bt4=.0ec11e73-464e-4135-8543-b2a7f70737ba@github.com>
Message-ID: <yBDIikEIUfXlabpU95_pe_JWKeL4WLq7myz5TWqyyjE=.f7f5c710-bf78-425a-a54c-74c16690616f@github.com>

On Wed, 15 Oct 2025 08:17:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> ## Background
>> 
>> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
>> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
>> 
>> 
>> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> index 4214d6c53dc..80896f8fffc 100644
>> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
>> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
>> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
>> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
>> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>> 
>> 
>> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
>> 
>> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
>> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
>> 
>> 
>> ...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

Thanks for your reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27572#issuecomment-3411047528

From mli at openjdk.org  Thu Oct 16 14:08:30 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 14:08:30 GMT
Subject: Integrated: 8368950: RISC-V: fail to catch out of order declarations
 among dependent cpu extensions/flags
In-Reply-To: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
References: <R3lH69auUAvuqb6GwZyKuG86vMDhagMCBAFIJkkFllg=.98622570-47d0-48f5-b578-4d310e41297c@github.com>
Message-ID: <HPzBuyzUaReQoEr9cZ9LOT0QZtb--EL2SuwSIZ_UpkA=.379b5943-7972-4f70-80ac-ee23e9a19b3a@github.com>

On Tue, 30 Sep 2025 11:25:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> ## Background
> 
> In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS.
> But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert.
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> index 4214d6c53dc..80896f8fffc 100644
> --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp
> @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \
>    decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \
>    decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \
> - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \
>    decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \
>    decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \
> @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version {
>    decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \
>    decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \
>    decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \
> + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \
>    decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \
>    decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
>    decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \
> 
> 
> If added following patch based on the above patch, we can find out what's going on, it will trigger the assert:
> 
> # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603
> # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc)
> 
> 
> 
> diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/r...

This pull request has now been integrated.

Changeset: f475eb8e
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f475eb8ee7c9a3e360b2f1210ed71b629243cd2a
Stats:     169 lines in 2 files changed: 90 ins; 61 del; 18 mod

8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/27572

From fandreuzzi at openjdk.org  Thu Oct 16 14:09:14 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 14:09:14 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v7]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  debug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/cbbbf8a2..b53c2da4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=05-06

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From aph at openjdk.org  Thu Oct 16 14:29:39 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 14:29:39 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v19]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <aAGL4OKPnYGQwYz4x9BJuUSE6OIKEwl7XMgasSNUAXw=.c3a1492f-6b11-40ee-8e1f-356ff3c5fbaa@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Check for working WX

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/c2d9049c..66f9d04d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=17-18

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From fandreuzzi at openjdk.org  Thu Oct 16 14:39:18 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 14:39:18 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
Message-ID: <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>

On Thu, 16 Oct 2025 02:36:11 GMT, Dean Long <dlong at openjdk.org> wrote:

> We could instead allow them to be cleaned up like regular nmethods.

That sounds reasonable to me, native methods seem to be tracked like all other nmethods. 

Removing `is_native_method()` altogether from the condition was the first implementation I had, and as far as I remember there was no failure in tier1 or tier2. Should I propose this alternative implementation as part of this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2436249273

From lmesnik at openjdk.org  Thu Oct 16 14:46:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 14:46:15 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v7]
In-Reply-To: <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>
Message-ID: <dqOdtBWdsJOzy51dX77W_1tB1knaWLLEckQ1kWisCDA=.f2fd42b5-bec6-419f-a757-4eb059ee64de@github.com>

On Thu, 16 Oct 2025 14:09:14 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug

Changes requested by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3337581027

From kbarrett at openjdk.org  Thu Oct 16 14:45:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 16 Oct 2025 14:45:45 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  default construct translated atomic without SFINAE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27539/files
  - new: https://git.openjdk.org/jdk/pull/27539/files/67616416..934a4ed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=02-03

  Stats: 13 lines in 1 file changed: 6 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27539/head:pull/27539

PR: https://git.openjdk.org/jdk/pull/27539

From lmesnik at openjdk.org  Thu Oct 16 14:46:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 14:46:19 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
Message-ID: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>

On Tue, 14 Oct 2025 08:17:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   summary

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadAttach.java line 40:

> 38: import jdk.test.lib.JDKToolFinder;
> 39: 
> 40: public class TestEarlyDynamicLoadAttach {

We don't usually have individual tests on the 'serviceability' level. 
Please move test into 'attach' folder. It is test for fix in the attach mechanism.

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:

> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
> 37:     char cmd[256];
> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());

Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2430534383
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2430539286

From kbarrett at openjdk.org  Thu Oct 16 14:50:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 16 Oct 2025 14:50:26 GMT
Subject: RFR: 8369828: Generalize share/utilities/bytes.hpp [v4]
In-Reply-To: <n72O_lX1Olq7_BkQZM8LursGApg5p5zAMQ2DHIt4O_o=.3b190fb0-a838-4289-ad71-719350df1c0a@github.com>
References: <l8CneheSGfOkJMr5wHhwjMBbylD_zu4j8L197lbnT0M=.78bf14ce-d59e-4de9-a51d-b6f207b4a750@github.com>
 <n72O_lX1Olq7_BkQZM8LursGApg5p5zAMQ2DHIt4O_o=.3b190fb0-a838-4289-ad71-719350df1c0a@github.com>
Message-ID: <3Unf5LJQ5M5JYpBMkGuBIsybCsW6Xk3VMrcxo5bIucM=.376e9e78-b62d-4549-b3c0-7450c6f9fe27@github.com>

On Thu, 16 Oct 2025 13:44:45 GMT, Justin King <jcking at openjdk.org> wrote:

>> Implement portable `share/utilities/bytes.hpp` and remove CPU-specific headers.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove std::is_trivially_default_constructible
>   
>   Signed-off-by: Justin King <jcking at google.com>

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27801#pullrequestreview-3345343687

From kvn at openjdk.org  Thu Oct 16 15:40:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Oct 2025 15:40:09 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v3]
In-Reply-To: <ozdlolzPMKpWpzqV0f9pPdyChsfG6gHQCoEjPrLG82I=.69f6d217-d7e2-4090-a8e8-debc86104619@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <ozdlolzPMKpWpzqV0f9pPdyChsfG6gHQCoEjPrLG82I=.69f6d217-d7e2-4090-a8e8-debc86104619@github.com>
Message-ID: <NKK2AgYTVsWbjTUjQU10v0cywh4bJN_hZIROj1iALi8=.0d91bce5-908d-468e-83bd-91a9da6d03f7@github.com>

On Thu, 16 Oct 2025 03:56:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comment - move delay nmethod event posting to nmethod.cpp

Looks good to me.

Minimal VM build is broken:


/home/runner/work/jdk/jdk/src/hotspot/share/runtime/threads.cpp:751:14: error: ?post_delayed_compiled_method_load_events? is not a member of ?nmethod?
  751 |     nmethod::post_delayed_compiled_method_load_events();
      |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27783#pullrequestreview-3345595560
PR Comment: https://git.openjdk.org/jdk/pull/27783#issuecomment-3411495218

From rehn at openjdk.org  Thu Oct 16 15:40:09 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Oct 2025 15:40:09 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v3]
In-Reply-To: <U6rqcgT3k8Rb3KqOuXQk83XKPxVF5BEXRuRm6fdBhhI=.1ca79227-9ce2-4bbe-acca-4ca8c1b6b902@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <U6rqcgT3k8Rb3KqOuXQk83XKPxVF5BEXRuRm6fdBhhI=.1ca79227-9ce2-4bbe-acca-4ca8c1b6b902@github.com>
Message-ID: <R1ipoEECSeEjP7G1oWjmJJz4XE_vH81uHMfNWfEs8Ag=.91d95793-2633-440b-881e-58c8c5c43db6@github.com>

On Thu, 16 Oct 2025 14:03:10 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> @RealFYang 
>> 
>> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
>> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
>> And also do some simple refactoring related to enable/disable/enabled and so on.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use DEFAULT_VALUE for RVExtFeatureValue::value()

Marked as reviewed by rehn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27771#pullrequestreview-3345599056

From rehn at openjdk.org  Thu Oct 16 15:40:10 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Oct 2025 15:40:10 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v3]
In-Reply-To: <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
Message-ID: <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>

On Thu, 16 Oct 2025 13:59:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> automatically C style conversion between booleans and integer should be avoided.
>> (pointer to as bool strictly no no)
>> 
>> And I'm confused:
>> Disabled value == DEFAULT_VALUE (-1)
>> But enabled returns 0 or 1 convertet from bool?
>> 
>> { return enabled() ? _what_value_here : DEFAULT_VALUE; } ?
>
> @robehn Thanks for the offline discussion!
> It makes sense to me to use DEFAULT_VALUE in `RVExtFeatureValue::value()`.

Thank you.
Now value() behave the same regardless of implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2436501740

From mablakatov at openjdk.org  Thu Oct 16 15:46:28 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 16 Oct 2025 15:46:28 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
 <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
Message-ID: <BXFr-z1N5W3SNcz5tsk8CrEPmyqQ--8bUOnOAeyWpWA=.01e9e25c-5bc4-468e-8411-7c9ecc0de0d5@github.com>

On Wed, 8 Oct 2025 16:45:12 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 910:
>> 
>>> 908:         assert(CodeBuffer::supports_shared_stubs(), "must support shared stubs");
>>> 909:         code()->share_trampoline_for(entry.target(), entry.target(), offset());
>>> 910:       } else if (entry.rspec().type() == relocInfo::static_call_type && callee != nullptr) {
>> 
>> I think we should require `callee` to non-null for `relocInfo::static_call_type`. Otherwise this will hide bugs, when it's been intended to share but forgotten to provide `callee`.
>
> We need to convert the check `callee != nullptr` into an assert.

@eastig , I'm a bit stuck on [`gen_continuation_enter()`](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1059). I can't figure out what the target of this static call is. Are you familiar with this portion of the codebase by any chance?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2436519557

From aph at openjdk.org  Thu Oct 16 15:52:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Oct 2025 15:52:09 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions [v2]
In-Reply-To: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
Message-ID: <V8CHbJsAhpO_3OeV289k46NxoUa0O8wM8DKjTBFcIHQ=.aa25f0b7-6270-4a49-b6a3-511f806428c8@github.com>

> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
> 
> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  remove the two parameter versions of MacroAssembler::target_addr_for_insn

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27649/files
  - new: https://git.openjdk.org/jdk/pull/27649/files/c8590829..809bd2d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27649&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27649&range=00-01

  Stats: 14 lines in 2 files changed: 0 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27649/head:pull/27649

PR: https://git.openjdk.org/jdk/pull/27649

From liach at openjdk.org  Thu Oct 16 16:00:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 16:00:03 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <WdMoWavTzv3sZZpCyqhMcrhJyiDQ64MSn42eW4w8l4o=.cd1fe863-a91d-42fe-a4c5-29ef0111d9cc@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Ran tier 1-6 and saw no related failure. Should I wait for another reviewer?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3411569290

From mli at openjdk.org  Thu Oct 16 16:17:31 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 16:17:31 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v4]
In-Reply-To: <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
 <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
Message-ID: <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>

On Thu, 16 Oct 2025 15:37:28 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> @robehn Thanks for the offline discussion!
>> It makes sense to me to use DEFAULT_VALUE in `RVExtFeatureValue::value()`.
>
> Thank you.
> Now value() behave the same regardless of implementation.

Thanks for reviewing!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2436616771

From pchilanomate at openjdk.org  Thu Oct 16 16:13:42 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:13:42 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  fix verify_frame_kind

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/79fce80f..ac557152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=01-02

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Thu Oct 16 16:13:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:13:43 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <Rj22ZFVQGHj-fAxKNGVyenbBfBRLK6ohHAC-stt7Rcw=.756f9248-132f-4a89-92e1-8db4cce36902@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
 <Avv9PuWx1yWbVWOCtQswTv76NlctLw41UfhH2J_lLfU=.c995d998-df8c-4ec4-843a-68dffcbf6bb2@github.com>
 <h3n6l-iaeBBg-n2xDlHHb68PTO9BDJwy_Tp3rwxGjLU=.b6285e20-71cd-401c-b3a6-9c68b9893efd@github.com>
 <Rj22ZFVQGHj-fAxKNGVyenbBfBRLK6ohHAC-stt7Rcw=.756f9248-132f-4a89-92e1-8db4cce36902@github.com>
Message-ID: <uk8nEJyCyLHYJP90vJ3rh0BQ6R27DVs_l5o9csEl5lA=.aac66961-2df0-45f2-b604-4a21e2064ab2@github.com>

On Thu, 16 Oct 2025 07:15:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue?
>> 
>> 
>> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> index 86c56fe583f..fb1f66c60f4 100644
>> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
>> @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output
>>  static void log_frames(JavaThread* thread, bool dolog = true);
>>  static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp);
>>  static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty);
>> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr);
>> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr);
>> 
>>  #define assert_pfl(p, ...) \
>>  do {                                           \
>> @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() {
>>    return true;
>>  }
>> 
>> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) {
>> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) {
>>    Method* m;
>>    const char* code_name;
>>    int bci;
>> @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem
>>        RegisterMap reg_map(current,
>>                    RegisterMap::UpdateMap::skip,
>>                    RegisterMap::ProcessFrames::skip,
>> -                  RegisterMap::WalkContinuation::skip);
>> +                  RegisterMap::WalkContinuation::include);
>> +      if (top.is_heap_frame()) {
>> +        assert(chunk != nullptr, "");
>> +        reg_map.set_stack_chunk(chunk);
>> +        top = chunk->relativize(top);
>> +        top.set_frame_index(0);
>> +      }
>>        frame fr = top.sender(&reg_map);
>>        vframe*  vf  = vframe::new_vframe(&fr, &reg_map, current);
>>        compiledVFrame* cvf = compiledVFrame::cast(vf);
>> @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(...
>
> Your patch fixes the issue. Thanks!

Great, pushed fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436600849

From mli at openjdk.org  Thu Oct 16 16:17:30 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 16 Oct 2025 16:17:30 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v4]
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <VGZWdVfT7gw3mZwaSdd6dV3d5gohiDR4aIQqGoiK8mk=.62aa5f9e-c8e7-4fb8-94a2-33f0a6e1ec3c@github.com>

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - merge master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - use DEFAULT_VALUE for RVExtFeatureValue::value()
 - review
 - minor
 - minor
 - initial commit
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 9 more: https://git.openjdk.org/jdk/compare/95380e1e...6dd4b73f

-------------

Changes: https://git.openjdk.org/jdk/pull/27771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=03
  Stats: 46 lines in 2 files changed: 9 ins; 24 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27771/head:pull/27771

PR: https://git.openjdk.org/jdk/pull/27771

From pchilanomate at openjdk.org  Thu Oct 16 16:26:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 16:26:09 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <XF5SX-T1nEDC9RiJ3qwvw_2iGLhFbX75b3A3Hswglzg=.cedaab94-b09a-4273-bd07-65b41aa2f014@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
 <XF5SX-T1nEDC9RiJ3qwvw_2iGLhFbX75b3A3Hswglzg=.cedaab94-b09a-4273-bd07-65b41aa2f014@github.com>
Message-ID: <FfKkoLkqvJr_jBUM5XyHumRi4t8MEoI6E0trF8cX5ks=.2120f2d8-a5b9-4621-a126-d999011bc206@github.com>

On Thu, 16 Oct 2025 09:05:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into JDK-8369238
>>  - RISC-V support
>>  - Fix whitespaces
>>  - v1
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209:
> 
>> 207:     // the last_sp saved in the frame (remove possible alignment added while
>> 208:     // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp
>> 209:     // saved in the frame as it is not expected to be set in case we preempt again.
> 
> A bit stronger?
> Suggestion:
> 
>     // saved in the frame because it must be clear if we freeze again.

Just to add more context, not clearing last_sp will make this assert [1] fire if we freeze again. That assert is mostly a verification check, because we know the interpreter doesn?t set last_sp for the top frame when calling into the VM. But I don?t see a fundamental reason why it must be cleared (removing the assert and not clearing last_sp works). I don?t see any other code that checks last_sp needs to be cleared for the top frame (other than in the interpreter before calling into the VM).
How about changing that last sentence with: `We also clear last_sp to match the behavior when calling the VM from the interpreter (we check for this in FreezeBase::prepare_freeze_interpreted_top_frame).`

[1] https://github.com/openjdk/jdk/blob/87092ef1d97e00ddb6674b0e309f2f904d307604/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L136

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436641958

From iklam at openjdk.org  Thu Oct 16 17:04:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Oct 2025 17:04:48 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v4]
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <otENSbKzpH5yH3RBCh1sgQg7tdieB6bJ0XTKjB6ATSA=.a491bb87-36a1-49b8-83a3-be5b01f8e997@github.com>

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed minimal build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27783/files
  - new: https://git.openjdk.org/jdk/pull/27783/files/a3923263..e8be7599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27783&range=02-03

  Stats: 8 lines in 1 file changed: 3 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27783/head:pull/27783

PR: https://git.openjdk.org/jdk/pull/27783

From lmesnik at openjdk.org  Thu Oct 16 18:37:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 18:37:47 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <LeUal1WkcXO-KwIwtR950NQ3yFV27tYuLDc0GYjKCPc=.775d6ab5-3854-4f31-83ca-53a12ffa259e@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

The changes looks reasonable. I'm not familiar with ClassFile API though.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3346435277

From duke at openjdk.org  Thu Oct 16 18:56:48 2025
From: duke at openjdk.org (duke)
Date: Thu, 16 Oct 2025 18:56:48 GMT
Subject: Withdrawn: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for
 LSE
In-Reply-To: <VmD1YkLtZRxhBpF5lwqMltlfjtQk0D78hoHJsN-Zjrs=.63276c32-8f28-4e60-becd-55581c2b2c5d@github.com>
References: <VmD1YkLtZRxhBpF5lwqMltlfjtQk0D78hoHJsN-Zjrs=.63276c32-8f28-4e60-becd-55581c2b2c5d@github.com>
Message-ID: <I6G09VdI6PiitUq6uNCfVvEZP87Bc-7ITEaaLtd3uyg=.3e5aa1ef-fc8f-453e-a305-5da94f0f3160@github.com>

On Tue, 19 Aug 2025 14:59:42 GMT, Samuel Chee <duke at openjdk.org> wrote:

> According to the Java SE 24 API, CompareAndExchange has the memory semantics as given by VarHandle.compareAndExchange, which has the following effects [1]:
> 
>> Atomically sets the value of a variable to the newValue with the
>> memory semantics of setVolatile if the variable's current value,
>> referred to as the witness value, == the expectedValue, as accessed
>> with the memory semantics of getVolatile.
> 
> Thus, the store-release due to setVolatile only occurs if the compare is successful. Since CASAL already satisfies these requirements, the DMB does not need to occur to ensure memory ordering in case the compare fails and a store-release does not happen.
> 
> Therefore, we can remove the DMB from cmpxchgptr when LSE is enabled. We also rename it to cmpxchgptr_barrier to indicate that this method provides trailing barrier semantics (via either LSE CASAL or a DMB).
> 
> The unused cmpxchgw is removed.
> 
> [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndExchange(java.lang.Object...)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26845

From kvn at openjdk.org  Thu Oct 16 19:05:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Oct 2025 19:05:10 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v4]
In-Reply-To: <otENSbKzpH5yH3RBCh1sgQg7tdieB6bJ0XTKjB6ATSA=.a491bb87-36a1-49b8-83a3-be5b01f8e997@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <otENSbKzpH5yH3RBCh1sgQg7tdieB6bJ0XTKjB6ATSA=.a491bb87-36a1-49b8-83a3-be5b01f8e997@github.com>
Message-ID: <w48gDiYmIyUWtm6iambQnEGp544EnsxTlIKAwV9YGPw=.6e1262d3-f2ea-4d8d-ac6e-1a178ed2bb56@github.com>

On Thu, 16 Oct 2025 17:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minimal build

Re-approved.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27783#pullrequestreview-3346559830

From duke at openjdk.org  Thu Oct 16 19:41:15 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 16 Oct 2025 19:41:15 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading [v2]
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  added package and module entries

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27738/files
  - new: https://git.openjdk.org/jdk/pull/27738/files/09ce2472..67141ee8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27738&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27738&range=00-01

  Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27738/head:pull/27738

PR: https://git.openjdk.org/jdk/pull/27738

From liach at openjdk.org  Thu Oct 16 19:49:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 19:49:17 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <Fjp0vxsImvrQkoOHlEtyXhWkGrr5Ie2Gq7Kipk6JYEM=.845b1357-8124-4843-bc58-992aa36fc1e0@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Thanks for the reviews! This should remove the hassles associated with new javac class files from value objects in the future. Integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3412591019

From liach at openjdk.org  Thu Oct 16 19:49:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 19:49:18 GMT
Subject: Integrated: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <_itaIEjwLBQOzS5kpabor2UBk5jMpx0UeyaQsoNAPMU=.9b60c8d2-963d-4ad9-922d-23d637b9d881@github.com>

On Thu, 8 May 2025 14:57:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

This pull request has now been integrated.

Changeset: 3248aaf3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3248aaf3c4f6784d5176e2a2c5bac0fbda47ee6b
Stats:     608 lines in 24 files changed: 92 ins; 302 del; 214 mod

8356548: Use ClassFile API instead of ASM to transform classes in tests

Reviewed-by: sspitsyn, lmesnik, coleenp, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/25124

From valeriep at openjdk.org  Thu Oct 16 20:04:35 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 20:04:35 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
Message-ID: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>

On Thu, 16 Oct 2025 05:14:44 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:

> 1038:      * @param p [in] the plaintext to be encrypted.
> 1039:      * @param po [in] the plaintext offset in the array of bytes.
> 1040:      * @param c [out] the encrypted ciphertext output.

nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:

> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
> 1157:             w += 8;

No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:

> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];

Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:

> 1218:      * @param c [in] the ciphertext to be decrypted.
> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
> 1220:      * @param p [out] the decrypted plaintext output.

nit: same comment for removing "decrypted" adj.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437316942
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437308268
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437313179
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437325831

From duke at openjdk.org  Thu Oct 16 20:04:37 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:04:37 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
 <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
Message-ID: <yjp97Nf6C11SkoOkNb7wxk04vZ4FFWcGX_rVDgRCx_w=.431a9ec0-3cb4-47fa-b404-aa292bfcaa8a@github.com>

On Thu, 16 Oct 2025 19:55:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:
> 
>> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
>> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
>> 1157:             w += 8;
> 
> No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

I would still need w for lines 1180 - 1195 though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437324027

From duke at openjdk.org  Thu Oct 16 20:22:20 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:20 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/9f00c355..a5991a2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=06-07

  Stats: 42 lines in 1 file changed: 0 ins; 4 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Thu Oct 16 20:22:22 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:22 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
 <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
Message-ID: <rlaQjW3we7FZT6JSVZUmC8DLRTVpTDk4P5fwg348HHM=.a2e1dfc0-d154-44ed-b478-33eaa27b4d34@github.com>

On Thu, 16 Oct 2025 19:58:40 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:
> 
>> 1038:      * @param p [in] the plaintext to be encrypted.
>> 1039:      * @param po [in] the plaintext offset in the array of bytes.
>> 1040:      * @param c [out] the encrypted ciphertext output.
> 
> nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

Agreed.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:
> 
>> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
>> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
>> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];
> 
> Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

Agreed.  I've changed decryption as well.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:
> 
>> 1218:      * @param c [in] the ciphertext to be decrypted.
>> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
>> 1220:      * @param p [out] the decrypted plaintext output.
> 
> nit: same comment for removing "decrypted" adj.

Agreed.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361415
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361126
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437362009

From asmehra at openjdk.org  Thu Oct 16 20:30:48 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 16 Oct 2025 20:30:48 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions [v2]
In-Reply-To: <V8CHbJsAhpO_3OeV289k46NxoUa0O8wM8DKjTBFcIHQ=.aa25f0b7-6270-4a49-b6a3-511f806428c8@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
 <V8CHbJsAhpO_3OeV289k46NxoUa0O8wM8DKjTBFcIHQ=.aa25f0b7-6270-4a49-b6a3-511f806428c8@github.com>
Message-ID: <cONfWVL3xUCNm7TE3eqUc4GGkENG_RuOTdHkchdH2G4=.0cf42736-04a4-4524-87d4-d8072972d69b@github.com>

On Thu, 16 Oct 2025 15:52:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
>> 
>> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the two parameter versions of MacroAssembler::target_addr_for_insn

Cleanup looks good

-------------

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27649#pullrequestreview-3346893676

From mbeckwit at openjdk.org  Thu Oct 16 20:35:01 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 16 Oct 2025 20:35:01 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v8]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <pTl7aCqt58syMQPIWU1VFGtDYo0YUBbiB7hdiRFaWkI=.40f3410a-2586-4549-beb7-a8125cc6468c@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge master
 - Address OpenJDK PR feedback on time-based heap uncommit and region selection
 - Remove unused static _uncommit_delay member and accessor
 - Resolve merge conflict - keep proper @tschatzl time type implementation
   
   - Keep Tickspan::from_milliseconds(G1UncommitDelayMillis) initialization
   - Keep (jlong)elapsed.milliseconds() cast for macOS build compatibility
   - Keep elapsed > _uncommit_delay direct Tickspan comparison
   - Maintains cross-platform compatibility
 - JDK-8357445: Implement @tschatzl code review feedback for time-based heap sizing
   
   - Convert from jlong milliseconds to proper time types (Ticks/Tickspan)
   - Reclassify G1UseTimeBasedHeapSizing from EXPERIMENTAL+false to DIAGNOSTIC+true
   - Reclassify G1MinRegionsToUncommit from EXPERIMENTAL to DIAGNOSTIC
   - Keep timing flags (G1UncommitDelayMillis, G1HeapEvaluationIntervalMillis) as MANAGEABLE
   - Update all test files to use UnlockDiagnosticVMOptions instead of UnlockExperimentalVMOptions
   - Remove explicit G1UseTimeBasedHeapSizing=true from tests (now enabled by default)
   - Improve logging terminology from 'time-based' to 'uncommit evaluation'
   - Fix comment style and remove unused heap_sizing_policy() accessor
   - Comprehensive type safety improvements throughout the codebase
   
   This addresses all feedback regarding type safety, flag design,
   and production readiness of the time-based heap sizing feature.
 - JDK-8357445: Implement @tschatzl code review feedback for time-based heap sizing
   
   - Convert from jlong milliseconds to proper time types (Ticks/Tickspan)
   - Reclassify G1UseTimeBasedHeapSizing from EXPERIMENTAL+false to DIAGNOSTIC+true
   - Reclassify G1MinRegionsToUncommit from EXPERIMENTAL to DIAGNOSTIC
   - Keep timing flags (G1UncommitDelayMillis, G1HeapEvaluationIntervalMillis) as MANAGEABLE
   - Update all test files to use UnlockDiagnosticVMOptions instead of UnlockExperimentalVMOptions
   - Remove explicit G1UseTimeBasedHeapSizing=true from tests (now enabled by default)
   - Improve logging terminology from 'time-based' to 'uncommit evaluation'
   - Fix comment style and remove unused heap_sizing_policy() accessor
   - Comprehensive type safety improvements throughout the codebase
   
   This addresses all feedback regarding type safety, flag design,
   and production readiness of the time-based heap sizing feature.
 - 8357445: Remove redundant record_activity calls and leftover initialize call
   
   - Remove record_activity() from retirement methods as hr_clear() is always last
   - Remove leftover initialize() call since initialization moved to constructor
   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap
 - 8357445: Address code review feedback
   
   Extra line removed
   Include cycle comment removed
   completed changed to flagged
   nullptr assignment changed to assert
   Redundant nullptr check removed
   VM_G1ShrinkHeap moved
   Forward declaration removed
   Constructor initialization for static _uncommit_delay_ms
 - Normalize encoding and line endings for G1 GC time-based tests
 - JDK-8357445: G1: Time-Based Heap Uncommit During Idle Periods
   
   Implement time-based heap uncommit for G1 during idle periods.
   
   Key changes:
   - Added G1HeapEvaluationTask for periodic heap evaluation
   - Switch from G1ServiceTask to PeriodicTask for virtual thread support
   - Implemented time-based heap sizing policy with configurable uncommit delay
   - Added region activity tracking with last access timestamps
   - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
   - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
   - Added 'sizing' log tag for heap sizing operations
   
   Comprehensive Test Coverage:
   - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
   - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
   - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
   - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
   
   This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

-------------

Changes: https://git.openjdk.org/jdk/pull/26240/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=07
  Stats: 1779 lines in 22 files changed: 1759 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

PR: https://git.openjdk.org/jdk/pull/26240

From mbeckwit at openjdk.org  Thu Oct 16 20:40:11 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 16 Oct 2025 20:40:11 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v9]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <S7wlfoDQA_UaqDHdcCy5UQzRt40vHwIR2yVjuVtKyRM=.c36119db-035e-4aca-a78c-18faf3304c62@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  8357445: Fix trailing whitespace issues in G1 time-based heap sizing implementation
  
  - Remove trailing whitespace from all modified G1 files
  - Resolves OpenJDK jcheck whitespace validation errors
  - No functional changes, whitespace cleanup only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/f69773bf..504e6d21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=07-08

  Stats: 49 lines in 6 files changed: 0 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

PR: https://git.openjdk.org/jdk/pull/26240

From fandreuzzi at openjdk.org  Thu Oct 16 20:54:17 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 20:54:17 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - revert
 - replace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/b53c2da4..7870ca78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=06-07

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From vlivanov at openjdk.org  Thu Oct 16 21:23:04 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 16 Oct 2025 21:23:04 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <DoIicmWfNmLt0XbsbbQLKPqwOqyQBy-QTwgdeGWq2kE=.1fd42f87-49c7-4d17-a8d0-f811f402eb94@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
 <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
 <UHR_QMk3BOsqMglcPIm2ENYYhg7es7S6DWr54kQkqOs=.d5b69afe-ed04-4dbb-9943-f8c7863ff1d3@github.com>
 <DoIicmWfNmLt0XbsbbQLKPqwOqyQBy-QTwgdeGWq2kE=.1fd42f87-49c7-4d17-a8d0-f811f402eb94@github.com>
Message-ID: <f2SeL3ZWytJAmyjbgnnz_pREEH0gA5uW3hyf9MtL8D8=.57b1cf62-742e-4fd2-8894-ec980f359844@github.com>

On Tue, 14 Oct 2025 05:52:51 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Considering that the linux-riscv64 hwprobe syscall is not always usable for detecting support for misaligned vector access especially on old kernels, it makes sense to me that we should give the user a choice to decide.
>
> Hi @iwanowww What do you think?

I'm strongly in favor of improving detection logic. In the worst case, it would require performing a misaligned vector access during VM bootstrapping and checking whether it traps or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2437492942

From duke at openjdk.org  Thu Oct 16 21:25:01 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 16 Oct 2025 21:25:01 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading [v2]
In-Reply-To: <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>
Message-ID: <PJ3cVqe9HXJ1qIiTCXDyeh9jQ6tC81t-ienhUiK4bfc=.87bd7486-1302-4f26-aac7-2f2f16af74fe@github.com>

On Thu, 16 Oct 2025 19:41:15 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
>> 
>> The location of the class file for a class defined can be of utility in both debugging and auditing.
>> 
>> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added package and module entries

looking at the current implementation for both jdk.ClassDefine and jdk.ClassLoad events, the "source" metadata recorded by the new event is not available in the (current) calling context for either of the pre-existing events.

In my opinion adding a new event to capture this information is less intrusive than adding fields(s) to the existing event(s) and contriving to provide the necessary state to those at their current call sites (or by relocating those to a calling context where the "source" is available)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3412911045

From fandreuzzi at openjdk.org  Thu Oct 16 22:07:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 22:07:19 GMT
Subject: Integrated: 8369734: JvmtiExport::post_class_file_load_hook return
 value is never used
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <CCHXj7CYxiEW0JmrlOoJJfC215qymBuB6guVx_5ydtQ=.1b02fb00-c5b8-41ad-9fc2-406ca198fe4d@github.com>

On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 0bdd6f06
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bdd6f0640fc25667f911228eed6a0fa118e8ff8
Stats:     12 lines in 2 files changed: 0 ins; 7 del; 5 mod

8369734: JvmtiExport::post_class_file_load_hook return value is never used

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27777

From sspitsyn at openjdk.org  Thu Oct 16 22:37:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 22:37:01 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
Message-ID: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>

On Thu, 16 Oct 2025 20:54:17 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert
>  - replace

The approach looks okay to me. Thank you for taking care about this issue!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413122264

From sspitsyn at openjdk.org  Thu Oct 16 22:37:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 22:37:04 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
Message-ID: <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>

On Tue, 14 Oct 2025 21:34:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:
> 
>> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
>> 37:     char cmd[256];
>> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());
> 
> Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.

Also, I'd suggest to convert native part from C to C++. Some examples in the test base can be found easily. There is already a number of tests with C based native agents. We need to convert them to C++ at some point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2437610532

From fandreuzzi at openjdk.org  Thu Oct 16 22:54:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 22:54:35 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  check jcmd exist

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/7870ca78..1363424e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=07-08

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From amenkov at openjdk.org  Thu Oct 16 23:03:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Oct 2025 23:03:03 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
Message-ID: <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>

On Thu, 16 Oct 2025 22:54:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check jcmd exist

Looks like both new test fail on Windows-x64

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413173277

From sspitsyn at openjdk.org  Thu Oct 16 23:03:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

The fix looks good in general but I've posted a question.

Marked as reviewed by sspitsyn (Reviewer).

test/jdk/ProblemList-Virtual.txt line 63:

> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all

Q: The following tests removed from this Problem-List do not have the required tweaks:

-java/lang/invoke/condy/CondyNestedResolutionTest.java
-jdk/jfr/startupargs/TestDumpOnExit.java
-java/util/Properties/StoreReproducibilityTest.java
-javax/management/ImplementationVersion/ImplVersionTest.java
-javax/management/remote/mandatory/version/ImplVersionTest.java

Is it intentional? Do I miss anything? Could you, please, explain a little bit?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347252960
PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347261953
PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437646036

From sspitsyn at openjdk.org  Thu Oct 16 23:03:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>
Message-ID: <tK2QZRmWg4m4UDLJIJpC-UG6i7wRrwf6qBaTrrKvFx4=.b321f19d-60c6-46e2-9aa1-79c907029c5b@github.com>

On Thu, 16 Oct 2025 22:57:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights updated
>>  - more tests removed
>
> test/jdk/ProblemList-Virtual.txt line 63:
> 
>> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
>> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all
> 
> Q: The following tests removed from this Problem-List do not have the required tweaks:
> 
> -java/lang/invoke/condy/CondyNestedResolutionTest.java
> -jdk/jfr/startupargs/TestDumpOnExit.java
> -java/util/Properties/StoreReproducibilityTest.java
> -javax/management/ImplementationVersion/ImplVersionTest.java
> -javax/management/remote/mandatory/version/ImplVersionTest.java
> 
> Is it intentional? Do I miss anything? Could you, please, explain a little bit?

I see you already explained this in the description. Sorry for the noise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437658480

From fandreuzzi at openjdk.org  Thu Oct 16 23:10:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 23:10:02 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
 <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>
Message-ID: <6ICNwv-YCNa_BFoB4wYA2eyDE7cdNU4o1hG6rqLl-kY=.eb728477-b51c-497e-b821-d889db6ed4f5@github.com>

On Thu, 16 Oct 2025 23:00:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Looks like both new test fail on Windows-x64

I'm looking into it, I don't have a Windows setup so I'm using GHA to test :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413186002

From dlong at openjdk.org  Thu Oct 16 23:25:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 16 Oct 2025 23:25:03 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <BXFr-z1N5W3SNcz5tsk8CrEPmyqQ--8bUOnOAeyWpWA=.01e9e25c-5bc4-468e-8411-7c9ecc0de0d5@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
 <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
 <BXFr-z1N5W3SNcz5tsk8CrEPmyqQ--8bUOnOAeyWpWA=.01e9e25c-5bc4-468e-8411-7c9ecc0de0d5@github.com>
Message-ID: <9idT2wdo-uuG1seABSR_6Mr0S_ygFBmeAbL6hK2QwCg=.343f6868-486a-4407-ab43-f6236a504e37@github.com>

On Thu, 16 Oct 2025 15:43:30 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> We need to convert the check `callee != nullptr` into an assert.
>
> @eastig , I'm a bit stuck on [`gen_continuation_enter()`](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1059). I can't figure out what the target of this static call is. Are you familiar with this portion of the codebase by any chance?

The target is Continuation::enter(), thanks to LinkResolver::resolve_continuation_enter().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2437715928

From dlong at openjdk.org  Thu Oct 16 23:43:02 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 16 Oct 2025 23:43:02 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
Message-ID: <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>

On Thu, 16 Oct 2025 14:36:06 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 2599:
>> 
>>> 2597: // nmethods that don't seem to be all that relevant any longer.
>>> 2598: bool nmethod::is_cold() {
>>> 2599:   if (!MethodFlushing || (is_native_method() && is_in_use()) || is_not_installed()) {
>> 
>> So I guess we need to decide what to do about native wrappers that are still "in use", but are "cold" because they haven't been called in a while.  The above change would keep them around forever.  We could instead allow them to be cleaned up like regular nmethods.
>
>> We could instead allow them to be cleaned up like regular nmethods.
> 
> That sounds reasonable to me, native methods seem to be tracked like all other nmethods. 
> 
> Removing `is_native_method()` altogether from the condition was the first implementation I had, and as far as I remember there was no failure in tier1 or tier2. Should I propose this alternative implementation as part of this PR?

I am tempted to say yes, for consistency, but it probably won't make much of a difference either way.  But now I am wondering, if these cold native wrappers continue to be immortal, then do they really need to give them nmethod entry barriers?  Removing the barrier could remove some overhead.  Whatever direction we decide to go, it would be good to add a comment here explaining the decision and/or trade-offs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2437762613

From vpetko at openjdk.org  Fri Oct 17 01:54:34 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 17 Oct 2025 01:54:34 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not return
 old value when compareExchange fails
Message-ID: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>

This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.

Testing (s390x) :

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
                                                         1     1     0     0     0   
==============================
TEST SUCCESS

Tier1 summary:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
   jtreg:test/jdk:tier1                               2518  2418     0     0   100   
   jtreg:test/langtools:tier1                         4672  4662     0     0    10   
   jtreg:test/jaxp:tier1                                 0     0     0     0     0   
   jtreg:test/lib-test:tier1                            38    38     0     0     0   
==============================
TEST SUCCESS


Tier 2 tests contain unrelated failures:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
   jtreg:test/langtools:tier2                           14    12     0     0     2   
   jtreg:test/jaxp:tier2                               517   516     0     0     1   
   jtreg:test/docs:tier2                                 4     0     0     0     4   
==============================
TEST FAILURE

jtreg:test/hotspot/jtreg:tier2:
1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 

jtreg:test/jdk:tier2:
1. ``java/net/Inet6Address/B6206527.java                                                                      Failed. Execution failed: `main' threw exception: java.net.SocketException: Duplicate link local addresses: must specify scope-id``
2. ``java/net/Inet6Address/Scoping.java                                                                       Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed: /[fe80:0:0:0:ca:9ff:fe00:6d0c]:0count: 0``
3. ``java/net/NetworkInterface/UniqueMacAddressesTest.java                                                    Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: mac address uniqueness test failed``
4. ``tools/launcher/HelpFlagsTest.java                                                                        Failed. Execution failed: `main' threw exception: java.lang.AssertionError: HelpFlagsTest failed: Tool jrunscript not covered by this test. Add specification to jdkTools array!``
5. ``tools/launcher/VersionCheck.java                                                                         Failed. Execution failed: `main' threw exception: java.lang.AssertionError: VersionCheck failed: testToolVersion: [jrunscript];``

-------------

Commit messages:
 - test: clean up test code
 - fix(s390x): return cas operation result instead of the expected value

Changes: https://git.openjdk.org/jdk/pull/27857/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370049
  Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27857/head:pull/27857

PR: https://git.openjdk.org/jdk/pull/27857

From fyang at openjdk.org  Fri Oct 17 03:03:04 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 17 Oct 2025 03:03:04 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v4]
In-Reply-To: <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
 <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
 <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>
Message-ID: <q38yFyEdUVWCXG6tbO6FnPkduagYyr7S3v9xKj1G0CU=.37414079-5a7f-4d29-ba88-40d555738fc1@github.com>

On Thu, 16 Oct 2025 16:13:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Thank you.
>> Now value() behave the same regardless of implementation.
>
> Thanks for reviewing!

Hmm ... But I find the only use of `value` in `VM_Version::setup_cpu_available_features()` is for `log_debug`:

147       log_debug(os, cpu)("Enabled RV64 feature "%s" (%ld)",
148              _feature_list[i]->pretty(),
149              _feature_list[i]->value());

Can we simply move this to other methods like `enable_feature()` or `disable_feature()` in the subclasses? These are the places where we do the real enable / disable for them. If that make sense, then we would be able to make `value()` a method only for non-extensions. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2438107157

From amitkumar at openjdk.org  Fri Oct 17 04:16:03 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 17 Oct 2025 04:16:03 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <5RjbmXpUxiDmLh9B_5QMBQeG0tJLS1G2oCXb_J9HDp4=.7232367e-a64a-405e-9905-3449c75382c1@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

Thank you so much for fixing this. I am surprised that it survived this long.

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27857#pullrequestreview-3348177568

From qpzhang at openjdk.org  Fri Oct 17 04:19:42 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Fri, 17 Oct 2025 04:19:42 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
Message-ID: <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>

> Issue: 
> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check.
> 
> This PR:
> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled.
> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization.
> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. 
> 
> Tests:
> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected.
> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks.

Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Refine the count types to pass mac and win builds
  
  Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26917/files
  - new: https://git.openjdk.org/jdk/pull/26917/files/c748d218..2bbc1d04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=05-06

  Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917

PR: https://git.openjdk.org/jdk/pull/26917

From qpzhang at openjdk.org  Fri Oct 17 04:23:05 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Fri, 17 Oct 2025 04:23:05 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v7]
In-Reply-To: <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <GjVnBFpmztg63oLghMGJ9h178LbFxKFQk-2IbR8T3Rk=.8fd619fc-6c35-459a-bf7f-ed20d48295eb@github.com>
Message-ID: <zfPFU_f5Co_IwHOu43YwzU8yknyW8X3hjnvcS5STewI=.23d46e7e-1b0c-4c4b-92ac-3c9e1b0eba1d@github.com>

On Fri, 17 Oct 2025 04:19:42 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> Issue: 
>> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check.
>> 
>> This PR:
>> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled.
>> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization.
>> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. 
>> 
>> Tests:
>> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected.
>> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks.
>
> Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the count types to pass mac and win builds
>   
>   Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

Added [test/hotspot/gtest/aarch64/test_MacroAssembler_zero_words.cpp](https://github.com/openjdk/jdk/pull/26917/files#diff-6698530e8c1fe55cec7c20ca36725bde034b3cd74b25ccee77cc50f66dabf16c) to measure the impact of different low limits and cleared word counts on the wall time of `MacroAssembler::zero_words` and compare the resulting differences.

Run the test and compare the wall times. We can see that `fixing the low limit from a lower value to the default 256` improves codegen efficiency, by 11x on clear_4_words (289 vs. 25) and by 1.6x on clear_16_words (170 vs. 107).

$ make run-test TEST="gtest:MacroAssemblerZeroWordsTest"

> Clear 4 words with lower limit 8, zero_words wall time (ns): 289
> Clear 4 words with lower limit 256, zero_words wall time (ns): 25
> Clear 16 words with lower limit 64, zero_words wall time (ns): 170
> Clear 16 words with lower limit 256, zero_words wall time (ns): 107

See below for the detailed run log, including the generated code sequences under various conditions:


Test selection 'gtest:MacroAssemblerZeroWordsTest', will run:
* gtest:MacroAssemblerZeroWordsTest/server

Running test 'gtest:MacroAssemblerZeroWordsTest/server'
Note: Google Test filter = MacroAssemblerZeroWordsTest*
[==========] Running 4 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 4 tests from MacroAssemblerZeroWordsTest
[ RUN      ] MacroAssemblerZeroWordsTest.UseBZ_clear_32B_with_lowlimit_8B_vm
--------------------------------------------------------------------------------
udf     #0
  0x0000400011c56a40:   mov     x10, #0x6fb0                    // #28592
  0x0000400011c56a44:   movk    x10, #0xab05, lsl #16
  0x0000400011c56a48:   movk    x10, #0xaaaa, lsl #32
  0x0000400011c56a4c:   orr     x11, xzr, #0x4
  0x0000400011c56a50:   subs    x8, x11, #0x8
  0x0000400011c56a54:   b.cc    0x0000400011c56a5c  // b.lo, b.ul, b.last
  0x0000400011c56a58:   bl      Stub::Stub Generator zero_blocks_stub
  0x0000400011c56a5c:   tbz     w11, #2, 0x0000400011c56a68
  0x0000400011c56a60:   stp     xzr, xzr, [x10], #16
  0x0000400011c56a64:   stp     xzr, xzr, [x10], #16
  0x0000400011c56a68:   tbz     w11, #1, 0x0000400011c56a70
  0x0000400011c56a6c:   stp     xzr, xzr, [x10], #16
  0x0000400011c56a70:   tbz     w11, #0, 0x0000400011c56a78
  0x0000400011c56a74:   str     xzr, [x10]
--------------------------------------------------------------------------------

Clear 4 words with lower limit 8, zero_words wall time (ns): 289
[       OK ] MacroAssemblerZeroWordsTest.UseBZ_clear_32B_with_lowlimit_8B_vm (2 ms)
[ RUN      ] MacroAssemblerZeroWordsTest.UseBZ_clear_32B_with_lowlimit_256B_vm
--------------------------------------------------------------------------------
udf     #0
  0x0000400011c57400:   mov     x10, #0x6fb0                    // #28592
  0x0000400011c57404:   movk    x10, #0xab05, lsl #16
  0x0000400011c57408:   movk    x10, #0xaaaa, lsl #32
  0x0000400011c5740c:   stp     xzr, xzr, [x10]
  0x0000400011c57410:   stp     xzr, xzr, [x10, #16]
--------------------------------------------------------------------------------

Clear 4 words with lower limit 256, zero_words wall time (ns): 25
[       OK ] MacroAssemblerZeroWordsTest.UseBZ_clear_32B_with_lowlimit_256B_vm (0 ms)
[ RUN      ] MacroAssemblerZeroWordsTest.UseBZ_clear_128B_with_lowlimit_64B_vm
--------------------------------------------------------------------------------
udf     #0
  0x0000400011c57400:   mov     x10, #0x6fe0                    // #28640
  0x0000400011c57404:   movk    x10, #0xab05, lsl #16
  0x0000400011c57408:   movk    x10, #0xaaaa, lsl #32
  0x0000400011c5740c:   orr     x11, xzr, #0x10
  0x0000400011c57410:   subs    x8, x11, #0x8
  0x0000400011c57414:   b.cc    0x0000400011c5741c  // b.lo, b.ul, b.last
  0x0000400011c57418:   bl      Stub::Stub Generator zero_blocks_stub
  0x0000400011c5741c:   tbz     w11, #2, 0x0000400011c57428
  0x0000400011c57420:   stp     xzr, xzr, [x10], #16
  0x0000400011c57424:   stp     xzr, xzr, [x10], #16
  0x0000400011c57428:   tbz     w11, #1, 0x0000400011c57430
  0x0000400011c5742c:   stp     xzr, xzr, [x10], #16
  0x0000400011c57430:   tbz     w11, #0, 0x0000400011c57438
  0x0000400011c57434:   str     xzr, [x10]
--------------------------------------------------------------------------------

Clear 16 words with lower limit 64, zero_words wall time (ns): 170
[       OK ] MacroAssemblerZeroWordsTest.UseBZ_clear_128B_with_lowlimit_64B_vm (0 ms)
[ RUN      ] MacroAssemblerZeroWordsTest.UseBZ_clear_128B_with_lowlimit_256B_vm
--------------------------------------------------------------------------------
udf     #0
  0x0000400011c57400:   mov     x10, #0x6fe0                    // #28640
  0x0000400011c57404:   movk    x10, #0xab05, lsl #16
  0x0000400011c57408:   movk    x10, #0xaaaa, lsl #32
  0x0000400011c5740c:   stp     xzr, xzr, [x10]
  0x0000400011c57410:   stp     xzr, xzr, [x10, #16]
  0x0000400011c57414:   stp     xzr, xzr, [x10, #32]
  0x0000400011c57418:   stp     xzr, xzr, [x10, #48]
  0x0000400011c5741c:   stp     xzr, xzr, [x10, #64]
  0x0000400011c57420:   stp     xzr, xzr, [x10, #80]
  0x0000400011c57424:   stp     xzr, xzr, [x10, #96]
  0x0000400011c57428:   stp     xzr, xzr, [x10, #112]
  0x0000400011c5742c:   add     x10, x10, #0x80
--------------------------------------------------------------------------------

Clear 16 words with lower limit 256, zero_words wall time (ns): 107
[       OK ] MacroAssemblerZeroWordsTest.UseBZ_clear_128B_with_lowlimit_256B_vm (0 ms)
[----------] 4 tests from MacroAssemblerZeroWordsTest (110 ms total)

[----------] Global test environment tear-down
[==========] 4 tests from 1 test suite ran. (110 ms total)
[  PASSED  ] 4 tests.
Finished running test 'gtest:MacroAssemblerZeroWordsTest/server'
Test report is stored in build-pr/test-results/gtest_MacroAssemblerZeroWordsTest_server

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   gtest:MacroAssemblerZeroWordsTest/server              4     4     0     0     0   
==============================
TEST SUCCESS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3413812045

From mbeckwit at openjdk.org  Fri Oct 17 05:19:03 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Fri, 17 Oct 2025 05:19:03 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v10]
In-Reply-To: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
References: <RLcdu4bOlzGjDgFzeceN2TShErL7vxBgZEn0FIbjyDY=.1deb2754-34c4-4881-a211-7a8da5f0efac@github.com>
Message-ID: <1FJGEob7g_zkJaboRxyS0hPJ1c590V6zZipDrZ3XpOw=.08c1cf33-af6b-49de-b94d-d4f2ca8f5a22@github.com>

> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
> 
> Implement time-based heap uncommit for G1 during idle periods.
> 
> Key changes:
> - Added G1HeapEvaluationTask for periodic heap evaluation
> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
> - Implemented time-based heap sizing policy with configurable uncommit delay
> - Added region activity tracking with last access timestamps
> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
> - Added 'sizing' log tag for heap sizing operations
> 
> Comprehensive Test Coverage:
> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
> 
> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.

Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision:

 - Fix compilation errors after master merge
   
   - Fix syntax error in g1CollectedHeap.cpp (extra closing brace)
   - Update API call from short_term_pause_time_ratio() to short_term_gc_time_ratio()
   
   These fixes resolve compilation issues that occurred after merging with
   upstream master due to API changes in the OpenJDK codebase.
 - 8357445: Address feedback for G1 time-based heap sizing
   
   - Fix indentation in log_debug statement in shrink_helper (suggested by @tschatzl)
   - Change terminology from 'inactive' to 'idle' throughout time-based heap sizing
   - Update flag descriptions in g1_globals.hpp to use 'idle' terminology
   - Fix remaining trailing whitespace in test files
   
   Addresses all outstanding review comments from @tschatzl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26240/files
  - new: https://git.openjdk.org/jdk/pull/26240/files/504e6d21..c17f5938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26240&range=08-09

  Stats: 44 lines in 8 files changed: 5 ins; 5 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/26240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26240/head:pull/26240

PR: https://git.openjdk.org/jdk/pull/26240

From valeriep at openjdk.org  Fri Oct 17 05:44:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 05:44:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:

> 909:             }
> 910:             sessionK[0] = genRoundKeys(key, rounds);
> 911:             sessionK[1] = invGenRoundKeys();

Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.

 private static int[][] genRoundKeys(byte[] key, int rounds) {
        int[][] ks = new int[2][]; // key schedule

        int wLen = (rounds + 1) * WB;
        int nk = key.length / WB;

        // generate the round keys for encryption
        int[] w = new int[wLen];
        for (int i = 0, j = 0; i < nk; i++, j+=4) {
            w[i] = ((key[j] & 0xFF) << 24)
                    | ((key[j + 1] & 0xFF) << 16)
                    | ((key[j + 2] & 0xFF) << 8)
                    | (key[j + 3] & 0xFF);
        }
        for (int i = nk; i < wLen; i++) {
            int tmp = w[i - 1];
            if (i % nk == 0) {
                int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
                tmp = subWord(rW) ^ RCON[(i / nk) - 1];
            } else if ((nk > 6) && ((i % nk) == WB)) {
                tmp = subWord(tmp);
            }
            w[i] = w[i - nk] ^ tmp;
        }
        ks[0] = w;

        // generate the decryption round keys based on encryption ones
        int[] dw = new int[wLen];
        int[] temp = new int[WB];

        // Intrinsics requires the inverse key expansion to be reverse order
        // except for the first and last round key as the first two round keys
        // are without a mix column transform.
        for (int i = 1; i < rounds; i++) {
            System.arraycopy(w, i * WB, temp, 0, WB);
            invMixRKey(temp);
            System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
        }
        // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
        System.arraycopy(w, 0, dw, 0, WB);
        System.arraycopy(w, wLen - WB, dw, WB, WB);
        ks[1] = dw;
        Arrays.fill(temp, 0);

        return ks;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438441223

From valeriep at openjdk.org  Fri Oct 17 06:17:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:17:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <Tj5N0POau9TQJhtth0YNN7hx2ofNHkn57Bx4FCPMuWw=.7c460466-36c2-4679-8bb9-b9c1f756f402@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:

> 956:      * @return the processed round key row.
> 957:      */
> 958:     private static int invMix(int[] state, int idx) {

It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.

    private static void invMixRKey(int[] state) {
        state[0] = invMix(state[0]);
        state[1] = invMix(state[1]);
        state[2] = invMix(state[2]);
        state[3] = invMix(state[3]);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438501716

From valeriep at openjdk.org  Fri Oct 17 06:30:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:30:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <56BA-l6ZrdSY0IRWxXme_AM_CWW_vtBSrzYqIA4oZaE=.b9011356-c376-455a-8964-4534f9db6035@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:

> 974:      * @param state [in, out] the round key for inverse mix column processing.
> 975:      */
> 976:     private static void invMixRKey(int[] state) {

nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438537870

From dholmes at openjdk.org  Fri Oct 17 06:53:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 06:53:20 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
Message-ID: <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>

On Thu, 16 Oct 2025 16:13:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix verify_frame_kind

Great piece of work @pchilano ! I've taken an initial pass through the main class/thread/objectMonitor pieces.

src/hotspot/share/interpreter/linkResolver.cpp line 1122:

> 1120:       resolved_klass->initialize(CHECK);
> 1121:     } else if (static_mode == StaticMode::initialize_klass_preemptable) {
> 1122:       resolved_klass->initialize_preemptable(CHECK);

Why is this not CHECK_AND_CLEAR_PREEMPTED?

src/hotspot/share/interpreter/linkResolver.hpp line 192:

> 190: };
> 191: 
> 192: enum class StaticMode : uint8_t {

Need to think of a better name for this ... `ClassInitMode`?

src/hotspot/share/interpreter/linkResolver.hpp line 195:

> 193:   dont_initialize_klass,
> 194:   initialize_klass,
> 195:   initialize_klass_preemptable

And maybe more concisely:
Suggestion:

  dont_init
  init
  init_preemptable

?

src/hotspot/share/oops/instanceKlass.cpp line 1284:

> 1282:   // Block preemption once we are the initializer thread. Unmounting now
> 1283:   // would complicate the reentrant case (identity is platform thread).
> 1284:   NoPreemptMark npm(THREAD);

How does this affect unrelated "preemption" that may occur in the Java code called as part of `<clinit>`?

src/hotspot/share/oops/klass.hpp line 583:

> 581:   // initializes the klass
> 582:   virtual void initialize(TRAPS);
> 583:   virtual void initialize_preemptable(TRAPS);

Can we not define these on `instanceKlass` instead of `klass`? Seems really odd to declare virtual methods for which the base class version should never be called (they should be pure virtuals in that case I would think?).

src/hotspot/share/runtime/continuationEntry.cpp line 117:

> 115:   assert(thread->has_last_Java_frame(), "Wrong place to use this assertion");
> 116: 
> 117:   if (preempted) return true;

I don't see the point of adding a new parameter just so the method can check it and return immediately. Shouldn't the caller be checking this?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 196:

> 194: static void do_deopt_after_thaw(JavaThread* thread);
> 195: static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, outputStream* st);
> 196: static void log_frames(JavaThread* thread, bool dolog = true);

Suggestion:

static void log_frames(JavaThread* thread, bool do_log = true);

src/hotspot/share/runtime/javaThread.hpp line 492:

> 490:   // throw IE at the end of thawing before returning to Java.
> 491:   bool _pending_interrupted_exception;
> 492:   // We allow preemption on some klass initializion calls.

Suggestion:

  // We allow preemption on some klass initialization calls.

src/hotspot/share/runtime/javaThread.hpp line 507:

> 505: 
> 506:   bool at_preemptable_init() { return _at_preemptable_init; }
> 507:   void set_at_preemptable_init(bool b) { _at_preemptable_init = b; }

If you are going align 503 and 504 then you may as well align these two lines as well

src/hotspot/share/runtime/javaThread.hpp line 522:

> 520:     JavaThread* _thread;
> 521:    public:
> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {

Suggestion:

    AtRedoVMCall(JavaThread* t) : _thread(t) {

src/hotspot/share/runtime/javaThread.hpp line 524:

> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {
> 523:       _thread->_interp_at_preemptable_vmcall_cnt++;
> 524:       assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "");

Suggestion:

      assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

src/hotspot/share/runtime/javaThread.hpp line 528:

> 526:     ~AtRedoVMCall() {
> 527:       _thread->_interp_at_preemptable_vmcall_cnt--;
> 528:       assert(_thread->_interp_at_preemptable_vmcall_cnt >= 0, "");

Suggestion:

    assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

src/hotspot/share/runtime/objectMonitor.cpp line 315:

> 313: }
> 314: 
> 315: // Keep object protected during ObjectLocker preemption.

I don't understand why this is necessary.

src/hotspot/share/runtime/synchronizer.cpp line 489:

> 487:     if (_thread->preempting()) {
> 488:       // If preemption was cancelled we acquired the monitor after freezing
> 489:       // the frames. Redoing the vm call later?in thaw will require us to

I don't quite follow the control flow here - at what point have we frozen any frames? Was that deep inside `enter`?

src/hotspot/share/runtime/synchronizer.hpp line 230:

> 228:   bool    _skip_exit;
> 229:  public:
> 230:   ObjectLocker(Handle obj, TRAPS);

I wonder if we should declare `PREEMPTABLE_TRAPS` as an indicator that the only exception expected to come out of a call is the preempted-exception?

src/java.base/share/classes/java/lang/VirtualThread.java line 172:

> 170: 
> 171:     // true when waiting in Object.wait, false for VM internal uninterruptible Object.wait
> 172:     private volatile boolean interruptableWait;

Suggestion:

    private volatile boolean interruptibleWait;

src/java.base/share/classes/java/lang/VirtualThread.java line 605:

> 603:         if (s == WAITING || s == TIMED_WAITING) {
> 604:             int newState;
> 605:             boolean interruptable = interruptableWait;

Suggestion:

            boolean interruptible = interruptibleWait;

src/java.base/share/classes/jdk/internal/vm/PreemptedException.java line 31:

> 29:  * Internal exception used only by the VM.
> 30:  */
> 31: public class PreemptedException extends Exception {

Should probably extend `RuntimeException` so that it is not considered a checked-exception

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3348320781
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438580798
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438444689
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438447733
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438469910
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438473899
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438480176
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438482435
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438506706
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438516134
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438518828
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438523339
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438524180
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438533049
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438542039
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438549455
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438568359
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438568876
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2438571309

From duke at openjdk.org  Fri Oct 17 06:56:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/a5991a2f..2ce35b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=07-08

  Stats: 47 lines in 1 file changed: 7 ins; 39 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Fri Oct 17 06:56:46 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:46 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
Message-ID: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>

On Fri, 17 Oct 2025 05:41:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
> 
>> 909:             }
>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>> 911:             sessionK[1] = invGenRoundKeys();
> 
> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
> 
>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>         int[][] ks = new int[2][]; // key schedule
> 
>         int wLen = (rounds + 1) * WB;
>         int nk = key.length / WB;
> 
>         // generate the round keys for encryption
>         int[] w = new int[wLen];
>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>             w[i] = ((key[j] & 0xFF) << 24)
>                     | ((key[j + 1] & 0xFF) << 16)
>                     | ((key[j + 2] & 0xFF) << 8)
>                     | (key[j + 3] & 0xFF);
>         }
>         for (int i = nk; i < wLen; i++) {
>             int tmp = w[i - 1];
>             if (i % nk == 0) {
>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>             } else if ((nk > 6) && ((i % nk) == WB)) {
>                 tmp = subWord(tmp);
>             }
>             w[i] = w[i - nk] ^ tmp;
>         }
>         ks[0] = w;
> 
>         // generate the decryption round keys based on encryption ones
>         int[] dw = new int[wLen];
>         int[] temp = new int[WB];
> 
>         // Intrinsics requires the inverse key expansion to be reverse order
>         // except for the first and last round key as the first two round keys
>         // are without a mix column transform.
>         for (int i = 1; i < rounds; i++) {
>             System.arraycopy(w, i * WB, temp, 0, WB);
>             invMixRKey(temp);
>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>         }
>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>         System.arraycopy(w, 0, dw, 0, WB);
>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>         ks[1] = dw;
>         Arrays.fill(temp, 0);
> 
>         return ks;
>     }

These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
> 
>> 956:      * @return the processed round key row.
>> 957:      */
>> 958:     private static int invMix(int[] state, int idx) {
> 
> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
> 
>     private static void invMixRKey(int[] state) {
>         state[0] = invMix(state[0]);
>         state[1] = invMix(state[1]);
>         state[2] = invMix(state[2]);
>         state[3] = invMix(state[3]);
>     }

I've removed this method and inlined this logic in the invGenRoundKeys method.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:
> 
>> 974:      * @param state [in, out] the round key for inverse mix column processing.
>> 975:      */
>> 976:     private static void invMixRKey(int[] state) {
> 
> nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

I've removed this method and inlined this logic in the invGenRoundKeys method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587221
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587085
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438586207

From valeriep at openjdk.org  Fri Oct 17 07:07:11 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 07:07:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>

On Fri, 17 Oct 2025 06:52:39 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
>> 
>>> 956:      * @return the processed round key row.
>>> 957:      */
>>> 958:     private static int invMix(int[] state, int idx) {
>> 
>> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
>> 
>>     private static void invMixRKey(int[] state) {
>>         state[0] = invMix(state[0]);
>>         state[1] = invMix(state[1]);
>>         state[2] = invMix(state[2]);
>>         state[3] = invMix(state[3]);
>>     }
>
> I've removed this method and inlined this logic in the invGenRoundKeys method.

Sure, this works as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438612714

From mli at openjdk.org  Fri Oct 17 08:20:08 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Oct 2025 08:20:08 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v4]
In-Reply-To: <q38yFyEdUVWCXG6tbO6FnPkduagYyr7S3v9xKj1G0CU=.37414079-5a7f-4d29-ba88-40d555738fc1@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
 <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
 <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>
 <q38yFyEdUVWCXG6tbO6FnPkduagYyr7S3v9xKj1G0CU=.37414079-5a7f-4d29-ba88-40d555738fc1@github.com>
Message-ID: <FYe1PTrEUeYN7jh44QBXcUCofZcq4TB04326mWcBCKo=.09de03a4-64f2-4b08-83b0-1af62f4be026@github.com>

On Fri, 17 Oct 2025 02:59:15 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Thanks for reviewing!
>
> Hmm ... But I find the only use of `value` in `VM_Version::setup_cpu_available_features()` is for `log_debug`:
> 
> 147       log_debug(os, cpu)("Enabled RV64 feature "%s" (%ld)",
> 148              _feature_list[i]->pretty(),
> 149              _feature_list[i]->value());
> 
> Can we simply move this to other methods like `enable_feature()` or `disable_feature()` in the subclasses? These are the places where we do the real enable / disable for them. If that make sense, then we would be able to make `value()` a method only for non-extensions. What do you think?

Good idea. Maybe put them into `update_flag` instead?

@robehn how do you think about it? That means `value()` is only a method in `RVNonExtFeatureValue`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2438800974

From aph at openjdk.org  Fri Oct 17 08:26:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 17 Oct 2025 08:26:02 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <5oj22SX96P_Rw774uZdiw2nN1G1eqbQqBaPuZNXYlX4=.6c146852-2e4d-4157-b6aa-f1698213b2b9@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

Good.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27857#pullrequestreview-3348848310

From rehn at openjdk.org  Fri Oct 17 08:47:06 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 17 Oct 2025 08:47:06 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v4]
In-Reply-To: <FYe1PTrEUeYN7jh44QBXcUCofZcq4TB04326mWcBCKo=.09de03a4-64f2-4b08-83b0-1af62f4be026@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
 <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
 <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>
 <q38yFyEdUVWCXG6tbO6FnPkduagYyr7S3v9xKj1G0CU=.37414079-5a7f-4d29-ba88-40d555738fc1@github.com>
 <FYe1PTrEUeYN7jh44QBXcUCofZcq4TB04326mWcBCKo=.09de03a4-64f2-4b08-83b0-1af62f4be026@github.com>
Message-ID: <fkRgsTaktr158_NQo1vKCkhSAfAqslt1h917Z-g4RAY=.6856608f-3473-462f-ad68-c8b2c2878577@github.com>

On Fri, 17 Oct 2025 08:16:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hmm ... But I find the only use of `value` in `VM_Version::setup_cpu_available_features()` is for `log_debug`:
>> 
>> 147       log_debug(os, cpu)("Enabled RV64 feature "%s" (%ld)",
>> 148              _feature_list[i]->pretty(),
>> 149              _feature_list[i]->value());
>> 
>> Can we simply move this to other methods like `enable_feature()` or `disable_feature()` in the subclasses? These are the places where we do the real enable / disable for them. If that make sense, then we would be able to make `value()` a method only for non-extensions. What do you think?
>
> Good idea. Maybe put them into `update_flag` instead? Or maybe a new method called `log_enabled` in `RVExtFeatures`? I prefer the latter.
> 
> @robehn how do you think about it? That means `value()` is only a method in `RVNonExtFeatureValue`.

Yes, that works.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2438886769

From rcastanedalo at openjdk.org  Fri Oct 17 08:48:02 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 17 Oct 2025 08:48:02 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <tVY1yuVnq5o1v_nCoCsGtvcxcYv_p3Zc9b-MLbBsul4=.04fea942-612a-477e-8f26-08686f1ed0c2@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

Hi Vladimir, I just submitted some Oracle-internal testing to check that the test changes work on other platforms, will come back with the results later today or on Monday the latest, please wait for integration until then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27857#issuecomment-3414477649

From mli at openjdk.org  Fri Oct 17 08:54:21 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Oct 2025 08:54:21 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v5]
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <69v6IXN6mh8D_RYI2f09RclDm2ANtJFBAQwSOG2I1Ss=.60d9c230-80ac-4540-8231-4ed29349efa7@github.com>

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27771/files
  - new: https://git.openjdk.org/jdk/pull/27771/files/6dd4b73f..8d65b7b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27771&range=03-04

  Stats: 20 lines in 2 files changed: 11 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27771/head:pull/27771

PR: https://git.openjdk.org/jdk/pull/27771

From mli at openjdk.org  Fri Oct 17 08:54:23 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Oct 2025 08:54:23 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v5]
In-Reply-To: <fkRgsTaktr158_NQo1vKCkhSAfAqslt1h917Z-g4RAY=.6856608f-3473-462f-ad68-c8b2c2878577@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <kcVCxL616ezCPUDXduxnnaIHA9F-BYVTC1_TXWA-yWw=.13644872-3e59-460e-afcf-93067b7f8419@github.com>
 <1jKclaSWBQjWD6trB4XxJWI6pgWWaclMRHvKWtq0LPo=.eff09c70-7dae-4917-9f5b-c2ce53215026@github.com>
 <NPtil2EN02p4wrEMbzgmsp5dORx4yg_fQrpb0uQHAWc=.75ec79d2-14e9-49b4-be2c-da85be8aea96@github.com>
 <Qe6I8uUXz0Ayayipbvoqt7Wihd56CHHf4sPjGiSVcJo=.52fb71a2-86db-4408-9866-aea0aa2ee1b3@github.com>
 <Ogp8AypF-vYhJ5Ozf80YRcj1dS7vevyY8sneP1b1b9k=.136286e6-a9e8-41b1-b414-4a4a834a3154@github.com>
 <ei4WiE1rKfFWZXa6KipFcqEPtwVY2V2mm-A2WA7J2Kk=.06f1c946-69ca-41b9-b037-5dfc9386254a@github.com>
 <q38yFyEdUVWCXG6tbO6FnPkduagYyr7S3v9xKj1G0CU=.37414079-5a7f-4d29-ba88-40d555738fc1@github.com>
 <FYe1PTrEUeYN7jh44QBXcUCofZcq4TB04326mWcBCKo=.09de03a4-64f2-4b08-83b0-1af62f4be026@github.com>
 <fkRgsTaktr158_NQo1vKCkhSAfAqslt1h917Z-g4RAY=.6856608f-3473-462f-ad68-c8b2c2878577@github.com>
Message-ID: <iLDw5SY_CH2JFOnevBD2w_cWyQsLVsS8P6WkGoNBB_Q=.073941e9-abb1-4d2c-a698-95129a1258d0@github.com>

On Fri, 17 Oct 2025 08:44:12 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Good idea. Maybe put them into `update_flag` instead? Or maybe a new method called `log_enabled` in `RVExtFeatures`? I prefer the latter.
>> 
>> @robehn how do you think about it? That means `value()` is only a method in `RVNonExtFeatureValue`.
>
> Yes, that works.

@robehn Thanks for the quick response!

@RealFYang I choose to add a new method `log_enabled`, let me know how you think about it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27771#discussion_r2438905393

From dbriemann at openjdk.org  Fri Oct 17 09:03:16 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Fri, 17 Oct 2025 09:03:16 GMT
Subject: Integrated: 8369979: Flag UsePopCountInstruction was accidentally
 disabled on PPC64
In-Reply-To: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
References: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
Message-ID: <2dZyh0E2WVfAhvzUPZV0SpdUaCY3_EAyNiLCaOJ6HNU=.f9b8819e-e131-42b2-8fd8-f02ffbe602d3@github.com>

On Thu, 16 Oct 2025 10:01:13 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Reenables the flag UsePopCountInstruction for PPC in `src/hotspot/cpu/ppc/vm_version_ppc.cpp` to reactivate the support for popcount intrinsics on PPC.

This pull request has now been integrated.

Changeset: 9b9559a2
Author:    David Briemann <dbriemann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b9559a2e33827126e1aeab7bf6f4861acaae109
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8369979: Flag UsePopCountInstruction was accidentally disabled on PPC64

Reviewed-by: aph, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/27843

From dbriemann at openjdk.org  Fri Oct 17 09:03:15 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Fri, 17 Oct 2025 09:03:15 GMT
Subject: RFR: 8369979: Flag UsePopCountInstruction was accidentally
 disabled on PPC64
In-Reply-To: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
References: <0DQpdT4SZjZeO01FHePxwY3BO1VcmYb56XMM1h_1owk=.e089cdfa-be90-4a11-b121-e73cfa567a73@github.com>
Message-ID: <qT1dH0q8_HM_dMwFAkmfqdH63UB48dsq3mch4IBR-zg=.c1ad35e8-a359-454f-8e0a-687022498e1e@github.com>

On Thu, 16 Oct 2025 10:01:13 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Reenables the flag UsePopCountInstruction for PPC in `src/hotspot/cpu/ppc/vm_version_ppc.cpp` to reactivate the support for popcount intrinsics on PPC.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27843#issuecomment-3414516566

From sspitsyn at openjdk.org  Fri Oct 17 09:28:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 09:28:05 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
Message-ID: <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>

On Wed, 15 Oct 2025 15:20:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Dont print error message when there are no archived objects
>  - Fix issue in new test
>  - Change is_aot_thread implementation
>  - update AotJdk problem lists

src/hotspot/share/prims/jvmtiExport.cpp line 1476:

> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
> 1475:     return;
> 1476:   }

This has to be okay for now.
It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2439002671

From ayang at openjdk.org  Fri Oct 17 09:36:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:36:18 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <xUgJ5Vw_jUDCJEdtuiZc4-K9nRl4oYFCvnBYTnMmPGo=.874c0422-752a-4539-ba5d-11d144cd5207@github.com>

On Tue, 14 Oct 2025 12:49:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3414639309

From ayang at openjdk.org  Fri Oct 17 09:36:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:36:19 GMT
Subject: Integrated: 8369814: G1: Relax card mark and store ordering
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <pqhUYGsNVyWhOctMkB619N-kZiI1c_keI-Do4zttaSA=.ed0670e9-1b90-42e0-b9f5-2a77e02f1e77@github.com>

On Tue, 14 Oct 2025 09:46:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 0a97bef8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a97bef840f8799313a1a55a65d9334e09cc1cf4
Stats:     123 lines in 11 files changed: 0 ins; 120 del; 3 mod

8369814: G1: Relax card mark and store ordering

Reviewed-by: tschatzl, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/27794

From fyang at openjdk.org  Fri Oct 17 10:34:03 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 17 Oct 2025 10:34:03 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v5]
In-Reply-To: <69v6IXN6mh8D_RYI2f09RclDm2ANtJFBAQwSOG2I1Ss=.60d9c230-80ac-4540-8231-4ed29349efa7@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <69v6IXN6mh8D_RYI2f09RclDm2ANtJFBAQwSOG2I1Ss=.60d9c230-80ac-4540-8231-4ed29349efa7@github.com>
Message-ID: <NpyyNm71uYqdIqV_2ay2IC-BU0a3omZ2t67BLo8rucE=.d7893c75-fd9f-4168-b0b9-df7b2818aeeb@github.com>

On Fri, 17 Oct 2025 08:54:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> @RealFYang 
>> 
>> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
>> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
>> And also do some simple refactoring related to enable/disable/enabled and so on.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Latest version looks good. Thanks for the update.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27771#pullrequestreview-3349374341

From alanb at openjdk.org  Fri Oct 17 10:43:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 10:43:03 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading [v2]
In-Reply-To: <PJ3cVqe9HXJ1qIiTCXDyeh9jQ6tC81t-ienhUiK4bfc=.87bd7486-1302-4f26-aac7-2f2f16af74fe@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>
 <PJ3cVqe9HXJ1qIiTCXDyeh9jQ6tC81t-ienhUiK4bfc=.87bd7486-1302-4f26-aac7-2f2f16af74fe@github.com>
Message-ID: <sIVVQ5GQnxX_KEB59Eo3dyWgMpN7cu8g8CSrRSbteA8=.e54eda03-ddec-4257-ba00-ca65cdf1bf4f@github.com>

On Thu, 16 Oct 2025 21:22:39 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added package and module entries
>
> looking at the current implementation for both jdk.ClassDefine and jdk.ClassLoad events, the "source" metadata recorded by the new event is not available in the (current) calling context for either of the pre-existing events.
> 
> In my opinion adding a new event to capture this information is less intrusive than adding fields(s) to the existing event(s) and contriving to provide the necessary state to those at their current call sites (or by relocating those to a calling context where the "source" is available)

@larry-cable Are you sure adding a new event is the right thing to do? Is it just the implementation challenge? If jdk.ClassDefine were being added today then it seems useful to add the module and the code source (no need for the package as the definedClass gives the fully qualified class name).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3414916266

From mli at openjdk.org  Fri Oct 17 11:25:22 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Oct 2025 11:25:22 GMT
Subject: RFR: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled [v5]
In-Reply-To: <NpyyNm71uYqdIqV_2ay2IC-BU0a3omZ2t67BLo8rucE=.d7893c75-fd9f-4168-b0b9-df7b2818aeeb@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
 <69v6IXN6mh8D_RYI2f09RclDm2ANtJFBAQwSOG2I1Ss=.60d9c230-80ac-4540-8231-4ed29349efa7@github.com>
 <NpyyNm71uYqdIqV_2ay2IC-BU0a3omZ2t67BLo8rucE=.d7893c75-fd9f-4168-b0b9-df7b2818aeeb@github.com>
Message-ID: <evLWZetWBp0UAToghdKKu49mLui3ERPKPTqD3CURz48=.476794c0-e691-4124-905b-af8b4d4489de@github.com>

On Fri, 17 Oct 2025 10:31:34 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Latest version looks good. Thanks for the update.

Thank you for the suggestion and reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27771#issuecomment-3415072153

From mli at openjdk.org  Fri Oct 17 11:25:24 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Oct 2025 11:25:24 GMT
Subject: Integrated: 8369685: RISC-V: refactor code related to
 RVFeatureValue::enabled
In-Reply-To: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
References: <-PvmBAUKBhLlufEx3r8wGN8s60tZ9NjNPesOz6ZjAFE=.5a0ccd74-aadd-4067-b861-78978a6aab80@github.com>
Message-ID: <yaqiglU-g77D2GlrmfPrxf7fRHfdByzq6JnH0_snsEE=.d63cefd0-a106-480b-adaf-f091efeac705@github.com>

On Mon, 13 Oct 2025 13:02:50 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> @RealFYang 
> 
> Original discussion is here: https://github.com/openjdk/jdk/pull/27562#discussion_r2415984981.
> Although seems we can not remove it, but we can still remove some of the redundant check like `mvendorid.enabled()`.
> And also do some simple refactoring related to enable/disable/enabled and so on.
> 
> Thanks

This pull request has now been integrated.

Changeset: e8e2aadd
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8e2aadd9ea302b7b448d0fda9d069d3813f31c5
Stats:     55 lines in 3 files changed: 15 ins; 24 del; 16 mod

8369685: RISC-V: refactor code related to RVFeatureValue::enabled

Reviewed-by: fyang, rehn

-------------

PR: https://git.openjdk.org/jdk/pull/27771

From rcastanedalo at openjdk.org  Fri Oct 17 11:58:02 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 17 Oct 2025 11:58:02 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <RJeTaUVhEEONO26DrG1glX_1yvShrDJCl00Z1M-EcYM=.04dcd139-0c46-41cb-967a-7cc8eebc9792@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

Test results look good!

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27857#pullrequestreview-3349854502

From rcastanedalo at openjdk.org  Fri Oct 17 11:54:09 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 17 Oct 2025 11:54:09 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style
In-Reply-To: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
Message-ID: <9TKpNnrHh3DnhvUWvGQQFDIuIgWFIcyo7En1HcoCGfI=.febc6239-4d54-433d-be30-dc2959c0002a@github.com>

On Wed, 15 Oct 2025 08:14:26 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
> 
> ### Changeset
> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
> - Similarly rename directly related methods in `chaitin.hpp`.
> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
> - Fix a few additional code style issues at lines touched by the changeset.
> 
> Note: this is a syntax-only changeset (no functional changes).
> 
> ### Testing
> 
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

Looks good otherwise!

test/hotspot/gtest/opto/test_regmask.cpp line 586:

> 584: }
> 585: 
> 586: TEST_VM(RegMask, Set_ALL_extended) {

Suggestion:

TEST_VM(RegMask, set_all_extended) {

test/hotspot/gtest/opto/test_regmask.cpp line 599:

> 597: }
> 598: 
> 599: TEST_VM(RegMask, Set_ALL_From_extended) {

Suggestion:

TEST_VM(RegMask, set_all_from_extended) {

test/hotspot/gtest/opto/test_regmask.cpp line 606:

> 604: }
> 605: 
> 606: TEST_VM(RegMask, Set_ALL_From_extended_grow) {

Suggestion:

TEST_VM(RegMask, set_all_from_extended_grow) {

test/hotspot/gtest/opto/test_regmask.cpp line 613:

> 611: }
> 612: 
> 613: TEST_VM(RegMask, Clear_extended) {

Suggestion:

TEST_VM(RegMask, clear_extended) {

test/hotspot/gtest/opto/test_regmask.cpp line 614:

> 612: 
> 613: TEST_VM(RegMask, Clear_extended) {
> 614:   // Check that Clear doesn't leave any stray bits on extended RegMasks.

Suggestion:

  // Check that clear doesn't leave any stray bits on extended RegMasks.

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3349813577
PR Review Comment: https://git.openjdk.org/jdk/pull/27817#discussion_r2439574516
PR Review Comment: https://git.openjdk.org/jdk/pull/27817#discussion_r2439576190
PR Review Comment: https://git.openjdk.org/jdk/pull/27817#discussion_r2439578391
PR Review Comment: https://git.openjdk.org/jdk/pull/27817#discussion_r2439579707
PR Review Comment: https://git.openjdk.org/jdk/pull/27817#discussion_r2439581329

From epeter at openjdk.org  Fri Oct 17 12:54:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 17 Oct 2025 12:54:05 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style
In-Reply-To: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
Message-ID: <XKRUWr0BZKxUtqBjkp8VPvK_OoYaXtYLUG3kdcak6_4=.e2b75d23-638a-41f5-b6d7-8fa12bb18f0e@github.com>

On Wed, 15 Oct 2025 08:14:26 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
> 
> ### Changeset
> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
> - Similarly rename directly related methods in `chaitin.hpp`.
> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
> - Fix a few additional code style issues at lines touched by the changeset.
> 
> Note: this is a syntax-only changeset (no functional changes).
> 
> ### Testing
> 
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

LGTM. Roberto had some good suggestions though, so you should look at those :)

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3350205643

From epeter at openjdk.org  Fri Oct 17 13:02:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 17 Oct 2025 13:02:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
Message-ID: <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>

On Fri, 17 Oct 2025 06:56:43 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:

> 42: 
> 43:     @Param("10000000")
> 44:     private int count;

Drive-by comment / question:
Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2439948821

From dlunden at openjdk.org  Fri Oct 17 14:17:08 2025
From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=)
Date: Fri, 17 Oct 2025 14:17:08 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style [v2]
In-Reply-To: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
Message-ID: <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>

> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
> 
> ### Changeset
> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
> - Similarly rename directly related methods in `chaitin.hpp`.
> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
> - Fix a few additional code style issues at lines touched by the changeset.
> 
> Note: this is a syntax-only changeset (no functional changes).
> 
> ### Testing
> 
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27817/files
  - new: https://git.openjdk.org/jdk/pull/27817/files/1a9c93a9..b44a9a6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27817&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27817&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27817/head:pull/27817

PR: https://git.openjdk.org/jdk/pull/27817

From aseoane at openjdk.org  Fri Oct 17 14:24:20 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Fri, 17 Oct 2025 14:24:20 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style [v2]
In-Reply-To: <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
 <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
Message-ID: <rU0_DoQvP2NakGv2iwYPeDVEvhoJ4X0QiZbU4JO1W_c=.156b7899-429a-44fe-a109-8265e2653a2e@github.com>

On Fri, 17 Oct 2025 14:17:08 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

>> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
>> 
>> ### Changeset
>> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
>> - Similarly rename directly related methods in `chaitin.hpp`.
>> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
>> - Fix a few additional code style issues at lines touched by the changeset.
>> 
>> Note: this is a syntax-only changeset (no functional changes).
>> 
>> ### Testing
>> 
>> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
>> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>
> Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

Marked as reviewed by aseoane (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3350601930

From dlunden at openjdk.org  Fri Oct 17 14:24:23 2025
From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=)
Date: Fri, 17 Oct 2025 14:24:23 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style [v2]
In-Reply-To: <9TKpNnrHh3DnhvUWvGQQFDIuIgWFIcyo7En1HcoCGfI=.febc6239-4d54-433d-be30-dc2959c0002a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
 <9TKpNnrHh3DnhvUWvGQQFDIuIgWFIcyo7En1HcoCGfI=.febc6239-4d54-433d-be30-dc2959c0002a@github.com>
Message-ID: <lxO-PqOqiXuUCnJAxEbBK_KWIJef11LSZeYfh5kJyh8=.08890234-432c-4bd9-b2d3-04c116b24b61@github.com>

On Fri, 17 Oct 2025 11:51:38 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>
>
> Looks good otherwise!

Thanks for the reviews! I've fixed the gtest naming issues @robcasloz caught. Please approve the latest commit and I'll integrate on Monday!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27817#issuecomment-3415806028

From rcastanedalo at openjdk.org  Fri Oct 17 14:24:19 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 17 Oct 2025 14:24:19 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style [v2]
In-Reply-To: <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
 <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
Message-ID: <pz4_6DNGh0b6z8I4zOIw8sbxRt_tyl7djPUH_UmTveE=.703e4234-422e-4278-b34e-96278b31530e@github.com>

On Fri, 17 Oct 2025 14:17:08 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

>> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
>> 
>> ### Changeset
>> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
>> - Similarly rename directly related methods in `chaitin.hpp`.
>> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
>> - Fix a few additional code style issues at lines touched by the changeset.
>> 
>> Note: this is a syntax-only changeset (no functional changes).
>> 
>> ### Testing
>> 
>> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
>> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>
> Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

Marked as reviewed by rcastanedalo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3350595495

From asmehra at openjdk.org  Fri Oct 17 14:46:58 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 17 Oct 2025 14:46:58 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v4]
In-Reply-To: <otENSbKzpH5yH3RBCh1sgQg7tdieB6bJ0XTKjB6ATSA=.a491bb87-36a1-49b8-83a3-be5b01f8e997@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <otENSbKzpH5yH3RBCh1sgQg7tdieB6bJ0XTKjB6ATSA=.a491bb87-36a1-49b8-83a3-be5b01f8e997@github.com>
Message-ID: <IVg1wX34aRwUXuRIJNsIFj0knj-sgF4YC1-zqkx8kJA=.86c196db-6b33-4b99-9485-0c85d83f5182@github.com>

On Thu, 16 Oct 2025 17:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minimal build

Marked as reviewed by asmehra (Committer).

lgtm

-------------

PR Review: https://git.openjdk.org/jdk/pull/27783#pullrequestreview-3350684736
PR Comment: https://git.openjdk.org/jdk/pull/27783#issuecomment-3415892447

From eosterlund at openjdk.org  Fri Oct 17 14:57:09 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 14:57:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v4]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <3DuECXkcrRXiQsS7DmaBxB1AZww_IJr-SbNCcY17uF4=.bc121009-9acc-46b8-8cdf-f0a34fe64e87@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:

 - Test fix
 - move exception marks outside locks
 - Cleanup testing after default change
 - Ioi comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/d6ff880b..0ddc2cc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=02-03

  Stats: 90 lines in 11 files changed: 25 ins; 49 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From eosterlund at openjdk.org  Fri Oct 17 15:03:24 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 15:03:24 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
Message-ID: <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>

On Thu, 16 Oct 2025 01:16:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Dont print error message when there are no archived objects
>>  - Fix issue in new test
>>  - Change is_aot_thread implementation
>>  - update AotJdk problem lists
>
> src/hotspot/share/cds/cds_globals.hpp line 79:
> 
>> 77:           "the CDS archive, in the specified file")                         \
>> 78:                                                                             \
>> 79:   product(bool, AOTStreamableObjects, true,                                 \
> 
> The default should be `false`, as that will be the mode that the user will get with no GC options are specified.

Makes sense. Fixed.

> src/hotspot/share/cds/heapShared.cpp line 355:
> 
>> 353: }
>> 354: 
>> 355: bool HeapShared::is_loading_mapping_mode() {
> 
> I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.
> 
> Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:
> 
> - _is_loading_heap
> - _is_loading_heap_streaming_mode
> 
> The first boolean is the main switch, but most of the code will be checking only the second boolean.

Okay. @stefank is having a look at fixing this.

> src/hotspot/share/cds/heapShared.cpp line 410:
> 
>> 408:       FLAG_SET_ERGO(AOTStreamableObjects, true);
>> 409:       _heap_write_mode = HeapArchiveMode::_streaming;
>> 410:       return;
> 
> This should be changed to `if (!UseZGC) {`, as all other GCs support writing the "mapping" format.

Fixed.

> src/hotspot/share/cds/heapShared.cpp line 418:
> 
>> 416: 
>> 417:   // Select default mode
>> 418:   if (UseG1GC && UseCompressedOops) {
> 
> This is different than specified in JEP 516. The condition should be `if (UseCompressedOops)`.

Okay, I changed it and cleaned up some comments and code suggesting dumping must be done with G1.

> test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 117:
> 
>> 115:                               small2,
>> 116:                               coops,
>> 117:                               "-XX:-AOTStreamableObjects",
> 
> Is this change necessary?

No, I removed it. Nice catch.

> test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java line 147:
> 
>> 145:             // Regardless of which GC dumped the heap, there will be an object archive, either
>> 146:             // created with mapping if dumped with G1, or streaming if dumped with serial GC.
>> 147:             // At exec time, try to load them into a small SerialGC heap that may be too small.
> 
> Actually the original check of `dumpWithSerial == false` was obsolete, as SerialGC can also dump heap objects.  `dumpWithSerial == false` should be removed. The first two lines of comments should also be removed.

Okay, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440306099
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440305408
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440309294
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440308642
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440303912
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440309778

From eosterlund at openjdk.org  Fri Oct 17 15:03:26 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Oct 2025 15:03:26 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
Message-ID: <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>

On Fri, 17 Oct 2025 09:25:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Dont print error message when there are no archived objects
>>  - Fix issue in new test
>>  - Change is_aot_thread implementation
>>  - update AotJdk problem lists
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1476:
> 
>> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
>> 1475:     return;
>> 1476:   }
> 
> This has to be okay for now.
> It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
> Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.

Thanks for the review Serguei! I agree with your assessment. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440313109

From lmesnik at openjdk.org  Fri Oct 17 16:06:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 16:06:43 GMT
Subject: Integrated: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead
In-Reply-To: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
Message-ID: <w9pTTU-3WfN9vkz-sRQzcJi4Gbpp_ZEvGn-MYj5vELM=.ca9da0a0-7d81-47a3-b219-2da962345e43@github.com>

On Thu, 16 Oct 2025 01:55:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

This pull request has now been integrated.

Changeset: 28bf9176
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28bf9176b8d460242bb7cedfb3bde5c6294c56fb
Stats:     70 lines in 18 files changed: 17 ins; 38 del; 15 mod

8348844: Remove remaining JVMTI tests from ProblemList-Virtual, use requires instead

Reviewed-by: dholmes, alanb, syan, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/27834

From dholmes at openjdk.org  Fri Oct 17 16:13:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 16:13:05 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
Message-ID: <f11QojUuRje2OV27YBL71LVkpLe--v9ExYMMBs2r-P0=.b25ea331-26ba-4d08-9f4d-7ddcea7c0e0c@github.com>

On Thu, 16 Oct 2025 22:54:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check jcmd exist

Note that while a PR is in draft mode, no emails get generated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413501278

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:08 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:08 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
Message-ID: <F1N3phFNxogMDSXk4SsN3kRAucfut4cacCBt8-HBeuc=.034dacc6-084d-4550-b9a6-d080b0116628@github.com>

On Tue, 14 Oct 2025 21:31:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadAttach.java line 40:
> 
>> 38: import jdk.test.lib.JDKToolFinder;
>> 39: 
>> 40: public class TestEarlyDynamicLoadAttach {
> 
> We don't usually have individual tests on the 'serviceability' level. 
> Please move test into 'attach' folder. It is test for fix in the attach mechanism.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440491128

From dholmes at openjdk.org  Fri Oct 17 16:13:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 16:13:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
Message-ID: <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>

On Fri, 17 Oct 2025 16:09:54 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - c++
>  - cc
>  - simplfiy
>  - mv to attach
>  - revert
>  - debug
>  - backslash
>  - quote
>  - revert
>  - wip

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 48:

> 46: 
> 47:     char cmd[256];
> 48:     snprintf(cmd, sizeof(cmd), "%s %d help", jcmd_path, PID());

Why are you running the help command instead of `agent_load` ???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2438017610

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:10 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:10 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
 <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>
Message-ID: <9mUt6vbiBvvOJ--6txTUob5bD1f-DGXRUoMDcxjLi-8=.f491c8e1-e4a8-4650-a5d7-4842b7cc99d0@github.com>

On Thu, 16 Oct 2025 22:29:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:
>> 
>>> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
>>> 37:     char cmd[256];
>>> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());
>> 
>> Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.
>
> Also, I'd suggest to convert native part from C to C++. Some examples in the test base can be found easily. There is already a number of tests with C based native agents. We need to convert them to C++ at some point.

Thanks for the suggestion, I changed the test structure so this is not applicable anymore.

Also, converted the native part to c++: 1af09f8ba080416b94aeb947da3a6be1acf9167d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440490778

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:13 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
 <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>
Message-ID: <FhQbA7apcARR_HccYovc4QpGtHl6pH6kPDwhLTZUDKc=.e668c548-e185-4799-a206-52e1095e07cf@github.com>

On Fri, 17 Oct 2025 02:04:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - c++
>>  - cc
>>  - simplfiy
>>  - mv to attach
>>  - revert
>>  - debug
>>  - backslash
>>  - quote
>>  - revert
>>  - wip
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 48:
> 
>> 46: 
>> 47:     char cmd[256];
>> 48:     snprintf(cmd, sizeof(cmd), "%s %d help", jcmd_path, PID());
> 
> Why are you running the help command instead of `agent_load` ???

See my [earlier comment](https://github.com/openjdk/jdk/pull/27766/#issuecomment-3413186002), I'm debugging failures on Windows so my code isn't in a reviewable state. Thus why I marked the PR as draft.

I'll make it ready again as soon as I fix the tests on Windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2438756587

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:02 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:

 - c++
 - cc
 - simplfiy
 - mv to attach
 - revert
 - debug
 - backslash
 - quote
 - revert
 - wip

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/1363424e..1af09f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=08-09

  Stats: 350 lines in 5 files changed: 146 ins; 204 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From aph at openjdk.org  Fri Oct 17 16:17:44 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 17 Oct 2025 16:17:44 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v20]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <gkrTcnPo6BirISb4GXbsHyt0MWALcXgq2oi0XhxbnfU=.0a60eedb-f007-4b0d-bc38-638532c341da@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Check for working WX

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/66f9d04d..a1474ff6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=18-19

  Stats: 7 lines in 2 files changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From fandreuzzi at openjdk.org  Fri Oct 17 16:20:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:20:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
Message-ID: <0SdjN96JipADAZBtK9PznSyfjpNvMyKgDL2mbk9iR4s=.b139b787-8776-4f52-9d0d-30e934bf8d36@github.com>

On Thu, 16 Oct 2025 08:27:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 50:
> 
>> 48: 
>> 49:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
>> 50:         output.shouldHaveExitValue(0);
> 
> Yes but more importantly we should be checking for the "not in live phase" error message.

Fixed in the latest revision

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440519881

From fandreuzzi at openjdk.org  Fri Oct 17 16:25:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:25:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v11]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <i8iBQsurfocx4D3bD-oMCGP1d92Yo7S16s-9Xh5pfAE=.1339ab21-856d-43ba-bd68-10baa0b94f7d@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  msg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/1af09f8b..93667b80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=09-10

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From duke at openjdk.org  Fri Oct 17 17:22:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 17:22:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
 <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>
Message-ID: <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@github.com>

On Fri, 17 Oct 2025 12:59:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:
> 
>> 42: 
>> 43:     @Param("10000000")
>> 44:     private int count;
> 
> Drive-by comment / question:
> Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

The benchmarks listed in the PR description execute tests for data sizes ranging from 16 to 10_000_000 bytes for decryption and encryption.  The difference in performance between the old and new code were within SE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2440660231

From fandreuzzi at openjdk.org  Fri Oct 17 17:53:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 17:53:28 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v12]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <eAzzuSxhvOcZwmxSbrvW9M1vrpMN26e152iq4oGWG_c=.ba73c2a3-5b12-4367-9dfa-a6d04f34e207@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nullptr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/93667b80..2e628c60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From serb at openjdk.org  Fri Oct 17 17:59:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 17:59:09 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
Message-ID: <USXKgcl7grYtjcgrt0fb6JDTFEhlUjcEL9Zov4pr12E=.02afda31-5239-410b-85f7-e7203952a83c@github.com>

On Fri, 10 Jan 2025 13:09:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>> 
>> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
>> build crashes with a failed assert:
>> 
>> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> 
>> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
>> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
>> by normal compilation).
>
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).
> 
> That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.
> 
> The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

@magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416538676

From jwaters at openjdk.org  Fri Oct 17 18:05:09 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Oct 2025 18:05:09 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
Message-ID: <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>

On Fri, 10 Jan 2025 13:09:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>> 
>> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
>> build crashes with a failed assert:
>> 
>> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> 
>> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
>> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
>> by normal compilation).
>
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).
> 
> That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.
> 
> The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

> @magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416555982

From serb at openjdk.org  Fri Oct 17 18:46:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 18:46:13 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>
Message-ID: <28f-0tg_MIRW7NA2_qtYXR9MUdyjMtDNC1ayfih7kJY=.23fb213c-9834-40d9-acaf-00f2a196b4c3@github.com>

On Fri, 17 Oct 2025 18:02:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

But as far I understand it will be much easy to implement for libs, do you know any blockers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3416689798

From sspitsyn at openjdk.org  Fri Oct 17 18:52:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 18:52:07 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <y-Q3n07-dECqNWVhAJx1rbQzoBaVZzOCk_rXEWisg6g=.90e972ef-d62d-4acf-a47f-fa1442886214@github.com>
 <ioISb7v72UXZzYWUar9Jmzn0TPjgsrp4K5aEMcMXJRA=.b4b8b887-92d9-468f-af6d-bc37ec5338e6@github.com>
Message-ID: <jVyfl3kPA_-_-K9KLd0N9hKMmP92A0Su0eIL4-Vr87c=.8cec8f71-6404-4962-b753-fb7142e81c0c@github.com>

On Fri, 17 Oct 2025 15:00:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 1476:
>> 
>>> 1474:     // virtual threads. When exiting it is filtered out due to being hidden.
>>> 1475:     return;
>>> 1476:   }
>> 
>> This has to be okay for now.
>> It can be done in more generic way. For instance, there is a check for `thread->is_hidden_from_external_view()` below which would be nice to have earlier. However, now there is an inconsistency with the flag `is_hidden_from_external_view()` usage we need to address in the near future. So, I'm suggesting to keep this tweak as it is now.
>> Most likely, we need to make sure other JVMTI events are not posted for this thread as well. I can file a separate JVMTI bug on it if it is okay with you.
>
> Thanks for the review Serguei! I agree with your assessment. :)

Good. I've filed a JVMTI bug:
[8370128](https://bugs.openjdk.org/browse/JDK-8370128) AOT thread should not post JVMTI events

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2440915774

From iklam at openjdk.org  Fri Oct 17 19:53:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Oct 2025 19:53:13 GMT
Subject: Integrated: 8369742: Link AOT-linked classes at JVM bootstrap
In-Reply-To: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
Message-ID: <sEv1YTfEckc9K4H-_aUBt2sCn0dIoT9_-2IRw5nzKFQ=.15aad050-5a4c-401e-a2ea-b307cb8a9c6c@github.com>

On Tue, 14 Oct 2025 04:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **PROBLEM**
> 
> If we have an AOT-initialized class like this in java.base
> 
> 
> @AOTSafeClassInitializer
> class Foo {
>     static Bar b = new Bar(); // AOT-cached
>     static void doit() {
>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>     }
> }
> 
> 
> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
> 
> **FIX**
> 
> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
> 
> **NOTES**
> 
> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.

This pull request has now been integrated.

Changeset: 6cd7f30d
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cd7f30d8d4118787401693b8628c72679d37a6a
Stats:     189 lines in 13 files changed: 126 ins; 30 del; 33 mod

8369742: Link AOT-linked classes at JVM bootstrap

Reviewed-by: kvn, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/27783

From iklam at openjdk.org  Fri Oct 17 19:53:12 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Oct 2025 19:53:12 GMT
Subject: RFR: 8369742: Link AOT-linked classes at JVM bootstrap [v3]
In-Reply-To: <NKK2AgYTVsWbjTUjQU10v0cywh4bJN_hZIROj1iALi8=.0d91bce5-908d-468e-83bd-91a9da6d03f7@github.com>
References: <797OwPc-aXsU_yxh5A7FlwkbpEVfvb5sQ6SKRBZ1HPw=.a13861c3-8cba-4fe5-ad8a-e3b1ffa099af@github.com>
 <ozdlolzPMKpWpzqV0f9pPdyChsfG6gHQCoEjPrLG82I=.69f6d217-d7e2-4090-a8e8-debc86104619@github.com>
 <NKK2AgYTVsWbjTUjQU10v0cywh4bJN_hZIROj1iALi8=.0d91bce5-908d-468e-83bd-91a9da6d03f7@github.com>
Message-ID: <gBO1U-P-VY0jGBGQLinOkT5IhdBu1S942SxoN-onQT0=.d3d17444-88e6-4a0f-913f-596b637c6336@github.com>

On Thu, 16 Oct 2025 15:37:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comment - move delay nmethod event posting to nmethod.cpp
>
> Minimal VM build is broken:
> 
> 
> /home/runner/work/jdk/jdk/src/hotspot/share/runtime/threads.cpp:751:14: error: ?post_delayed_compiled_method_load_events? is not a member of ?nmethod?
>   751 |     nmethod::post_delayed_compiled_method_load_events();
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks @vnkozlov @ashu-mehra for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27783#issuecomment-3416893390

From duke at openjdk.org  Fri Oct 17 20:03:18 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Oct 2025 20:03:18 GMT
Subject: RFR: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <XE5evcspaLg3lCYyNFR7w7vYx_KwaUEs7ggfhxba0Q0=.d7f30e01-8b46-4fe3-b1a5-533e3c5e906b@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

@vpa1977 
Your change (at version 38f55c410a57c2f735748338e3882f4e154eba46) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27857#issuecomment-3416921636

From duke at openjdk.org  Fri Oct 17 20:07:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/2ce35b97..1102c609

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=08-09

  Stats: 17 lines in 1 file changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Fri Oct 17 20:07:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>

On Fri, 17 Oct 2025 06:52:44 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
>> 
>>> 909:             }
>>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>>> 911:             sessionK[1] = invGenRoundKeys();
>> 
>> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
>> 
>>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>>         int[][] ks = new int[2][]; // key schedule
>> 
>>         int wLen = (rounds + 1) * WB;
>>         int nk = key.length / WB;
>> 
>>         // generate the round keys for encryption
>>         int[] w = new int[wLen];
>>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>>             w[i] = ((key[j] & 0xFF) << 24)
>>                     | ((key[j + 1] & 0xFF) << 16)
>>                     | ((key[j + 2] & 0xFF) << 8)
>>                     | (key[j + 3] & 0xFF);
>>         }
>>         for (int i = nk; i < wLen; i++) {
>>             int tmp = w[i - 1];
>>             if (i % nk == 0) {
>>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>>             } else if ((nk > 6) && ((i % nk) == WB)) {
>>                 tmp = subWord(tmp);
>>             }
>>             w[i] = w[i - nk] ^ tmp;
>>         }
>>         ks[0] = w;
>> 
>>         // generate the decryption round keys based on encryption ones
>>         int[] dw = new int[wLen];
>>         int[] temp = new int[WB];
>> 
>>         // Intrinsics requires the inverse key expansion to be reverse order
>>         // except for the first and last round key as the first two round keys
>>         // are without a mix column transform.
>>         for (int i = 1; i < rounds; i++) {
>>             System.arraycopy(w, i * WB, temp, 0, WB);
>>             invMixRKey(temp);
>>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>>         }
>>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>>         System.arraycopy(w, 0, dw, 0, WB);
>>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>>         ks[1] = dw;
>>         Arrays.fill(temp, 0);
>> 
>>         return ks;
>>     }
>
> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

I did make changes based on your code to eliminate len and updates to variable names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441096947

From fandreuzzi at openjdk.org  Fri Oct 17 20:16:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 20:16:28 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  fix tool call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/2e628c60..30b2cf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=11-12

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From valeriep at openjdk.org  Fri Oct 17 20:21:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 20:21:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>
Message-ID: <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@github.com>

On Fri, 17 Oct 2025 20:01:21 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.
>
> I did make changes based on your code to eliminate len and updates to variable names.

Yes, I take a second look and maybe a smaller adjustments would work as well. E.g,
1) nit: method name `invGenRoundKeys`  -> `genInvRoundKeys`
2) make this method static by passing `sessionKey[0]` and `rounds` as arguments,
3) no need for `len` since it's always `WB`
4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441139964

From sspitsyn at openjdk.org  Fri Oct 17 21:09:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 21:09:12 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
Message-ID: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>

With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
The following API's are being added with this enhancement:

Introduce:
 - new capability: `can_get_gc_cpu_time`
 - new JVMTI functions:
    - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
    - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`

The related CSR will be created shortly.

Testing:
 - TBD: Mach5 tiers 1-6

-------------

Commit messages:
 - 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime

Changes: https://git.openjdk.org/jdk/pull/27879/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369449
  Stats: 102 lines in 4 files changed: 101 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27879/head:pull/27879

PR: https://git.openjdk.org/jdk/pull/27879

From valeriep at openjdk.org  Fri Oct 17 21:15:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:15:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
Message-ID: <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:

> 43: final class AES_Crypt extends SymmetricCipher {
> 44: 
> 45:     // Number of words in a block

nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441263128

From valeriep at openjdk.org  Fri Oct 17 21:39:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:39:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
Message-ID: <lvnDTYQtlU2Cog7Nh73cg9940Q6emY3n8CTnoKR7vXo=.80347c43-9992-42bc-9c27-56380c8a5726@github.com>

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:

> 132:     };
> 133: 
> 134:     private static final int[] T0 = {

nit: add comment for all these precomputed lookup tables and their usage.

Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441320498

From duke at openjdk.org  Fri Oct 17 22:19:26 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:26 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v11]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <Eru3ph2VIaQUrfafNUbqvChxAekUYdfypR7GYv1st5o=.d9acf2a8-cad2-4e17-8df4-ec496535bdaf@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/1102c609..e0741b17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=09-10

  Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Fri Oct 17 22:19:28 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:28 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
 <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>
Message-ID: <CyofiIE6O8yr1TKC7R-DQRP2qBh5XAJLS5_avs_sdeM=.ef58babb-0ec5-4d9f-a365-f8296fcd0522@github.com>

On Fri, 17 Oct 2025 21:12:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:
> 
>> 43: final class AES_Crypt extends SymmetricCipher {
>> 44: 
>> 45:     // Number of words in a block
> 
> nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

I agree, it should be bytes per word for number of keys (nk) calculation, so BW?  I want to preserved words per block (WB) for maintainability (e.g., if we decide to implement Rijndael-256, where WB = 8).  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:
> 
>> 132:     };
>> 133: 
>> 134:     private static final int[] T0 = {
> 
> nit: add comment for all these precomputed lookup tables and their usage.
> 
> Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

I generated the tables separately, but their usage is referenced in the original specification cited in section 5.2.1.  If made comments indicating of such.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377285
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377328

From duke at openjdk.org  Fri Oct 17 22:59:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 17 Oct 2025 22:59:59 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>

On Fri, 17 Oct 2025 21:02:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Thanks for making this happen! I think it looks good from my point of view, I have just one question, is it safe to skip the check for `os::is_thread_cpu_time_supported`? One might ask why `CPUTimeUsage` does not handle that, but since these methods are also used by internal GC functionality this was intentionally omitted for performance reasons (and some GCs like G1 won't run if thread CPU time is not supported so that call is not always needed). I'm no JVMTI expert so this might be fine, like how its fine for G1 to omit calling it, but just wanted to ask.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27879#pullrequestreview-3352329567

From sspitsyn at openjdk.org  Sat Oct 18 00:45:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:45:01 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
In-Reply-To: <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>
Message-ID: <uCNoQo2-ywSpNobg7MoH-03SNdtmkJiTO9B6rBlMnJo=.128e47e3-c30f-488a-a8bb-2a0a17a8800e@github.com>

On Fri, 17 Oct 2025 22:57:43 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Thanks for making this happen! I think it looks good from my point of view, I have just one question, is it safe to skip the check for os::is_thread_cpu_time_supported? One might ask why CPUTimeUsage does not handle that, but since these methods are also used by internal GC functionality this was intentionally omitted for performance reasons (and some GCs like G1 won't run if thread CPU time is not supported so that call is not always needed). I'm no JVMTI expert so this might be fine, like how its fine for G1 to omit calling it, but just wanted to ask.

Thank you for looking at it and comment! Yes, I was thinking about this check but have not came to any conclusion yet. Yes, I was thinking if this check would be simpler to add to the `CPUTimeUsage` and understand your point about performance reasons. From the other hand it is possible for `CPUTimeUsage::GC::total()` to just always return `-1` if `!os::is_thread_cpu_time_supported()`. While it is better to have it implemented in some common place, I'm not very religious about it and could add it to the JVMTI functions. One problem with that is consistency. There is no such check in the existing JVMTI functions like `GetThreadCpuTime()`,  `GetCurrentThreadCpuTime()`, `GetThreadCpuTimerInfo()` and `GetCurrentThreadCpuTimerInfo()`.
However, I've just added this check to the `GetTotalGCCpuTime()`. Please, let me know your opinion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3417637848

From sspitsyn at openjdk.org  Sat Oct 18 00:50:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:50:59 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v2]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <Istcl5nUS9vt7Rt4aLgbYR-Hn1d8a2r9zlBpNtTYnXE=.a70cab83-4da3-4ffd-8141-65b27df137de@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Review: add os::is_thread_cpu_time_supported() check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/b3bc092f..1fef0d71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27879/head:pull/27879

PR: https://git.openjdk.org/jdk/pull/27879

From sspitsyn at openjdk.org  Sat Oct 18 00:56:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:56:25 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix a typo in GetGCCpuTimerInfo: long => jlong

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/1fef0d71..d816a56d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27879/head:pull/27879

PR: https://git.openjdk.org/jdk/pull/27879

From fyang at openjdk.org  Sat Oct 18 08:35:07 2025
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 18 Oct 2025 08:35:07 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v7]
In-Reply-To: <h8TmlmXesAwID7Mnl8qFcWg2ZaYlFfcr72XByVvtrxo=.15f70e6f-9f13-4a1f-a4da-ae26b2d27f87@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
 <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
 <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>
 <awsyLcrSdQHwSbPZC1mtAuIEsck_2Ng_2UNCySDylAU=.bcc75894-3826-4fd6-9849-2db9fa9d856b@github.com>
 <h8TmlmXesAwID7Mnl8qFcWg2ZaYlFfcr72XByVvtrxo=.15f70e6f-9f13-4a1f-a4da-ae26b2d27f87@github.com>
Message-ID: <P6qXdJkF2FCFHmKevbIE_dP5IAdl5ydwFPO-s0Em7wo=.4c47aff0-2dae-44af-b7e8-b01b8a14c360@github.com>

On Tue, 14 Oct 2025 11:04:38 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> Oh, I misunderstood, I will try to check the rule and test tier1
>
> This AvoidUnalignedAccesses Flag is defined in ARCH_FLAGS, I think it will only affect riscv arch. and after using the alternative flag !UseUnalignedAccesses, it seems there is no need for it in the hotspot/cpu/riscv, we can hold on for a while to wait for others comments.
> 
> besides, I have  test-tier1 tests passed with or without deleting this  : )

AFAIK, you need a CSR when removing a product flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2441819942

From fandreuzzi at openjdk.org  Sat Oct 18 09:54:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 18 Oct 2025 09:54:05 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
Message-ID: <7dJKHoq6_LDsL_BAaorip6w78YYI_bh1qY5jWeb2ehk=.44cfd4c7-1111-4422-a3ad-aba03ca05d99@github.com>

On Sat, 11 Oct 2025 18:25:48 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update foundOne

Marking as draft, I'll take some measurements to check if removing nmethod entry barriers for native stubs gives a measurable benefit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27742#issuecomment-3418137388

From fandreuzzi at openjdk.org  Sat Oct 18 10:16:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 18 Oct 2025 10:16:02 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
 <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
Message-ID: <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>

On Thu, 16 Oct 2025 23:40:08 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> We could instead allow them to be cleaned up like regular nmethods.
>> 
>> That sounds reasonable to me, native methods seem to be tracked like all other nmethods. 
>> 
>> Removing `is_native_method()` altogether from the condition was the first implementation I had, and as far as I remember there was no failure in tier1 or tier2. Should I propose this alternative implementation as part of this PR?
>
> I am tempted to say yes, for consistency, but it probably won't make much of a difference either way.  But now I am wondering, if these cold native wrappers continue to be immortal, then do they really need to give them nmethod entry barriers?  Removing the barrier could remove some overhead.  Whatever direction we decide to go, it would be good to add a comment here explaining the decision and/or trade-offs.

Is it actually possible to remove entry barriers for _any_ garbage collectible nmethod? How can we know an nmethod is not used anymore, even when it is made not entrant? `is_cold()` bails out when an nmethod does not support entry barriers:

// On platforms that don't support nmethod entry barriers, we can't
// trust the temporal aspect of the gc epochs. So we can't detect
// cold nmethods on such platforms.

So, the decision of removing entry barriers for native nmethods would make the memory leak I'm trying to fix here effectively unfixable? Let me know if I'm missing something.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2442009918

From kbarrett at openjdk.org  Sat Oct 18 16:29:05 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 18 Oct 2025 16:29:05 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
Message-ID: <yH4FbmkSTgT1Je3t8Gul-I3AgDkyWIALTHez83FIvTQ=.bddce6c0-9c53-487b-a010-cbeeea80df47@github.com>

On Thu, 16 Oct 2025 14:45:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds the type Atomic<T>, to use as the type
>> of a variable that is accessed (including writes) concurrently by multiple
>> threads. This is intended to replace (most) uses of the current HotSpot idiom
>> of declaring a variable volatile and accessing that variable using functions
>> from the AtomicAccess class.
>> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
>> 
>> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
>> 
>> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
>> operationally the same, with the same API, hence uses and gtests didn't need
>> to change in that respect. Thanks to @stefank for raising this issue, and for
>> some suggestions toward improvements.
>> 
>> * Changed how fetch_then_set for atomic translated types is handled, to avoid
>> having the function there at all if it isn't usable, rather than just removing
>> it via SFINAE, leaving an empty overload set.
>> 
>> * Added more gtests.
>> 
>> Testing: mach5 tier1-6, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default construct translated atomic without SFINAE

After a lot of Oracle-internal discussion, I'm proposing the `relaxed_store`
function in this PR be changed to `store_relaxed`. I'm going to hold off on
making that change for a bit, to give folks not in on that internal-to-Oracle
discussion an opportunity to weigh in. (I noticed that @theRealAph  liked the
suggestion of "unordered" in an earlier comment.)

Summarizing that discussion, here are goals and rationale for this change:

1. Have an explicit qualifier describing the behavior of the store. Some folks
have a strong preference for being explicit. Some folks have a preference for
the shorter `store` name (and `load` instead of `load_relaxed`), consistent
with `AtomicAccess`. It was agreed that the `AtomicAccess` names should be
updated to match, once the conversion to using `Atomic<T>` has been done.

2. Use the term "relaxed" for that qualifier. C, C++, and Rust use that
terminology. HotSpot uses `memory_order_relaxed` to be consistent with C++.
Java uses "opaque", but some felt that wasn't suggestive of any particular
behavior. Various other options (including "unordered" and "unfenced") were
considered, but none were sufficiently popular to overcome existing precedent.

3. Avoid visual ambiguity with `release_store`. This is the issue that started
the discussion.

There was some discussion of the "inconsistency" of `release_store` vs
`store_relaxed`, with the qualifier being in different positions. It was
suggested that, for naming consistency, all load/store qualifiers should
follow the operation. A noted benefit was that IDE name completion works well
in that case. But there was strong strong preference by some for
`release_store`, as it suggests the store is ordered with respect to preceding
operations. (And `load_aquire` orders the load with respect to following
operations.) The "relaxed" variants don't provide any ordering, so the
placement of the qualifier is unimportant in that regard. And "consistent"
placement leads to the visual ambiguity issue. The existence of
`release_store_fence` also makes any consistency argument look pretty weak.

In the dicussion about using "unordered" it was noted that our Access API uses
`MO_RELAXED` for atomic accesses without barriers, and `MO_UNORDERED` for
"plain" accesses. It's not obvious from the names how those differ, and
perhaps the name `MO_UNORDERED` should be reconsidered. But that's a separate
issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3418630518

From kbarrett at openjdk.org  Sat Oct 18 17:11:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 18 Oct 2025 17:11:48 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' into stdlib-header-wrappers
 - Merge branch 'master' into stdlib-header-wrappers
 - Merge branch 'master' into stdlib-header-wrappers
 - jrose comments
 - move tuple to undecided category
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

-------------

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=03
  Stats: 670 lines in 68 files changed: 430 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

PR: https://git.openjdk.org/jdk/pull/27601

From lmesnik at openjdk.org  Sat Oct 18 17:14:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Oct 2025 17:14:35 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
Message-ID: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>

The problem happens when jni access fields while the last java frame is still compiled. The field access/modification events require interp only mode and compiled frame is not expected. However,  It might happens if thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 

The original example doesn't reproduce issue because of JDK changes but the problem exists in JVMTI. So I implemented reliable regression test. 

The location should be zero for JNI access.

-------------

Commit messages:
 - the new test added
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8224852
 - logging fixed
 - minor fixes
 - 8224852: JVM crash on watched field access from native code

Changes: https://git.openjdk.org/jdk/pull/27584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224852
  Stats: 348 lines in 4 files changed: 341 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27584/head:pull/27584

PR: https://git.openjdk.org/jdk/pull/27584

From duke at openjdk.org  Sun Oct 19 02:18:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/e0741b17..5ea6933b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=10-11

  Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Sun Oct 19 02:18:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>
 <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@github.com>
Message-ID: <7kU60fP_Aw4oiwfwMN48YfFwC70wVObcHQpSXqZvyC4=.5094fe4c-de7e-4a96-8000-121a9db66ae5@github.com>

On Fri, 17 Oct 2025 20:18:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I did make changes based on your code to eliminate len and updates to variable names.
>
> Yes, I take a second look and maybe a smaller adjustments would work as well. E.g,
> 1) nit: method name `invGenRoundKeys`  -> `genInvRoundKeys`
> 2) make this method static by passing `sessionKey[0]` and `rounds` as arguments,
> 3) no need for `len` since it's always `WB`
> 4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result.

Sorry, missed this comment in the melee.  Re: 1) method name, agreed; 2) to static, agreed; 3) remove len, prior commit; 4) variable name alignment, agreed.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2442722654

From eastigeevich at openjdk.org  Sun Oct 19 08:53:02 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 19 Oct 2025 08:53:02 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <9idT2wdo-uuG1seABSR_6Mr0S_ygFBmeAbL6hK2QwCg=.343f6868-486a-4407-ab43-f6236a504e37@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
 <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
 <BXFr-z1N5W3SNcz5tsk8CrEPmyqQ--8bUOnOAeyWpWA=.01e9e25c-5bc4-468e-8411-7c9ecc0de0d5@github.com>
 <9idT2wdo-uuG1seABSR_6Mr0S_ygFBmeAbL6hK2QwCg=.343f6868-486a-4407-ab43-f6236a504e37@github.com>
Message-ID: <Hp6QSEOFv7waYk3jwFx3KG23xtjzuT2sAkaudjd529k=.22cd0b09-bcab-4083-bbeb-fd8e2da5af5b@github.com>

On Thu, 16 Oct 2025 23:22:22 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @eastig , I'm a bit stuck on [`gen_continuation_enter()`](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L1059). I can't figure out what the target of this static call is. Are you familiar with this portion of the codebase by any chance?
>
> The target is Continuation::enter(), thanks to LinkResolver::resolve_continuation_enter().

Thank you @dean-long 

@mikabl-arm ,  it looks like we should allow `nullptr` for `callee` at the time of trampoline requested. We don't have `ciMethod`. Getting some kind of it might involve linking. In case of `gen_continuation_enter()` we don't save much vs adding complexity to Hotspot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2443033080

From alanb at openjdk.org  Sun Oct 19 10:25:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Oct 2025 10:25:01 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> There is also interest to get the same performance data from JVMTI.

Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.

I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

(n passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419554152

From mgronlun at openjdk.org  Sun Oct 19 12:23:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 19 Oct 2025 12:23:05 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading [v2]
In-Reply-To: <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
 <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com>
Message-ID: <IAB-D3fiFOAiok_Fov3gSpBlwZDWUZ0rKL69mmv5dGg=.247c845a-2832-4bd9-a9f7-7ffb0944b376@github.com>

On Thu, 16 Oct 2025 19:41:15 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
>> 
>> The location of the class file for a class defined can be of utility in both debugging and auditing.
>> 
>> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added package and module entries

Package and Module information is implicitly included in the JFR model for a class (its transitive dependencies), so you do not need to include them explicitly.

I prefer that the design address how the source information is to be included for the existing events (ClassLoad and ClassDefine). 

I am working on a symbol table implementation to help you out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3419623850

From aph at openjdk.org  Sun Oct 19 14:23:01 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 19 Oct 2025 14:23:01 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <yH4FbmkSTgT1Je3t8Gul-I3AgDkyWIALTHez83FIvTQ=.bddce6c0-9c53-487b-a010-cbeeea80df47@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
 <yH4FbmkSTgT1Je3t8Gul-I3AgDkyWIALTHez83FIvTQ=.bddce6c0-9c53-487b-a010-cbeeea80df47@github.com>
Message-ID: <ZwyZPvp_Jr4j9LfKhM8jLG4jWfsQTPgSvBZjCt8Sc6k=.af3b14ce-6df4-48d5-806f-873910915e5e@github.com>

On Sat, 18 Oct 2025 16:26:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> After a lot of Oracle-internal discussion, I'm proposing the `relaxed_store`
> function in this PR be changed to `store_relaxed`. I'm going to hold off on
> making that change for a bit, to give folks not in on that internal-to-Oracle
> discussion an opportunity to weigh in. (I noticed that @theRealAph liked the
> suggestion of "unordered" in an earlier comment.)

`store_relaxed` sounds good to me. It has the great advantage of being unlikely
to require people to have to search for its meaning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3419704866

From duke at openjdk.org  Sun Oct 19 15:40:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 15:40:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
Message-ID: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>

On Sun, 19 Oct 2025 10:21:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

Certainly, thanks for asking. Researchers in GC are using the GC start/end events (https://dl.acm.org/doi/10.1145/3669940.3707217, https://ieeexplore.ieee.org/document/9804613, https://dl.acm.org/doi/10.1145/3764118, https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various costs pertaining to GC. I believe one USP of using a JVMTI agent is that it does not require modification of the benchmarking code and allows usage of powerful features made available by framework such as libpfm. 

So these JVMTI hooks are used to read CPU performance counters to get some estimations of various metrics, be it CPU time, cache-misses etc. However this imposes severe limitations especially when it comes GCs with concurrent parts. This patch will expand the capabilities for these users using JVMTI agents to profile applications.

> there aren't functions to get the process CPU time for example

I think there is no need for JVMTI to export such functionality as it should be trivial for a C/C++ application to get process CPU time through other means. However getting GC CPU time (outside the scope of stop-the-world) would be less trivial without this patch.

> JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

I believe JVMTI is still relevant for profiling as it is being used in the GC research community.

On a general note, I think exposing GC CPU time at various APIs will serve a different scope of users. At this level we support users that uses advanced profiling techniques with external libraries.

Hope this helps.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419754679

From duke at openjdk.org  Sun Oct 19 16:42:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 16:42:10 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmtiH.xsl line 120:

> 118:     JVMTI_VERSION_19  = 0x30130000,
> 119:     JVMTI_VERSION_21  = 0x30150000,
> 120:     JVMTI_VERSION_25  = 0x30170000,

Should this be `JVMTI_VERSION_26` if this is targeted for version 26?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443390372

From duke at openjdk.org  Sun Oct 19 17:06:06 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 17:06:06 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <GaCutHRWuK72QjyBX-RPYIqjZycVAHURB5vd6HDuNWo=.d2b9dc5d-69f7-4c7a-bd4c-dd5e63489caa@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmtiManageCapabilities.cpp line 95:

> 93:     jc.can_get_current_thread_cpu_time = 1;
> 94:     jc.can_get_thread_cpu_time = 1;
> 95:     jc.can_get_gc_cpu_time = 1;

I'm wondering, would a user trying to call `GetTotalGCCpuTime` if `can_get_gc_cpu_time` is not successfully set to 1 be undefined behavior? The specs say "To possess a capability, the agent must add the capability (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#capability). If yes maybe we can discard the extra call to `os::is_thread_cpu_time_supported` in `JvmtiEnv::GetTotalGCCpuTime`? That seems to align with the pattern to not have that check in the other methods as you pointed out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443399514

From duke at openjdk.org  Sun Oct 19 17:46:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 17:46:10 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <Q4FpxJ60YhHKrh2fd-nbaae6c8EwyC-vZI7FDK7TI0M=.ca2ccca3-0d25-4bfc-8835-16fd466906b5@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmti.xml line 11234:

> 11232:     </function>
> 11233: 
> 11234:     <function id="GetGCCpuTimerInfo" phase="any" callbacksafe="safe" num="157" since="26">

Should this be called `GetTotalGCCpuTimerInfo`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443414405

From duke at openjdk.org  Sun Oct 19 18:45:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 18:45:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

There may be two issues with the patch as is:

Calling `GetTotalGCCpuTime` in `Agent_OnLoad` can cause crash (since `CollectedHeap::gc_threads_do` do not protect against races on VM startup/shutdown).

If `GetTotalGCCpuTime` is invoked in a callback for GC start/end, this will cause a deadlock as the `Heap_lock` is already held. The `MutexLocker hl(Heap_lock)` pattern was introduced to avoid races that could happen from internal usage in G1 of `CPUTimeUsage::GC::total()` during shutdown. I could recall this wrong but I think the usage `Heap_lock` (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of `Universe::_is_shutting_down`. I will ask @walulyai for his thoughts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419871071

From wenanjian at openjdk.org  Mon Oct 20 03:33:15 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Mon, 20 Oct 2025 03:33:15 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v7]
In-Reply-To: <P6qXdJkF2FCFHmKevbIE_dP5IAdl5ydwFPO-s0Em7wo=.4c47aff0-2dae-44af-b7e8-b01b8a14c360@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <gST6O4AD7uNdCVXZRZTHahZl9U-ZQ3kGXojI6nLHkSk=.37d05b1d-df04-4ce1-bc6c-d450e11ee6a3@github.com>
 <GSt1JjOZ4XArqMmPQOhwEE8cW_CYabvLYamsZ1Ni60E=.189bac13-9402-41eb-bb25-3d9a903ec837@github.com>
 <YPVGKBm2SxaptXjgWSi32t87141APVqsXjBdVJzCL2s=.c5fdc857-c452-4dff-812e-232fc9f68447@github.com>
 <XKFGYt4qz9gqKTKaIot-LXxXEyIHLTvchGM4-VZ9r9k=.6df89fc9-f7eb-4a28-bafe-537717f27bf8@github.com>
 <awsyLcrSdQHwSbPZC1mtAuIEsck_2Ng_2UNCySDylAU=.bcc75894-3826-4fd6-9849-2db9fa9d856b@github.com>
 <h8TmlmXesAwID7Mnl8qFcWg2ZaYlFfcr72XByVvtrxo=.15f70e6f-9f13-4a1f-a4da-ae26b2d27f87@github.com>
 <P6qXdJkF2FCFHmKevbIE_dP5IAdl5ydwFPO-s0Em7wo=.4c47aff0-2dae-44af-b7e8-b01b8a14c360@github.com>
Message-ID: <1cMHK3VtzhMYRbx5N-GRoY8rDAwy7uweroFrphTaN0A=.95f92dde-698b-478e-88dc-309dd49a9cbd@github.com>

On Sat, 18 Oct 2025 08:32:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This AvoidUnalignedAccesses Flag is defined in ARCH_FLAGS, I think it will only affect riscv arch. and after using the alternative flag !UseUnalignedAccesses, it seems there is no need for it in the hotspot/cpu/riscv, we can hold on for a while to wait for others comments.
>> 
>> besides, I have  test-tier1 tests passed with or without deleting this  : )
>
> AFAIK, you need a CSR when removing a product flag.

@RealFYang Thanks?Already added a CSR issue for the flag remove

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27510#discussion_r2443741551

From dzhang at openjdk.org  Mon Oct 20 04:01:04 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 20 Oct 2025 04:01:04 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <f2SeL3ZWytJAmyjbgnnz_pREEH0gA5uW3hyf9MtL8D8=.57b1cf62-742e-4fd2-8894-ec980f359844@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
 <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
 <UHR_QMk3BOsqMglcPIm2ENYYhg7es7S6DWr54kQkqOs=.d5b69afe-ed04-4dbb-9943-f8c7863ff1d3@github.com>
 <DoIicmWfNmLt0XbsbbQLKPqwOqyQBy-QTwgdeGWq2kE=.1fd42f87-49c7-4d17-a8d0-f811f402eb94@github.com>
 <f2SeL3ZWytJAmyjbgnnz_pREEH0gA5uW3hyf9MtL8D8=.57b1cf62-742e-4fd2-8894-ec980f359844@github.com>
Message-ID: <KwaIgp3-O8nTuu_aRaZi_AnpxbdkWe4kRBo4fe2DLTQ=.ba2e0584-5fef-4c6b-9aca-13b48d08c403@github.com>

On Thu, 16 Oct 2025 21:20:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I'm strongly in favor of improving detection logic. In the worst case, it would require performing a misaligned vector access during VM bootstrapping and checking whether it traps or not.

That makes sense to me. I will try to improve the detection making it more reliable on old kernels without good hwprobe support. I think performing a misaligned vector access during VM bootstrapping and checking whether it traps or not is a good way. Thanks for the suggestion!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2443765140

From dholmes at openjdk.org  Mon Oct 20 04:48:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Oct 2025 04:48:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <M2u2LiPE7eCtO2uxXoHlB6fZ0BS3FYWGf4DHi0-XqAg=.93fc881a-5e46-474c-9abe-3316966ad71c@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

I have a few issues with the spec and implementation, but they are easily addressed.

I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take hs word for it.

src/hotspot/share/prims/jvmti.xml line 11288:

> 11286:             On return, points to the time in nanoseconds.
> 11287:             This is an unsigned value.  If tested or printed as a jlong (signed value)
> 11288:             it may appear to be a negative number.

This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

src/hotspot/share/prims/jvmtiEnv.cpp line 3802:

> 3800:   {
> 3801:     MutexLocker hl(Heap_lock);
> 3802:     if (!os::is_thread_cpu_time_supported() ||

If it isn't supported then you can't have the capability and so won't reach here.

src/hotspot/share/prims/jvmtiEnv.cpp line 3804:

> 3802:     if (!os::is_thread_cpu_time_supported() ||
> 3803:         Universe::heap()->is_shutting_down()) {
> 3804:       *nanos_ptr = -1;

This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27879#pullrequestreview-3354987972
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443784044
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443799741
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443800932

From dholmes at openjdk.org  Mon Oct 20 04:48:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Oct 2025 04:48:06 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>
Message-ID: <bicbqp9p2-oF7cYx-bqPivKSuffHoLukGKT-AjVu-B4=.0fbba7bb-fd01-4863-a72f-3762cfe23ace@github.com>

On Sun, 19 Oct 2025 16:39:34 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix a typo in GetGCCpuTimerInfo: long => jlong
>
> src/hotspot/share/prims/jvmtiH.xsl line 120:
> 
>> 118:     JVMTI_VERSION_19  = 0x30130000,
>> 119:     JVMTI_VERSION_21  = 0x30150000,
>> 120:     JVMTI_VERSION_25  = 0x30170000,
> 
> Should this be `JVMTI_VERSION_26` if this is targeted for version 26?

Also the hex value represents JDK 23 not 25.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443789919

From epeter at openjdk.org  Mon Oct 20 05:59:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 20 Oct 2025 05:59:07 GMT
Subject: RFR: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style [v2]
In-Reply-To: <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
 <8KTiD_-r-3Z3BrfjO2hghq5rdPEukPFQ1TIwDnIvM90=.a2b6d535-38ce-4184-a67a-5dcce6c4d6b7@github.com>
Message-ID: <gFiupmDXGoTnu4yzzDA3ao_rFw5xwVliZRbk53avbyE=.26956a94-9ada-4f96-a31f-b284e2ecac79@github.com>

On Fri, 17 Oct 2025 14:17:08 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

>> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
>> 
>> ### Changeset
>> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
>> - Similarly rename directly related methods in `chaitin.hpp`.
>> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
>> - Fix a few additional code style issues at lines touched by the changeset.
>> 
>> Note: this is a syntax-only changeset (no functional changes).
>> 
>> ### Testing
>> 
>> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
>> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>
> Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

Marked as reviewed by epeter (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27817#pullrequestreview-3355094444

From rrich at openjdk.org  Mon Oct 20 06:33:02 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 20 Oct 2025 06:33:02 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: <sJzFRqYl_RYBg6PMCb0IjOrWPyrLQMx8iVqpWwcba4k=.1cf5f930-8529-4367-9b7a-ee7dc070f111@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <zzGalP0qaZEuS1TsUAVZl82qZrU8FG8s4jRMl4O9GLM=.a772aa70-0dd6-4daa-bc69-bb5d8205d6cc@github.com>
 <sJzFRqYl_RYBg6PMCb0IjOrWPyrLQMx8iVqpWwcba4k=.1cf5f930-8529-4367-9b7a-ee7dc070f111@github.com>
Message-ID: <bZJ-GybjKzh4nEhaAm5bG2akNuqa9rWX1MdP27sndrw=.fc258a79-3a9b-485e-a3c0-5c8185a430c5@github.com>

On Tue, 14 Oct 2025 20:20:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/27676 has been integrated which requires resolution.
>
>> #27676 has been integrated which requires resolution.
>>
> Thanks, merged with latest master.

@pchilano I've finished the ppc part: https://github.com/reinrich/jdk/commit/99b96528539dd7239711d9c70aebb1a4c1a7fdfe

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3420740434

From azafari at openjdk.org  Mon Oct 20 07:37:07 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:37:07 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
Message-ID: <ULP4C2zdfAlLsafjiTtVynzIGrlsWCaZPl5ZHfmmyPE=.02b40dc3-8b20-4ad6-a6df-30a4d37860c9@github.com>

On Thu, 18 Sep 2025 15:37:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed MAX2 template parameter

It seems that this PR is diverging in some (un)related changes. I suggest to define separate new RFEs per issues found here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3420919024

From azafari at openjdk.org  Mon Oct 20 07:37:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:37:10 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
 <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>
Message-ID: <1p0PZb6EijjJFhDHDraj1Xh522GehuN9XifO-rReyMw=.ab35fbf1-a00f-4218-9780-1b38f83a0291@github.com>

On Thu, 9 Oct 2025 01:55:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed MAX2 template parameter
>
> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
> 
>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>> 288:   if (value + MaxHeapSize < MaxHeapSize) { // overflow
> 
> Sorry I am struggling to see how this check differs in practice to the existing check:
> 
> (value > (max_uintx - MaxHeapSize))
> 
> Further, the comment before the new check seems to relate to the existing check.

Sorry it's my mistake in reading `max - a < b` as `a - b < b` .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2444032200

From dlunden at openjdk.org  Mon Oct 20 07:52:15 2025
From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=)
Date: Mon, 20 Oct 2025 07:52:15 GMT
Subject: Integrated: 8369569: Rename methods in regmask.hpp to conform with
 HotSpot coding style
In-Reply-To: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
References: <qBk41uaMD-lCYw2MkUuharT4EQoY7BgW_q21CU-jUvc=.859dd7ba-8c23-45df-a871-af347213cd4a@github.com>
Message-ID: <4HdU0eHdahImR-MduNI1PiA9ngjNKjjmaYGXpH3GlLM=.9ef1cee9-70c7-4709-8e58-3e4f1e8dd1ba@github.com>

On Wed, 15 Oct 2025 08:14:26 GMT, Daniel Lund?n <dlunden at openjdk.org> wrote:

> A number of methods in regmask.hpp do not conform with the HotSpot coding style. We should make sure they do.
> 
> ### Changeset
> - Rename methods in `regmask.hpp` to conform with HotSpot coding style.
> - Similarly rename directly related methods in `chaitin.hpp`.
> - Rename the constant register masks `All` and `Empty` to `ALL` and `EMPTY`.
> - Fix a few additional code style issues at lines touched by the changeset.
> 
> Note: this is a syntax-only changeset (no functional changes).
> 
> ### Testing
> 
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18500704336)
> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.

This pull request has now been integrated.

Changeset: 39211e7f
Author:    Daniel Lund?n <dlunden at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39211e7fac74a30c343987e2ef17ab5d855a73dc
Stats:     629 lines in 31 files changed: 12 ins; 0 del; 617 mod

8369569: Rename methods in regmask.hpp to conform with HotSpot coding style

Reviewed-by: aseoane, rcastanedalo, epeter

-------------

PR: https://git.openjdk.org/jdk/pull/27817

From azafari at openjdk.org  Mon Oct 20 07:54:40 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:54:40 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
Message-ID: <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>

> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
> The acceptable value is changed to 64K.
> 
> Tests:
> linux-x64 tier1

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  subtraction for checking overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26955/files
  - new: https://git.openjdk.org/jdk/pull/26955/files/3dfa9765..d0300291

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955

PR: https://git.openjdk.org/jdk/pull/26955

From vpetko at openjdk.org  Mon Oct 20 08:09:18 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 20 Oct 2025 08:09:18 GMT
Subject: Integrated: 8370049: [s390x] G1 barrier compareAndExchange does not
 return old value when compareExchange fails
In-Reply-To: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
References: <0BQDpWdCV63CljNDZIOkSKbULAiZbAdzr5YNU5xgdrs=.9d71dd24-8718-4fb1-bd69-34e19d43d35b@github.com>
Message-ID: <RxP_yqrrHd73adW7GuvTINcQZZlykyAFn-g-kdls7eM=.95ac3603-27cb-4cd1-a74b-c26107572f4f@github.com>

On Thu, 16 Oct 2025 22:55:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR fixes typo in `src/hotspot/cpu/s390/gc/g1/g1_s390.ad` that caused `compareAndExchange` return expected value instead of old value when compareAndExchange failed.
> It updates jtreg test to include negative tests for compareAndExchange and compareAndSwap g1 barriers.
> 
> Testing (s390x) :
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java
>                                                          1     1     0     0     0   
> ==============================
> TEST SUCCESS
> 
> Tier1 summary:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>    jtreg:test/hotspot/jtreg:tier1                     3118  2466     0     0   652   
>    jtreg:test/jdk:tier1                               2518  2418     0     0   100   
>    jtreg:test/langtools:tier1                         4672  4662     0     0    10   
>    jtreg:test/jaxp:tier1                                 0     0     0     0     0   
>    jtreg:test/lib-test:tier1                            38    38     0     0     0   
> ==============================
> TEST SUCCESS
> 
> 
> Tier 2 tests contain unrelated failures:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
>>> jtreg:test/hotspot/jtreg:tier2                      960   766     1     0   193 <<
>>> jtreg:test/jdk:tier2                               4455  4203     5     0   247 <<
>    jtreg:test/langtools:tier2                           14    12     0     0     2   
>    jtreg:test/jaxp:tier2                               517   516     0     0     1   
>    jtreg:test/docs:tier2                                 4     0     0     0     4   
> ==============================
> TEST FAILURE
> 
> jtreg:test/hotspot/jtreg:tier2:
> 1. ``applications/ctw/modules/jdk_jfr.java                                                      Failed. Execution failed: `main' threw exception: java.lang.AssertionError: There were 1 errors:[{modules_jdk_jfr_0: failed during compilation of class #226 : jdk/jfr/internal/jfc/JFC}]`` - existing issue https://bugs.openjdk.org/browse/JDK-8352567 
> 
> jtreg:test/jdk:tier2:
> 1. ``java/net/Inet6Address/B6206527.java                                                                  ...

This pull request has now been integrated.

Changeset: 5609ee11
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5609ee11a2daf888d02c0c1b2b70eb4df817582c
Stats:     21 lines in 2 files changed: 20 ins; 0 del; 1 mod

8370049: [s390x] G1 barrier compareAndExchange does not return old value when compareExchange fails

Reviewed-by: amitkumar, aph, rcastanedalo

-------------

PR: https://git.openjdk.org/jdk/pull/27857

From thartmann at openjdk.org  Mon Oct 20 09:04:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 09:04:05 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
 <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
Message-ID: <xxNhE1D3x3BKBDaPG8xJfkABkAaFnlXA55vPtymJ5bk=.26acc27f-23c3-408e-bf9f-f4fdfb5619d6@github.com>

On Wed, 8 Oct 2025 23:17:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete test/hotspot/jtreg/compiler/exceptions/a

That looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27683#pullrequestreview-3355578028

From lkorinth at openjdk.org  Mon Oct 20 09:18:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 20 Oct 2025 09:18:08 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

I think this is a nice way forward. I would have liked more of the c++ library included (like tuples, optional and expected), but this is a good start.

Thanks for putting so much effort into this!!!

-------------

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3355641379

From adinn at openjdk.org  Mon Oct 20 09:27:16 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 20 Oct 2025 09:27:16 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
Message-ID: <FYcC9eKk5aGJH74Vbv6X9QKyMbpsDID6gWi_RlwMZKg=.a5f2140e-ada0-4dbf-918f-dff1721693e6@github.com>

On Wed, 15 Oct 2025 14:00:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge from the main branch
>>  - Address review comments
>>  - Address review comments
>>  - Address review comments
>>  - The patch is contributed by @TheRealMDoerr
>>  - Offset the deoptimization handler entry point
>>    
>>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>>  - Revert "Ensure stub code is not adjacent to a call"
>>  - Ensure stub code is not adjacent to a call
>>  - Address review comments
>>  - 8365047: Remove exception handler stub code in C2
>>    
>>    The C2 exception handler stub code is only a trampoline to the
>>    generated exception handler blob. This change removes the extra
>>    step on the way to the generated blob.
>>    
>>    According to some comments in the source code, the exception handler
>>    stub code used to be patched upon deoptimization, however presumably
>>    these comments are outdated as the patching upon deoptimization happens
>>    for post-call NOPs only.
>
> One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
> SIGSEGV in caller_is_deopted:
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
> V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
> v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c
> 
> 
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000
> 
> 
> That address is at the end of the stub section:
> 
> 
> R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
> {0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
>  - ---- fields (total size 5 words):
>  - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
>  - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
>  - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
>  - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
>  - transient 'size' 'I' @24  60 (0x0000003c)
>  - transient 'modCount' 'I' @28  60 (0x0000003c)
>  - 'threshold' 'I' @32  96 (0x00000060)
>  - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
> R1 =0x0000001fd503201f is an unknown value
> R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
> Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
>  total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
>  main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
>  stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
>  mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
>  relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
>  metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
>  immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
>  dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
>  scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
>  scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
>  speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
> 0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
> --------------------------------------------------------------------------------
>   0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
>   0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
> --------------------------------------------------------------------------------
> R3 =0x0000f7cf03817578 points into unknown readable ...

@TheRealMDoerr

I tried reproducing this on linuxaarch64 using my M2 Mac Studio/fedora and could not get it to reproduce with either DEBUG or RELEASE build.

There is something rather weird going here. The code at the offending address looks like this:

    0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
    0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
    0x0000f7cf03c60000:   <off the end of the nmethod>

That definitely looks like it is the new backward branch code for the deopt stub leading up to the nmethod tail. However, the generator code for the stub in c1_LIRAssembler is this:

    __ bind(start);
    __ far_jump(RuntimeAddress(SharedRuntime::deopt_blob()->unpack()));
    int entry_offset = __ offset();
    __ b(start);

Method `far_call` should have planted a `bkr` or `bl` not a `b`:

    void MacroAssembler::far_call(Address entry, Register tmp) {
      ...
      if (target_needs_far_branch(entry.target())) {
        uint64_t offset;
        // We can use ADRP here because we know that the total size of
        // the code cache cannot exceed 2Gb (ADRP limit is 4GB).
        adrp(tmp, entry, offset);
        add(tmp, tmp, offset);
        blr(tmp);
      } else {
        bl(entry);
      }

So, I don't understand how your test ended up with these two successive `b` instructions in the nmethod stub.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3421206833

From adinn at openjdk.org  Mon Oct 20 09:53:14 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 20 Oct 2025 09:53:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <ZCnSDCLyDNKZvyijs3s0D7YGOyqoDSVJwFyTK1_0b3o=.3afa1882-1493-4934-8989-1b865047975c@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Doh! Looking at the code properly this time it actually calls `far_jump` but, of course it should really be `far_call` (the C2 version was changed correctly). I believe that's the cause of the error (although it doesn't explain why the value in `lr` was the address after the nmethod tail).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3421306619

From iwalulya at openjdk.org  Mon Oct 20 10:29:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 20 Oct 2025 10:29:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
Message-ID: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>

On Sun, 19 Oct 2025 18:41:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> There may be two issues with the patch as is:
> 
> Calling `GetTotalGCCpuTime` in `Agent_OnLoad` can cause crash (since `CollectedHeap::gc_threads_do` do not protect against races on VM startup/shutdown).
> 
> If `GetTotalGCCpuTime` is invoked in a callback for GC start/end, this will cause a deadlock as the `Heap_lock` is already held. The `MutexLocker hl(Heap_lock)` pattern was introduced to avoid races that could happen from internal usage in G1 of `CPUTimeUsage::GC::total()` during shutdown. I could recall this wrong but I think the usage `Heap_lock` (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of `Universe::_is_shutting_down`. I will ask @walulyai for his thoughts.

Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3421476400

From ayang at openjdk.org  Mon Oct 20 12:54:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 12:54:03 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
Message-ID: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>

Trivial removing effectively dead code.

Test: tier1

-------------

Commit messages:
 - g1-barrier-set-remove

Changes: https://git.openjdk.org/jdk/pull/27898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370234
  Stats: 13 lines in 5 files changed: 0 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27898/head:pull/27898

PR: https://git.openjdk.org/jdk/pull/27898

From mbaesken at openjdk.org  Mon Oct 20 13:23:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 20 Oct 2025 13:23:44 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <28f-0tg_MIRW7NA2_qtYXR9MUdyjMtDNC1ayfih7kJY=.23fb213c-9834-40d9-acaf-00f2a196b4c3@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <d222Kg8hLIsjIobn_l2f6mKLdTgc68Ypka7uaKBUEWg=.11c9a38a-a360-497a-8e31-0ecc326103c3@github.com>
 <28f-0tg_MIRW7NA2_qtYXR9MUdyjMtDNC1ayfih7kJY=.23fb213c-9834-40d9-acaf-00f2a196b4c3@github.com>
Message-ID: <pfrRjnbjzlARQYxgR5RgdI0dasaVMvPFOXcJys13fdY=.12f17de0-9f70-40d3-9d6a-628d7a6c86c7@github.com>

On Fri, 17 Oct 2025 18:43:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.
> 
> But as far I understand it will be much easy to implement for libs, do you know any blockers?

Yes, the LTO build worked for the other JDK native libs when I enabled it there some months ago as a test.
(lto support for them is just a hack for now; but compiled nicely for me because those libs are much smaller/simpler than libjvm)

With GCC and LTO enabled, some libs get smaller  e.g. for libfontmanager I saw a while ago 1.7M (without)  to  1.1M (with LTO).
Speed improvements are hard to evaluate, the benchmarks used in OpenJDK often stress Hotspot and not so much single native JDK libs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3420865857

From mbaesken at openjdk.org  Mon Oct 20 13:23:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 20 Oct 2025 13:23:45 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
Message-ID: <PBoEGxOPlNQQIrRAlOU431MpwxPVlELp6yO9w3NVaj4=.c29168ff-870f-4b3d-a6f5-bec0bab955c4@github.com>

On Fri, 10 Jan 2025 13:09:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.
>> 
>> Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
>> build crashes with a failed assert:
>> 
>> #  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> 
>> I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
>> noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
>> by normal compilation).
>
>> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
> by normal compilation).
> 
> That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.
> 
> The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

> @magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

Currently we have  OPTIMIZATION levels NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE  for the native libs we build in OpenJDK.  We could easily add also LTO or  LTOHIGH + LTOSIZE if we want to distinguish even more.
But currently it is hard to evaluate what it is 'good' for.
Some people would expect improved performance from it; but we do not really have the benchmarks for the smaller JDK libs to prove that (at least I am not aware of it);  that was also a problem when discussing to switch more libs to SIZE optimization.
Some people would expect improved/reduced size from using LTO; that is easier to 'prove' by looking at the libs sizes.  But it is from what I saw not always true (for GCC with lto enabled however you often get smaller libs).

So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3422037167

From fandreuzzi at openjdk.org  Mon Oct 20 13:49:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 13:49:30 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
Message-ID: <D_Ah6omZiPARUgiYuDI-o5zqM_itAQeTx5HlsgECI4I=.f67660d4-b017-49d6-a7b2-74ff0b951a69@github.com>

On Tue, 14 Oct 2025 13:35:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/11529ad9...273c2003

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3356539136

From eosterlund at openjdk.org  Mon Oct 20 14:23:58 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 20 Oct 2025 14:23:58 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v5]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <X3tiJLJ7DL0pWu7lrWj_ob35_EfeW5bJQvwdwgOiBgc=.787757db-8717-4342-a66a-a3eebd495e11@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Test polishing
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Test fix
 - move exception marks outside locks
 - Cleanup testing after default change
 - Ioi comments
 - Dont print error message when there are no archived objects
 - Fix issue in new test
 - Change is_aot_thread implementation
 - update AotJdk problem lists
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c8679713...f7b9f32a

-------------

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=04
  Stats: 8676 lines in 111 files changed: 5906 ins; 2322 del; 448 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From aph at openjdk.org  Mon Oct 20 14:35:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 20 Oct 2025 14:35:11 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <leXzT8VDccm4STu0673und3AwpVtGY_1cIkGFrGgHSY=.f85fc215-d22b-4267-b5e6-f6500f410967@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26562/files
  - new: https://git.openjdk.org/jdk/pull/26562/files/a1474ff6..09f555ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=19-20

  Stats: 82 lines in 4 files changed: 5 ins; 66 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From tschatzl at openjdk.org  Mon Oct 20 14:45:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 20 Oct 2025 14:45:38 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <4Mo8I0J2KxQfnytZoe8uXRlkeIQBes1V2gRtdqjIoPs=.b6b52655-45fa-48a8-a0ed-a0706a4f08ba@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27898#pullrequestreview-3356754224

From fandreuzzi at openjdk.org  Mon Oct 20 15:12:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 15:12:11 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <e5hQT6OWedxZdJaCr955V5uI-JctpMSbXcZR9UaOL1Q=.dfc15ac0-7e63-4d07-986a-425a4e4fd2e6@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27898#pullrequestreview-3356854629

From aph at openjdk.org  Mon Oct 20 15:19:12 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 20 Oct 2025 15:19:12 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <OMinH0J0LqWQH1nXdFCftzUJg-N4-yq61rsHmnR0iLE=.3c448c7e-2773-4294-a1eb-586f6c133f4e@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <c9TT3faFjbiR50afdRd5umynPotg-qyYa56gxJBdEAU=.559fdb4c-6bf7-4d67-bbab-c073bed9577b@github.com>
 <OMinH0J0LqWQH1nXdFCftzUJg-N4-yq61rsHmnR0iLE=.3c448c7e-2773-4294-a1eb-586f6c133f4e@github.com>
Message-ID: <EkCM_zvpMHWFPGqoGO7AkC9jl5AcxW6DxrMcTWyocgY=.3633e07f-ab0e-4078-ade6-a148db41f258@github.com>

On Tue, 12 Aug 2025 07:52:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/os/bsd/os_bsd.cpp line 821:
>> 
>>> 819:   // Avoiding excessive CAS operations to hot RW locations is critical.
>>> 820:   // See https://blogs.oracle.com/dave/entry/cas_and_cache_trivia_invalidate
>>> 821:   // https://web.archive.org/web/20131214182431/https://blogs.oracle.com/dave/entry/cas_and_cache_trivia_invalidate
>> 
>> Something is wrong here. Do we need both the original URL and the wayback machine link?
>
>> Something is wrong here. Do we need both the original URL and the wayback machine link?
> 
> I guess not. The original link is (very) dead, but I'm not sure how stable archive.org links are.

Are you OK with this? I'd rather leave the original URL as it is, but add the archived version: it is very useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2445326715

From adinn at openjdk.org  Mon Oct 20 15:33:08 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 20 Oct 2025 15:33:08 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <EkCM_zvpMHWFPGqoGO7AkC9jl5AcxW6DxrMcTWyocgY=.3633e07f-ab0e-4078-ade6-a148db41f258@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <c9TT3faFjbiR50afdRd5umynPotg-qyYa56gxJBdEAU=.559fdb4c-6bf7-4d67-bbab-c073bed9577b@github.com>
 <OMinH0J0LqWQH1nXdFCftzUJg-N4-yq61rsHmnR0iLE=.3c448c7e-2773-4294-a1eb-586f6c133f4e@github.com>
 <EkCM_zvpMHWFPGqoGO7AkC9jl5AcxW6DxrMcTWyocgY=.3633e07f-ab0e-4078-ade6-a148db41f258@github.com>
Message-ID: <ZT8dRW9zkg8aGmpAmMSJwTMmLTlJ7ZSpeNkRTDlGpwE=.c54d8d54-606a-4718-865f-36d0e812c7e6@github.com>

On Mon, 20 Oct 2025 15:16:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> Something is wrong here. Do we need both the original URL and the wayback machine link?
>> 
>> I guess not. The original link is (very) dead, but I'm not sure how stable archive.org links are.
>
> Are you OK with this? I'd rather leave the original URL as it is, but add the archived version: it is very useful.

Ok if you prefer that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2445361815

From kvn at openjdk.org  Mon Oct 20 16:12:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Oct 2025 16:12:06 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
 <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
Message-ID: <JdDeX2nHp_lpIYOY9OIDYlUk-aFM36O3cgpK9-DOmP4=.52861e2a-a9cd-48dc-bf0a-e47f437e0e6f@github.com>

On Wed, 8 Oct 2025 23:17:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete test/hotspot/jtreg/compiler/exceptions/a

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27683#pullrequestreview-3357083129

From fandreuzzi at openjdk.org  Mon Oct 20 16:41:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 16:41:05 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
 <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
Message-ID: <vYVkf0HIaSQEIOZoXyNa2KkVUUwFwPLRU3YaG93eoiE=.6e725bd5-33ad-4d47-82c7-a469f288851d@github.com>

On Thu, 16 Oct 2025 22:31:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert
>>  - replace
>
> The approach looks okay to me. Thank you for taking care about this issue!

Hi @sspitsyn, @dholmes-ora, @lmesnik, I applied all your suggestions. This PR is ready for another look when you have time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3422860973

From duke at openjdk.org  Mon Oct 20 17:25:14 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 20 Oct 2025 17:25:14 GMT
Subject: Withdrawn: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
References: <BC52YZOIEYxmp9_x0SF9luBsK1iYKSxVdg11i96RyIs=.f3db3b21-5bfd-4011-80cb-9e88237e4b5a@github.com>
Message-ID: <NuKx9A0nCRa_BvixGmrHKq1fXj6lwlkFOxDmV4MR3qc=.16f79633-de0d-4f72-829c-a52fa59864c9@github.com>

On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable <duke at openjdk.org> wrote:

> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile.
> 
> The location of the class file for a class defined can be of utility in both debugging and auditing.
> 
> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27738

From duke at openjdk.org  Mon Oct 20 17:44:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:44:05 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v4]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <CdFU-mIZLpsyvo6OYlS8zoLHsZFcneghwBRJ7HhdniE=.636452d0-bcc8-414b-80f4-0ed381feabf7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove tabs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/b03db63e..8d83dd97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Mon Oct 20 17:50:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:50:05 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <qg1Bn8Hwxdd_QQHbIeOzZPZijQUXI9vLX9Vl4mZBY8k=.4f536c8a-66ee-443a-8ff9-34a023708365@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

Thanks for the suggested API docs @kevinjwalls! I pushed a proposal to use j.l.management, with the proposed generic API docs.

I dropped "may" and "any" from the paragraph about `-1` return value from @kevinjwalls original suggestion:

     * This method return {@code -1} if the platform does
     * not support this operation or the information is not
     * available.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3423134361

From duke at openjdk.org  Mon Oct 20 17:37:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:37:44 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v3]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <EBxwdE3akdiEKYckVZGX-VLdDBeGHkFYzvNkye4_XQw=.3fbaa8dc-3fde-423f-999c-ff2a15ede3c1@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - j.l.management with generic API docs
 - Revert "Move from j.l.management to com.sun.management etc."
   
   This reverts commit 6431310109a02ec5c34f877a1c690afb00193043.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/64313101..b03db63e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=01-02

  Stats: 186 lines in 11 files changed: 35 ins; 143 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From sspitsyn at openjdk.org  Mon Oct 20 18:29:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 18:29:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <Kjr97B0c7Zct7rbCyDEGOu4qJjEhqMWgwZqojDVMY1Q=.62182532-f9be-4968-829a-a48d8f9282f7@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take his word for it.

Yes. I asked Jonas about it when we started our conversation and I rely on his justification which is in the enhancement description.

> This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

Good catch, thanks. Fixed now.

> Also the hex value represents JDK 23 not 25.

Good catch, thanks. Fixed now.

> If it isn't supported then you can't have the capability and so won't reach here.

Good comment. In fact, I've already made a decision to move this to the capability check. But it seems, it also needs to be fixed this way for `GetCurrentThreadCpuTime()` and `GetThreadCpuTime()`.

>> +       Universe::heap()->is_shutting_down()) {
>> +       *nanos_ptr = -1;
> 
> This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

I agree. I've already noticed this issue and was thinking where and how to fix it. Thank you for the suggestion. It can be fixed this way but I feel it is better to fix on the GC side. Will discuss it with Jonas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423268108

From pchilanomate at openjdk.org  Mon Oct 20 19:01:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 19:01:58 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v4]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <YaFsnpfxMN6Uydz7nVvHb9tFNtGosRc6cYO1hUBmTYM=.b7215bef-433e-45a7-9fd5-6bf056c41c61@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Extra comments from David
 - Use ClassInitMode and shorter enum names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/ac557152..30bdf498

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=02-03

  Stats: 65 lines in 16 files changed: 2 ins; 4 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Mon Oct 20 19:12:24 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 19:12:24 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v5]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <WAhX9sE3rkD29mFCpLb1o98l6s341E32M8rWzSL0rtw=.96b3052a-8f15-42a7-8a7a-fa16d69151d2@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra debugging param

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/30bdf498..6882db04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Mon Oct 20 19:12:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 19:12:29 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
Message-ID: <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>

On Fri, 17 Oct 2025 05:43:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix verify_frame_kind
>
> src/hotspot/share/interpreter/linkResolver.hpp line 192:
> 
>> 190: };
>> 191: 
>> 192: enum class StaticMode : uint8_t {
> 
> Need to think of a better name for this ... `ClassInitMode`?

Yes, much better. Changed.

> src/hotspot/share/interpreter/linkResolver.hpp line 195:
> 
>> 193:   dont_initialize_klass,
>> 194:   initialize_klass,
>> 195:   initialize_klass_preemptable
> 
> And maybe more concisely:
> Suggestion:
> 
>   dont_init
>   init
>   init_preemptable
> 
> ?

Yes, changed.

> src/hotspot/share/oops/instanceKlass.cpp line 1284:
> 
>> 1282:   // Block preemption once we are the initializer thread. Unmounting now
>> 1283:   // would complicate the reentrant case (identity is platform thread).
>> 1284:   NoPreemptMark npm(THREAD);
> 
> How does this affect unrelated "preemption" that may occur in the Java code called as part of `<clinit>`?

While executing the `<clinit>` method the vthread is pinned because of the call_stub in the stack (freeze will fail if we try to unmount), regardless of this `NoPreemptMark`. So this is for the other places where it is preemptable, mainly when initializing the super klass below.

> src/hotspot/share/oops/klass.hpp line 583:
> 
>> 581:   // initializes the klass
>> 582:   virtual void initialize(TRAPS);
>> 583:   virtual void initialize_preemptable(TRAPS);
> 
> Can we not define these on `instanceKlass` instead of `klass`? Seems really odd to declare virtual methods for which the base class version should never be called (they should be pure virtuals in that case I would think?).

Ok. Just to double check, casting to `InstanceKlass*` where we call `initialize_preemptable` for the `invokestatic` and `getstatic/putstatic` cases should be always safe right? I don?t see how we could get there for an `ArrayKlass`.

> src/hotspot/share/runtime/continuationEntry.cpp line 117:
> 
>> 115:   assert(thread->has_last_Java_frame(), "Wrong place to use this assertion");
>> 116: 
>> 117:   if (preempted) return true;
> 
> I don't see the point of adding a new parameter just so the method can check it and return immediately. Shouldn't the caller be checking this?

Right, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445862480
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445862813
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445864285
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445868222
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445869014

From sspitsyn at openjdk.org  Mon Oct 20 19:17:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:17:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <-xJ-7eFcpzLYfOtrQlhE9ejmcwz1WM7FplEQtmTCADc=.2ec0d270-3e7f-4862-8967-1aa245bf5c5a@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm wondering, would a user trying to call GetTotalGCCpuTime if can_get_gc_cpu_time is not successfully set to 1 be undefined behavior? The specs say "To possess a capability, the agent must add the capability (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#capability). If yes maybe we can discard the extra call to os::is_thread_cpu_time_supported in JvmtiEnv::GetTotalGCCpuTime? That seems to align with the pattern to not have that check in the other methods as you pointed out.

Right thinking, thanks. In fact, I had a plan to move this check to the capability side after the week ends. :)

> Should this be called GetTotalGCCpuTimerInfo?

I was already thinking on this for some time. I wanted to generalize this timer a little bit for a case if we ever decide to add more GC related functions. I'm not sure that all timers have to be strictly bound to the `CpuTime` function` and can be potentially reused for some other cases.

> There may be two issues with the patch as is:
> Calling GetTotalGCCpuTime in Agent_OnLoad can cause crash (since CollectedHeap::gc_threads_do do not protect against races on VM startup/shutdown).
>
> If GetTotalGCCpuTime is invoked in a callback for GC start/end, this will cause a deadlock as the Heap_lock is already held. The MutexLocker hl(Heap_lock) pattern was introduced to avoid races that could happen from internal usage in G1 of CPUTimeUsage::GC::total() during shutdown. I could recall this wrong but I think the usage Heap_lock (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of Universe::_is_shutting_down. I will ask @walulyai for his thoughts.

It is nice you have caught this early. It would be nice to sort out this issue, and it is better to fix it on the GC side. I'd suggest to file a bug to separate this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423402965

From sspitsyn at openjdk.org  Mon Oct 20 19:04:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:04:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <_dyneYvZ5cJjriz-Mt1woRWD4LfgppeF2dJybclDo2I=.3049be57-dccd-4378-876c-b7780bf8c1f7@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

Alan, thank you for looking at this, the comments and good questions. I agree, we need to look at some level of completeness here. It includes the process CPU time and potentially more functionality to support modern GC's (I hope to get more insight from the GC team here). One question I've got is about all these timers and a possibility to reuse some of them. Is it right to have new timer for each CPU metric? We need some kind of overall design for all this. As I've posted earlier in reply to David for this enhancement, I rely on Jonas's justification which is in the enhancement description.

> As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.

Yes, support for modern collectors is on the table for some time.  Now seems to be a good time to make some steps in this direction.

> I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

I hope, Jonas has answered this.

> (in passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

Yes, it seems this function is a little bit out of this section scope. But I do not see a better section for this, and it does not deserve its own section yet. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423360087

From pchilanomate at openjdk.org  Mon Oct 20 19:23:16 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 19:23:16 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
Message-ID: <4RnCaK-UiAcxujqvgB6zbTe70SMXBkJDJieP9U0tzg4=.3fbda558-c9b3-4d5a-a0e0-e009005d9a50@github.com>

On Fri, 17 Oct 2025 06:49:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix verify_frame_kind
>
> src/hotspot/share/interpreter/linkResolver.cpp line 1122:
> 
>> 1120:       resolved_klass->initialize(CHECK);
>> 1121:     } else if (static_mode == StaticMode::initialize_klass_preemptable) {
>> 1122:       resolved_klass->initialize_preemptable(CHECK);
> 
> Why is this not CHECK_AND_CLEAR_PREEMPTED?

We need to let the exception propagate all the way back to the VM entry point, and only then we can clear it.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 196:
> 
>> 194: static void do_deopt_after_thaw(JavaThread* thread);
>> 195: static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, outputStream* st);
>> 196: static void log_frames(JavaThread* thread, bool dolog = true);
> 
> Suggestion:
> 
> static void log_frames(JavaThread* thread, bool do_log = true);

I removed it altogether. I used it during debugging when I wanted to disable all frame logging except from certain places. But it's not really needed.

> src/hotspot/share/runtime/javaThread.hpp line 492:
> 
>> 490:   // throw IE at the end of thawing before returning to Java.
>> 491:   bool _pending_interrupted_exception;
>> 492:   // We allow preemption on some klass initializion calls.
> 
> Suggestion:
> 
>   // We allow preemption on some klass initialization calls.

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 507:
> 
>> 505: 
>> 506:   bool at_preemptable_init() { return _at_preemptable_init; }
>> 507:   void set_at_preemptable_init(bool b) { _at_preemptable_init = b; }
> 
> If you are going align 503 and 504 then you may as well align these two lines as well

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 522:
> 
>> 520:     JavaThread* _thread;
>> 521:    public:
>> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {
> 
> Suggestion:
> 
>     AtRedoVMCall(JavaThread* t) : _thread(t) {

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 524:
> 
>> 522:     AtRedoVMCall(JavaThread *t) : _thread(t) {
>> 523:       _thread->_interp_at_preemptable_vmcall_cnt++;
>> 524:       assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "");
> 
> Suggestion:
> 
>       assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

Added.

> src/hotspot/share/runtime/javaThread.hpp line 528:
> 
>> 526:     ~AtRedoVMCall() {
>> 527:       _thread->_interp_at_preemptable_vmcall_cnt--;
>> 528:       assert(_thread->_interp_at_preemptable_vmcall_cnt >= 0, "");
> 
> Suggestion:
> 
>     assert(_thread->_interp_at_preemptable_vmcall_cnt > 0, "Unexpected count: %d", _thread->_interp_at_preemptable_vmcall_cnt);

Added.

> src/hotspot/share/runtime/objectMonitor.cpp line 315:
> 
>> 313: }
>> 314: 
>> 315: // Keep object protected during ObjectLocker preemption.
> 
> I don't understand why this is necessary.

Once the thread initializing the class finishes the initialization and calls `InstanceKlass::fence_and_clear_init_lock()`, the init_lock oop can be GC?ed, unless there is some other `Handle` protecting it (`ObjectMonitor::_object` is only a `WeakHandle`). But we could still have preempted virtual threads using the ObjectMonitor, so we need to protect the oop. In practice, I don?t see paths in `ObjectMonitor::resume_operation` where we try to get the oop out of the monitor, but I?m not sure if we want to break the invariant where the object needs to be alive while using its ObjectMonitor.

> src/hotspot/share/runtime/synchronizer.cpp line 489:
> 
>> 487:     if (_thread->preempting()) {
>> 488:       // If preemption was cancelled we acquired the monitor after freezing
>> 489:       // the frames. Redoing the vm call later?in thaw will require us to
> 
> I don't quite follow the control flow here - at what point have we frozen any frames? Was that deep inside `enter`?

Yes, in `ObjectMonitor::enter_with_contention_mark` we first freezed the frames, but then the thread was able to acquire the monitor in `ObjectMonitor::vthread_monitor_enter` while trying to add itself to the `_entry_list`, so preemption was cancelled. For this `ObjectLocker` case, we will have to redo the VM call again after thawing so we need to release the monitor.

> src/java.base/share/classes/java/lang/VirtualThread.java line 172:
> 
>> 170: 
>> 171:     // true when waiting in Object.wait, false for VM internal uninterruptible Object.wait
>> 172:     private volatile boolean interruptableWait;
> 
> Suggestion:
> 
>     private volatile boolean interruptibleWait;

Fixed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 605:
> 
>> 603:         if (s == WAITING || s == TIMED_WAITING) {
>> 604:             int newState;
>> 605:             boolean interruptable = interruptableWait;
> 
> Suggestion:
> 
>             boolean interruptible = interruptibleWait;

Fixed.

> src/java.base/share/classes/jdk/internal/vm/PreemptedException.java line 31:
> 
>> 29:  * Internal exception used only by the VM.
>> 30:  */
>> 31: public class PreemptedException extends Exception {
> 
> Should probably extend `RuntimeException` so that it is not considered a checked-exception

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445892049
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445884886
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445886314
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445886550
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445886740
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445886915
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445887072
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445889274
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445890688
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445890950
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445891154
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445891449

From pchilanomate at openjdk.org  Mon Oct 20 20:26:44 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 20:26:44 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <o3hpKGrTsS6w4Szf9ag-bBuHgPPA5NRXPyHVMoXtwvI=.61e6c656-aa9c-4a29-8ae4-0450006f6910@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  PPC support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/6882db04..6000edb6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=04-05

  Stats: 167 lines in 17 files changed: 107 ins; 20 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Mon Oct 20 20:26:45 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 20 Oct 2025 20:26:45 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths
In-Reply-To: <sJzFRqYl_RYBg6PMCb0IjOrWPyrLQMx8iVqpWwcba4k=.1cf5f930-8529-4367-9b7a-ee7dc070f111@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <zzGalP0qaZEuS1TsUAVZl82qZrU8FG8s4jRMl4O9GLM=.a772aa70-0dd6-4daa-bc69-bb5d8205d6cc@github.com>
 <sJzFRqYl_RYBg6PMCb0IjOrWPyrLQMx8iVqpWwcba4k=.1cf5f930-8529-4367-9b7a-ee7dc070f111@github.com>
Message-ID: <uU91dlThea5VRXLbe8mOuYofezs0Sy0lH8QKwtkwHTg=.a85aa8c2-5c66-4dce-a4b7-d4143c270b2d@github.com>

On Tue, 14 Oct 2025 20:20:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/27676 has been integrated which requires resolution.
>
>> #27676 has been integrated which requires resolution.
>>
> Thanks, merged with latest master.

> @pchilano I've finished the ppc part: [reinrich at 99b9652](https://github.com/reinrich/jdk/commit/99b96528539dd7239711d9c70aebb1a4c1a7fdfe)
>
Great, thanks Richard! Pushed the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3423592607

From lmesnik at openjdk.org  Mon Oct 20 20:43:06 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 20 Oct 2025 20:43:06 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 66:

> 64:     @AfterAll
> 65:     static void stopChild() throws Exception {
> 66:         child.destroy();

Is it possible to let the process to complete normally instead of killing it?  (by writing into stream?)
So test can verify that process is exited with code 0 and nothing is broken by this attaching attempt.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3357862476
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446072341

From kbarrett at openjdk.org  Mon Oct 20 20:56:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Oct 2025 20:56:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ealn_1aUb8RSGHtU0rSU2QXw0NnKSbLVzQU0XOusP28=.a18d6e0f-b721-4929-9d29-870fc1060353@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

I forgot to update gtests to use the newly introduced wrapper headers. I'll deal with that later as a separate change,
to avoid making this one even bigger with not very interesting changes to a bunch more files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3423683169

From coleenp at openjdk.org  Mon Oct 20 20:59:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 20 Oct 2025 20:59:36 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace
Message-ID: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>

This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
Tested with the test 100x.

-------------

Commit messages:
 - 8361451: Test vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java fails with OutOfMemoryError: Metaspace

Changes: https://git.openjdk.org/jdk/pull/27907/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361451
  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27907/head:pull/27907

PR: https://git.openjdk.org/jdk/pull/27907

From kbarrett at openjdk.org  Mon Oct 20 21:00:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Oct 2025 21:00:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
 <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>
Message-ID: <gC8igKGYKLcIi17oTJUcLLT0Aw4adBgaIyMb0WgcPD4=.ae5b1824-a2a8-4287-ab69-c2691a9816ac@github.com>

On Mon, 20 Oct 2025 09:15:14 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> [...] I would have liked more of the c++ library included (like tuples, optional and expected), but this is a good start.

This PR is intentionally quite limited; it doesn't add anything to the set of
what's permitted. It is instead about establishing that such additions are
possible, and a framework for doing so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3423694560

From sspitsyn at openjdk.org  Mon Oct 20 21:05:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 21:05:25 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v4]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <5ZWuvRfM6nTcjIkNRpjYYHTlhNwuBEN0SK4lchzxVNw=.b655df31-9696-45ff-94cc-70c53b459d76@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Review: address some review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/d816a56d..6ac238eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27879&range=02-03

  Stats: 10 lines in 3 files changed: 1 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27879/head:pull/27879

PR: https://git.openjdk.org/jdk/pull/27879

From amenkov at openjdk.org  Mon Oct 20 21:06:08 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 20 Oct 2025 21:06:08 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 35:

> 33: import java.io.InputStream;
> 34: import java.util.Objects;
> 35: import java.util.concurrent.TimeUnit;

Unused imports

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 99:

> 97: 
> 98:         ProcessBuilder pb = new ProcessBuilder(jcmd.getCommand());
> 99:         OutputAnalyzer out = new OutputAnalyzer(pb.start());

I'd suggest to use `jdk.test.lib.dcmd.PidJcmdExecutor`
Then this can be simplified to something like


OutputAnalyzer out = new PidJcmdExecutor().execute("JVMTI.agent_load some.jar");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446116204
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446119986

From serb at openjdk.org  Mon Oct 20 21:11:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Oct 2025 21:11:15 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <PBoEGxOPlNQQIrRAlOU431MpwxPVlELp6yO9w3NVaj4=.c29168ff-870f-4b3d-a6f5-bec0bab955c4@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <PBoEGxOPlNQQIrRAlOU431MpwxPVlELp6yO9w3NVaj4=.c29168ff-870f-4b3d-a6f5-bec0bab955c4@github.com>
Message-ID: <8w70YHXPApfQ_Hp1DJAQsijiUU0AXkm6ZgziOn3zj0I=.71b5defe-02e5-4d2b-930f-8d7615aacf88@github.com>

On Mon, 20 Oct 2025 13:19:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3423727477

From stefank at openjdk.org  Mon Oct 20 21:40:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Oct 2025 21:40:03 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
 <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
Message-ID: <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>

On Fri, 17 Oct 2025 14:57:11 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.cpp line 355:
>> 
>>> 353: }
>>> 354: 
>>> 355: bool HeapShared::is_loading_mapping_mode() {
>> 
>> I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.
>> 
>> Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:
>> 
>> - _is_loading_heap
>> - _is_loading_heap_streaming_mode
>> 
>> The first boolean is the main switch, but most of the code will be checking only the second boolean.
>
> Okay. @stefank is having a look at fixing this.

I've sort-of implemented the second part of your comment about removing the tri-state:
https://github.com/fisk/jdk/compare/8326035_JEP_object_streaming_v6...stefank:jdk:8326035_JEP_object_streaming_v6_stefank

The enum had *four* states (`uninitialized`, `mapping`, `streaming`, `none`) and while reading this PR the `none` part seemed unusual. After working on the proposed patch I think the `none` value served a purpose, but let's see if a patch without it makes sense.

The patch still uses an enum instead of two booleans. I think that makes the code more readable because we encode the three states with three enum values. If we were to use two booleans we would end up with four possible states and then the reader of the code would have to figure out which of the forth state is an invalid state. I think what we have in the patch above is safer. (Let's revisit this if this still is a blocker)

So, I removed `none` and added strict asserts that you are not allowed to ask for the mode until the variable has transitioned away from `uninitialized` to either `mapping` or `streaming`. After the variable has been initialized the questions are binary and you have `is_loading_mapping_mode() == !is_loading_streaming_mode()`. I don't see the appeal to remove one of these two functions, because that just adds negation to the code and that makes it harder to read. (We can experiment with that in a separate patch)

I tried to take it even further and join these `is_loading` functions with the `is_archived_heap_in_use` and the `is_in_use` properties, but that hit problems with error-edge cases. I have a feeling that the `none` value dealt with these problems.

Some more details about the edge-case problems:

During loading of the heap archive there is a duration where we have decided that we are going to load the archived heap and what loading mode to use, but the archive has not been loaded enough have the `is_archived_heap_in_use` function return `true`. During these early stages we must use the `is_loading` and `is_loading_` functions. After `is_archived_heap_in_use` starts to return the correct value, the code likely needs to use that function instead of the `is_loading` functions. Some parts of the AOT/CDS code will bug out if you try to use the `is_loading` functions after an error.

So, I've tried to keep the usages of `is_loading` functions inside AOT/CDS code. The `is_archived_heap_in_use`, or one of it's sub-components (E.g. `AOTMappedHeapLoader:is_in_use()`), are used in both later stages of the AOT/CDS code and in code only adjacent to AOT/CDS.

In addition to removing the `none"` state the patch also includes a couple of small tweaks:

* Move some dispatching to "mapping" and "streaming" code so that the `is_loading_` functions could be kept inside the HeapShared code.
* Move `is_` functions to heapShared.inline.hpp added to get rid of some extra calls.
* Fix some log error messages for inconsistent JVM flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2446184309

From valeriep at openjdk.org  Mon Oct 20 23:17:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Oct 2025 23:17:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
Message-ID: <2uIJVPehvByBLLKXHTHvkysLZIyHXsUvviNj1mbelxE=.379ce84d-7532-4a61-a63a-f4f54791b4e7@github.com>

On Sun, 19 Oct 2025 02:18:43 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1034:

> 1032:         int ti0, ti1, ti2, ti3;
> 1033:         int a0, a1, a2, a3;
> 1034:         int w = K.length - 4;

nit: 4 could be WB?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446328176

From valeriep at openjdk.org  Mon Oct 20 23:51:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Oct 2025 23:51:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
Message-ID: <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>

On Sun, 19 Oct 2025 02:18:43 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

Just have some minor questions and nit.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 589:

> 587: 
> 588:     // Lookup table for inverse substitution transform of last round as
> 589:     // described in the international journal article referenced.

Is there a link that I can look it up also?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1180:

> 1178:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
> 1179:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
> 1180:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w + 3];

Is this last round processing also based on spec or some journal?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27807#pullrequestreview-3358325489
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446391365
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446389723

From duke at openjdk.org  Tue Oct 21 00:05:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:05:31 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/5ea6933b..fdfd3892

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

PR: https://git.openjdk.org/jdk/pull/27807

From duke at openjdk.org  Tue Oct 21 00:05:34 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:05:34 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
 <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>
Message-ID: <Eh36gbo8zuwSO_Onq_XfViiimSCKuku-A-XH-CV10sw=.a788694f-3bf3-4a5b-88cb-b356e4ae8943@github.com>

On Mon, 20 Oct 2025 23:47:51 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 589:
> 
>> 587: 
>> 588:     // Lookup table for inverse substitution transform of last round as
>> 589:     // described in the international journal article referenced.
> 
> Is there a link that I can look it up also?

Yes, it's the 3rd document cited for this class: https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1034:
> 
>> 1032:         int ti0, ti1, ti2, ti3;
>> 1033:         int a0, a1, a2, a3;
>> 1034:         int w = K.length - 4;
> 
> nit: 4 could be WB?

Yes, I think that logic is acceptable. Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1180:
> 
>> 1178:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
>> 1179:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
>> 1180:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w + 3];
> 
> Is this last round processing also based on spec or some journal?

Yes, it's an optimization based on the 3rd document cited for this class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411532
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411617
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411563

From duke at openjdk.org  Tue Oct 21 00:21:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:21:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>
Message-ID: <56yK_DbZSYd0QHrNIo3kAy5wxesDss6VTTB0Ii6q_JU=.12a00665-fd8d-4e44-a169-5fec560fc0b2@github.com>

On Fri, 17 Oct 2025 07:04:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I've removed this method and inlined this logic in the invGenRoundKeys method.
>
> Sure, this works as well.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446428127

From duke at openjdk.org  Tue Oct 21 00:21:07 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:21:07 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <PDpfpmbfNV44CQjYzvy4hoOdUWDN7k5VNqKYMZT_Kz4=.410e2407-6689-4ee6-a3e7-538c52eef8bf@github.com>

On Fri, 17 Oct 2025 06:52:16 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:
>> 
>>> 974:      * @param state [in, out] the round key for inverse mix column processing.
>>> 975:      */
>>> 976:     private static void invMixRKey(int[] state) {
>> 
>> nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?
>
> I've removed this method and inlined this logic in the invGenRoundKeys method.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446428552

From dholmes at openjdk.org  Tue Oct 21 01:55:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Oct 2025 01:55:00 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace
In-Reply-To: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
Message-ID: <Q4VQUW2qE2gK-LoTrQHMaRyKr7OWW9_X3sJJV5TBR4M=.b207fccb-ecfc-41f0-abb8-fed4a953ec5f@github.com>

On Mon, 20 Oct 2025 20:53:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
> Tested with the test 100x.

test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/PerformChecksHelper.java line 140:

> 138:             }
> 139:         } catch (InvocationTargetException ite) {
> 140:             if (ite.getCause() != null && ite.getCause().getMessage().trim().toLowerCase().contains("Metaspace")) {

Surely this can never be true as you converted to lowercase and are searching for uppercase 'M'. ??

And the `trim()` serves no purpose that I can see when you are using `contains`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27907#discussion_r2446522093

From epeter at openjdk.org  Tue Oct 21 05:50:02 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 05:50:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
 <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>
 <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@github.com>
Message-ID: <FnsJnOqlH8GvLjpxaPYYVWnyuwExnUQvIU_DsRlTpTo=.a25060e5-2dd0-4159-84da-3fb6aa0145ba@github.com>

On Fri, 17 Oct 2025 17:19:09 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:
>> 
>>> 42: 
>>> 43:     @Param("10000000")
>>> 44:     private int count;
>> 
>> Drive-by comment / question:
>> Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.
>
> The benchmarks listed in the PR description execute tests for data sizes ranging from 16 to 10_000_000 bytes for decryption and encryption.  The difference in performance between the old and new code were within SE.

Ok, sure. Why not list all the relevant sizes in the benchmark itself then?
But totally up to you. This was just a hint/drive-by comment, feel free to mark it as resolved :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446783134

From sspitsyn at openjdk.org  Tue Oct 21 07:14:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 07:14:07 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:

> 45: 
> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);

Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446956647

From epeter at openjdk.org  Tue Oct 21 07:18:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:18:05 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v3]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <84MqtoPPB-QssENCh58yZai2AXiBUmiJMchtZxclf50=.b43920a8-6e84-4904-81e9-5c2166a697d9@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720
> 
> TODO: improve `VerifyLoopOptimizations` to check that we can call `get_ctrl` on all live nodes after loop-opts.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  fix merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/c3ab0698..e0b6ad68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=01-02

  Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From epeter at openjdk.org  Tue Oct 21 07:21:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:21:07 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v3]
In-Reply-To: <A6CrebaCSqy7t7KUCEnwkPPatJCoxi2ZNzM3krriMsg=.f7987f30-f887-4cdc-ac1d-59443ec07c9c@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
 <A6CrebaCSqy7t7KUCEnwkPPatJCoxi2ZNzM3krriMsg=.f7987f30-f887-4cdc-ac1d-59443ec07c9c@github.com>
Message-ID: <mcZx-QxVv1_G0o2QBUW_RetN0ddfalNMe5C0VZlZxPY=.8165d07d-31de-432f-8f97-2ac9b544b7fe@github.com>

On Mon, 20 Oct 2025 13:36:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> src/hotspot/share/opto/loopnode.hpp line 1176:
>> 
>>> 1174:   // - Update the node inputs of all uses.
>>> 1175:   // - Lazily update the ctrl and idom info of all uses, via a ctrl/idom forwarding.
>>> 1176:   void replace_ctrl_node_and_forward_ctrl_and_idom(Node *old_node, Node *new_node) {
>> 
>> Maybe add here and/or in `install_lazy_ctrl_and_idom_forwarding()` an assert that we have a CFG nodes (i.e. `is_CFG()`) additionally to the `!has_ctrl()` asserts.
>
> Just noticed this: We often (intuitively?) seem to use "control" when talking about just some control nodes and "ctrl" when talking about the nodes found/fetched from `_loop_or_ctrl`. Under this light, we might want to name the method "replace_control_node_and_forward_ctrl_and_idom" to better distinguish them. But I don't have a strong opinion about it - your call ?

I'm not sure we do that consistently. I think I'll just keep it as is, in a shorter form. The name is already quite long ? 

Adding the `is_CFG`, good idea!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2446988758

From epeter at openjdk.org  Tue Oct 21 07:29:41 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:29:41 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v4]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <3TcuvopXlzCCI30K0S5aC07hKiGgQ1xkIOHbc_0ZmNo=.45f10950-7238-4d3f-a51e-53a281e3fa75@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720
> 
> TODO: improve `VerifyLoopOptimizations` to check that we can call `get_ctrl` on all live nodes after loop-opts.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  for Christian part 1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/e0b6ad68..d9f7926e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From epeter at openjdk.org  Tue Oct 21 07:35:20 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:35:20 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <9RB0Ls1iPyS_xeJWj5DLw5b_un7ueUWZ4bX5ix9F_kw=.3495c8e4-a6ed-430e-b7d8-a6e4acf2b99a@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720
> 
> TODO: improve `VerifyLoopOptimizations` to check that we can call `get_ctrl` on all live nodes after loop-opts.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/d9f7926e..73bb42f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From epeter at openjdk.org  Tue Oct 21 07:42:13 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:42:13 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
Message-ID: <Z7SzxANJkHGA7TzaWDT1F1ceH45Au3KWtLWRKPBXmvs=.d1840d27-825b-4226-8b23-56869a6a443e@github.com>

On Mon, 20 Oct 2025 13:25:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/loopnode.hpp line 1154:
> 
>> 1152:   //   forwarding in the future.
>> 1153:   // - When querying "idom": from some node get its old idom, which
>> 1154:   //   may be dead but has a ctrl forwarding to the new and live
> 
> Maybe add this:
> Suggestion:
> 
>   //   may be dead but has an idom forwarding (piggy-backing on '_loop_or_ctrl') to the new and live

Thanks for the suggestion. I applied something that is inspired by your suggestion instead :)

> src/hotspot/share/opto/loopnode.hpp line 1160:
> 
>> 1158:   // the entry for the old dead node now, and we do not have to update all
>> 1159:   // the nodes that had the old_node as their "get_ctrl" or "idom". We
>> 1160:   // clean up the forwarding links when we query "get_ctrl" or "idom".
> 
> Suggestion:
> 
>   // clean up the forwarding links when we query "get_ctrl" or "idom" for these nodes the next time.

Applied it but with a line break ;)

> src/hotspot/share/opto/loopnode.hpp line 1161:
> 
>> 1159:   // the nodes that had the old_node as their "get_ctrl" or "idom". We
>> 1160:   // clean up the forwarding links when we query "get_ctrl" or "idom".
>> 1161:   void install_lazy_ctrl_and_idom_forwarding(Node* old_node, Node* new_node) {
> 
> Maybe we don't need lazy sice "install forwarding" is already expressive enough:
> 
> Suggestion:
> 
>   void install_ctrl_and_idom_forwarding(Node* old_node, Node* new_node) {

Applied systematically :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447051099
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447056113
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447060094

From epeter at openjdk.org  Tue Oct 21 07:47:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:47:07 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
Message-ID: <6fV6WCQAoTBHoBnxKZLvMdINAZgsMRtrw6ol63bqOGQ=.8df8a005-2b10-41ef-b533-74d184bf976a@github.com>

On Mon, 20 Oct 2025 13:50:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/loopnode.hpp line 1262:
> 
>> 1260:       // forwarding installed, using "install_lazy_ctrl_and_idom_forwarding".
>> 1261:       // We now have to jump from the old (dead) ctrl node to the new (live)
>> 1262:       // ctrl/idom node, in possibly multiple ctrl/idom forwarding steps.
> 
> Maybe for clarification since it's somehow surprising at first that we reuse `_loop_or_ctrl`:
> Suggestion:
> 
>       // idom node, in possibly multiple idom forwarding steps.
>       // Note that we piggy back on `_loop_or_ctrl` do the the forwarding.

Applied with even more information.

> src/hotspot/share/opto/loopnode.hpp line 1274:
> 
>> 1272:   }
>> 1273: 
>> 1274:   Node* idom(uint didx) const {
> 
> While at it: Maybe also name this `node_index`?

I chose to replace it with `node_idx`, since it comes from `n->_idx`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447068474
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447075460

From epeter at openjdk.org  Tue Oct 21 07:57:39 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 07:57:39 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v6]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <59V3v8eASx0Rblb7t7fSAlMC4YOGOIHP4OGlUmOjbH8=.9894dc12-027d-4e17-b250-1c3c5dbfe395@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720

Emanuel Peter has updated the pull request incrementally with three additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - more for Christian part 3
 - more for Christian part 2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/73bb42f5..a91396be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=04-05

  Stats: 33 lines in 3 files changed: 10 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From thartmann at openjdk.org  Tue Oct 21 07:57:43 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 07:57:43 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <9RB0Ls1iPyS_xeJWj5DLw5b_un7ueUWZ4bX5ix9F_kw=.3495c8e4-a6ed-430e-b7d8-a6e4acf2b99a@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <9RB0Ls1iPyS_xeJWj5DLw5b_un7ueUWZ4bX5ix9F_kw=.3495c8e4-a6ed-430e-b7d8-a6e4acf2b99a@github.com>
Message-ID: <Cl3CPD3rrUe0bo-AWVBAsAyVUHTrXXXh3ci7fi2V7MQ=.113c4a28-b39b-4a7e-b8fd-665ed03e1e2a@github.com>

On Tue, 21 Oct 2025 07:35:20 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
>> 
>> Here, I'm doing the following:
>> - Add more documentation, and improve it in other cases.
>> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
>> - Made some methods private, and added some additional asserts.
>> 
>> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
>> 
>> Related issues:
>> https://github.com/openjdk/jdk/pull/27889
>> https://github.com/openjdk/jdk/pull/15720
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

src/hotspot/share/opto/loopUnswitch.cpp line 523:

> 521:   register_control(region, lp, new_multiversion_slow_proj);
> 522: 
> 523:   // Hook region into slow_path, in stead of the multiversion_slow_proj.

Suggestion:

  // Hook region into slow_path, instead of the multiversion_slow_proj.

src/hotspot/share/opto/loopnode.hpp line 1176:

> 1174:   // - Update the node inputs of all uses.
> 1175:   // - Lazily update the ctrl and idom info of all uses, via a ctrl/idom forwarding.
> 1176:   void replace_ctrl_node_and_forward_ctrl_and_idom(Node *old_node, Node *new_node) {

Drive-by comment (sorry): I think this is way too heavy. Descriptive names are good but for complex methods, not all the semantics can be put into the name but should rather be in a comment.

Couldn't we just name these `replace_and_update_ctrl` and `update_ctrl`? I think this entails updating idom which is dependent on ctrl. And the comments explain the details well enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447056340
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447097742

From epeter at openjdk.org  Tue Oct 21 08:11:10 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 08:11:10 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <Cl3CPD3rrUe0bo-AWVBAsAyVUHTrXXXh3ci7fi2V7MQ=.113c4a28-b39b-4a7e-b8fd-665ed03e1e2a@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <9RB0Ls1iPyS_xeJWj5DLw5b_un7ueUWZ4bX5ix9F_kw=.3495c8e4-a6ed-430e-b7d8-a6e4acf2b99a@github.com>
 <Cl3CPD3rrUe0bo-AWVBAsAyVUHTrXXXh3ci7fi2V7MQ=.113c4a28-b39b-4a7e-b8fd-665ed03e1e2a@github.com>
Message-ID: <JYfKdYiEUgcNAzd7HBdWhcajpNZOdjzeCJMUyTyoiCs=.398a0f64-6075-40bf-8dbf-8aa0ae63d0bf@github.com>

On Tue, 21 Oct 2025 07:51:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/loopnode.hpp line 1176:
> 
>> 1174:   // - Update the node inputs of all uses.
>> 1175:   // - Lazily update the ctrl and idom info of all uses, via a ctrl/idom forwarding.
>> 1176:   void replace_ctrl_node_and_forward_ctrl_and_idom(Node *old_node, Node *new_node) {
> 
> Drive-by comment (sorry): I think this is way too heavy. Descriptive names are good but for complex methods, not all the semantics can be put into the name but should rather be in a comment.
> 
> Couldn't we just name these `replace_and_update_ctrl` and `update_ctrl`? I think this entails updating idom which is dependent on ctrl. And the comments explain the details well enough.

@TobiHartmann 

`update_ctrl`: Sounds too much like `set_ctrl`, but it is not at all similar conceptually.

What about:
- `install_ctrl_and_idom_forwarding` -> `forward_ctrl`
- `replace_ctrl_node_and_forward_ctrl_and_idom` -> `replace_node_and_forward_ctrl`
  - Because it is really a specialization of `_igvn.replace_node`, so it should have some name similarity.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447148523

From thartmann at openjdk.org  Tue Oct 21 08:11:11 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 08:11:11 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v5]
In-Reply-To: <JYfKdYiEUgcNAzd7HBdWhcajpNZOdjzeCJMUyTyoiCs=.398a0f64-6075-40bf-8dbf-8aa0ae63d0bf@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <9RB0Ls1iPyS_xeJWj5DLw5b_un7ueUWZ4bX5ix9F_kw=.3495c8e4-a6ed-430e-b7d8-a6e4acf2b99a@github.com>
 <Cl3CPD3rrUe0bo-AWVBAsAyVUHTrXXXh3ci7fi2V7MQ=.113c4a28-b39b-4a7e-b8fd-665ed03e1e2a@github.com>
 <JYfKdYiEUgcNAzd7HBdWhcajpNZOdjzeCJMUyTyoiCs=.398a0f64-6075-40bf-8dbf-8aa0ae63d0bf@github.com>
Message-ID: <bOXvL16ttLjvMLO5VYsqouTPGVN4eeKDiALpKc4LdzU=.f56c70a0-d8e8-41f9-88f1-5e7a31aca22a@github.com>

On Tue, 21 Oct 2025 08:06:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/loopnode.hpp line 1176:
>> 
>>> 1174:   // - Update the node inputs of all uses.
>>> 1175:   // - Lazily update the ctrl and idom info of all uses, via a ctrl/idom forwarding.
>>> 1176:   void replace_ctrl_node_and_forward_ctrl_and_idom(Node *old_node, Node *new_node) {
>> 
>> Drive-by comment (sorry): I think this is way too heavy. Descriptive names are good but for complex methods, not all the semantics can be put into the name but should rather be in a comment.
>> 
>> Couldn't we just name these `replace_and_update_ctrl` and `update_ctrl`? I think this entails updating idom which is dependent on ctrl. And the comments explain the details well enough.
>
> @TobiHartmann 
> 
> `update_ctrl`: Sounds too much like `set_ctrl`, but it is not at all similar conceptually.
> 
> What about:
> - `install_ctrl_and_idom_forwarding` -> `forward_ctrl`
> - `replace_ctrl_node_and_forward_ctrl_and_idom` -> `replace_node_and_forward_ctrl`
>   - Because it is really a specialization of `_igvn.replace_node`, so it should have some name similarity.
> 
> What do you think?

Yes, that's much better, good with me!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447155999

From ayang at openjdk.org  Tue Oct 21 08:17:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 08:17:33 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
Message-ID: <7czjnRkioTvwfdr0hxlBvTXkbw-4lP4yld-6Nint2lw=.d2b85ba9-f2cd-4e52-bca8-d85817726938@github.com>

On Tue, 14 Oct 2025 13:35:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
>> 
>> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
>> 
>> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
>> 
>> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
>> 
>> Test: tier1?8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8924d866...273c2003

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26700#issuecomment-3425335159

From ayang at openjdk.org  Tue Oct 21 08:17:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 08:17:34 GMT
Subject: Integrated: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <7LJx42wgyM6gU-5iJ5qvvPyzAuXY_x-FUrnWDUUUqhE=.017426b8-46ba-4326-bc14-26badae457fe@github.com>

On Fri, 8 Aug 2025 14:50:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`.
> 
> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.
> 
> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`.
> 
> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary.
> 
> Test: tier1?8

This pull request has now been integrated.

Changeset: 2be273f2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2be273f20f839980f22a74b88b74fc5754fa0c11
Stats:     238 lines in 15 files changed: 77 ins; 93 del; 68 mod

8346005: Parallel: Incorrect page size calculation with UseLargePages

Co-authored-by: Joel Sikstr?m <jsikstro at openjdk.org>
Reviewed-by: jsikstro, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/26700

From epeter at openjdk.org  Tue Oct 21 08:20:26 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 08:20:26 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v7]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <5NCbOn36uvy0cTen6j1ys_E4uDD-qWjW5N1B-doqCGU=.4f75ce02-f27c-4d9a-ace8-5073f211d78f@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  renaming for Tobias

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/a91396be..aaa91d18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=05-06

  Stats: 49 lines in 8 files changed: 0 ins; 1 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From epeter at openjdk.org  Tue Oct 21 08:23:14 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 08:23:14 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v7]
In-Reply-To: <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <7nfOylxfH7KPKOj291d3N3f67w5rKrGwhc17OKv77NY=.afb319e9-f3be-4330-abe9-b1c19b61dc75@github.com>
Message-ID: <jUjLUNe7Q0eayM9_Fc6xchOKyxrruO0AAV2dehMpIvw=.5c91e8ea-98d9-448d-8f35-3f614d80402c@github.com>

On Mon, 20 Oct 2025 13:55:49 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renaming for Tobias
>
> Thanks a lot for following up with a documentation and renaming! Some small suggestions, otherwise, looks good!
> 
> Note: There are some build failures in GHA.

@chhagedorn Thanks for all the suggestions / comments, I think I applied them all now :)

@TobiHartmann thanks for the drive-by comment / suggestion.

@rwestrel You are somewhat familiar with this code, would you mind reviewing?

@vnkozlov You may also want to have quick look, just so you are aware of the renamings. But feel free to also review ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27892#issuecomment-3425369640

From mli at openjdk.org  Tue Oct 21 08:32:11 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Oct 2025 08:32:11 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
Message-ID: <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>

> Hi,
> Can you help to review this trivial patch?
> `verify_xxx` verify_xxx in interp_masm_riscv.hpp should be consistent.
> 
> Thanks!

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  add NOT_DEBUG_RETURN

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27894/files
  - new: https://git.openjdk.org/jdk/pull/27894/files/47ee73bc..6dbe8748

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27894&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27894&range=00-01

  Stats: 14 lines in 3 files changed: 0 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27894/head:pull/27894

PR: https://git.openjdk.org/jdk/pull/27894

From mli at openjdk.org  Tue Oct 21 08:32:12 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Oct 2025 08:32:12 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
In-Reply-To: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
Message-ID: <FsdvR7iXBn10_YcA8iQDghVGJueX_qZR_3n74mqy58A=.63b18279-de04-4747-a5ef-2eba535586de@github.com>

On Mon, 20 Oct 2025 09:36:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this trivial patch?
> `verify_xxx` verify_xxx in interp_masm_riscv.hpp should be consistent.
> 
> Thanks!

Ah, you're right. Thanks!

I'll make the `verify_` methods in interp_masm_riscv.hpp consistent with each other. Can you have another look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27894#issuecomment-3425378756

From rehn at openjdk.org  Tue Oct 21 08:33:44 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Oct 2025 08:33:44 GMT
Subject: RFR: 8368724: RISC-V: Remove AvoidUnalignedAccesses Flag [v7]
In-Reply-To: <9LF0mPPgOWE4Ts4WMoRnoo5Bdq5C1p9u5H-P0iBJFgw=.72f9eb2a-8468-4e76-820a-9c29a9c97197@github.com>
References: <bwPsRUu6nY4b0erzZotiRmuENaLPvfiYJ3jimm8IMDY=.71626371-eb12-4632-9d36-af36393a3f72@github.com>
 <9LF0mPPgOWE4Ts4WMoRnoo5Bdq5C1p9u5H-P0iBJFgw=.72f9eb2a-8468-4e76-820a-9c29a9c97197@github.com>
Message-ID: <Dx39F2KtbQAEkVddc3v2Jexi_zrs2PlYfEeKlM9PDaE=.a896dab5-9c6b-4f56-bea0-677a5388c74e@github.com>

On Thu, 16 Oct 2025 02:53:36 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:

>> According to the discuss in https://github.com/openjdk/jdk/pull/27445#, we can use UseUnalignedAccesses and !UseUnalignedAccesses to cover the AvoidUnalignedAccesses Flag, so I Remove the AvoidUnalignedAccesses Flag in this patch
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the use of UseUnalignedAccesses flag after it properly assigned.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3425407993

From thartmann at openjdk.org  Tue Oct 21 08:38:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 08:38:23 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v7]
In-Reply-To: <5NCbOn36uvy0cTen6j1ys_E4uDD-qWjW5N1B-doqCGU=.4f75ce02-f27c-4d9a-ace8-5073f211d78f@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <5NCbOn36uvy0cTen6j1ys_E4uDD-qWjW5N1B-doqCGU=.4f75ce02-f27c-4d9a-ace8-5073f211d78f@github.com>
Message-ID: <mJeSrEFk1STM4W6SQSBQ1gOhopxridgWoLmLRmewNuQ=.69d1d78e-0ddb-4605-b604-e06669229104@github.com>

On Tue, 21 Oct 2025 08:20:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
>> 
>> Here, I'm doing the following:
>> - Add more documentation, and improve it in other cases.
>> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
>> - Made some methods private, and added some additional asserts.
>> 
>> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
>> 
>> Related issues:
>> https://github.com/openjdk/jdk/pull/27889
>> https://github.com/openjdk/jdk/pull/15720
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renaming for Tobias

Nice improvement, looks good to me!

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27892#pullrequestreview-3359424704

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v14]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <og-MzkWyLi7rxNct6NRjNzd1ySH4z2hQgzjtFQhUuRQ=.d033e524-3b89-4963-a03b-f4cdf284b92a@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with five additional commits since the last revision:

 - jvmti errors
 - indent
 - close
 - rephrase
 - PidJcmdExecutor. unused import. cc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/30b2cf96..925f9fc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=12-13

  Stats: 59 lines in 2 files changed: 19 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:42 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>
Message-ID: <JdmjkJ85SqHoUfwvC1EvKbJx8njVF9Yy5k2HaevpdeM=.5e3f9ffc-f22a-4eea-8ebf-8cfd1e0d7b04@github.com>

On Mon, 20 Oct 2025 21:01:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 35:
> 
>> 33: import java.io.InputStream;
>> 34: import java.util.Objects;
>> 35: import java.util.concurrent.TimeUnit;
> 
> Unused imports

bd4b98a7ad038a4516db7caa8d62204ba760a79c

> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 99:
> 
>> 97: 
>> 98:         ProcessBuilder pb = new ProcessBuilder(jcmd.getCommand());
>> 99:         OutputAnalyzer out = new OutputAnalyzer(pb.start());
> 
> I'd suggest to use `jdk.test.lib.dcmd.PidJcmdExecutor`
> Then this can be simplified to something like
> 
> 
> OutputAnalyzer out = new PidJcmdExecutor().execute("JVMTI.agent_load some.jar");

Thanks, fixed in bd4b98a7ad038a4516db7caa8d62204ba760a79c

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447476586
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447476248

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:43 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
Message-ID: <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>

On Tue, 21 Oct 2025 07:08:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:
> 
>> 45: 
>> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
>> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);
> 
> Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)

Fixed in a401f0a118785f600e70ca0099802ff05e967bc9 and 925f9fc828597f920e4b800d63428e414f8b0345. I thought the error could be printed with `jvmti->GetErrorName`, but I guess that would introduce unnecessary complication. Let me know what you think @sspitsyn.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447475060

From fandreuzzi at openjdk.org  Tue Oct 21 09:43:21 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:43:21 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v15]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <Ler7QHsjSwjk3Ywx-MsqbhxOPomdgyu-WM0gjkxX86c=.7958318f-5b18-4682-b1c5-5e1df6395037@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  empty stderr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/925f9fc8..60d6fdff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=13-14

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Tue Oct 21 09:43:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:43:24 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>
Message-ID: <Ya-VpLXP4M_w9rn-5ri_aYvg1ThFnN-d8AM4E6yYl8A=.6eafcd95-0321-4ef2-9443-2a7f013171c1@github.com>

On Mon, 20 Oct 2025 20:40:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 66:
> 
>> 64:     @AfterAll
>> 65:     static void stopChild() throws Exception {
>> 66:         child.destroy();
> 
> Is it possible to let the process to complete normally instead of killing it?  (by writing into stream?)
> So test can verify that process is exited with code 0 and nothing is broken by this attaching attempt.

Yeah that sounds reasonable, thanks. Please check the latest revision of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447510551

From chagedorn at openjdk.org  Tue Oct 21 09:45:17 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 09:45:17 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v7]
In-Reply-To: <5NCbOn36uvy0cTen6j1ys_E4uDD-qWjW5N1B-doqCGU=.4f75ce02-f27c-4d9a-ace8-5073f211d78f@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <5NCbOn36uvy0cTen6j1ys_E4uDD-qWjW5N1B-doqCGU=.4f75ce02-f27c-4d9a-ace8-5073f211d78f@github.com>
Message-ID: <AZEPsG0biTEWIPabPYSx7bMMvAYtHIcmPppQgfB3Oc0=.c27b2f44-130e-44ee-aef8-80c421477b7c@github.com>

On Tue, 21 Oct 2025 08:20:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
>> 
>> Here, I'm doing the following:
>> - Add more documentation, and improve it in other cases.
>> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
>> - Made some methods private, and added some additional asserts.
>> 
>> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
>> 
>> Related issues:
>> https://github.com/openjdk/jdk/pull/27889
>> https://github.com/openjdk/jdk/pull/15720
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renaming for Tobias

Good naming update! The update looks good to me apart from some last nits.

src/hotspot/share/opto/loopnode.hpp line 1161:

> 1159:   //   future.
> 1160:   //   Note: while the "idom" information is stored in the "_idom"
> 1161:   //   side-table, the idom forwarding piggy-packs on the ctrl

Suggestion:

  //   side-table, the idom forwarding piggybacks on the ctrl

src/hotspot/share/opto/loopnode.hpp line 1182:

> 1180:   // - Update the node inputs of all uses.
> 1181:   // - Lazily update the ctrl and idom info of all uses, via a ctrl/idom forwarding.
> 1182:   void replace_node_and_forward_ctrl(Node *old_node, Node *new_node) {

Suggestion:

  void replace_node_and_forward_ctrl(Node* old_node, Node* new_node) {

src/hotspot/share/opto/loopnode.hpp line 1269:

> 1267:       // the old (dead) idom node to the new (live) idom node, in possibly
> 1268:       // multiple idom forwarding steps.
> 1269:       // Note that we piggy-back on "_loop_or_ctrl" to do the forwarding,

Suggestion:

      // Note that we piggyback on "_loop_or_ctrl" to do the forwarding,

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27892#pullrequestreview-3359723589
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447507606
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447512959
PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2447509451

From fandreuzzi at openjdk.org  Tue Oct 21 09:47:52 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:47:52 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  cc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/60d6fdff..ba3dc024

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=14-15

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From duke at openjdk.org  Tue Oct 21 10:21:30 2025
From: duke at openjdk.org (Yuri Gaevsky)
Date: Tue, 21 Oct 2025 10:21:30 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6]
In-Reply-To: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
 <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com>
Message-ID: <nVuSA-26AuiKw0GVZ_H0EFYlEq17biSzSNgs4D8vFTE=.7f311fdd-4c24-425e-a3ad-d508b2353339@github.com>

On Tue, 12 Aug 2025 19:54:14 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

>> Hello All,
>> 
>> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
>> 
>> Thank you,
>> -Yuri Gaevsky
>> 
>> **Correctness checks:**
>>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.
>
> Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded check for zero length; changed lmul from m8 to m2.

.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3425823246

From fyang at openjdk.org  Tue Oct 21 10:54:28 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Oct 2025 10:54:28 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
Message-ID: <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>

On Tue, 21 Oct 2025 08:32:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this trivial patch?
>> `verify_xxx` verify_xxx in interp_masm_riscv.hpp should be consistent.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add NOT_DEBUG_RETURN

src/hotspot/cpu/riscv/interp_masm_riscv.hpp line 306:

> 304:   void verify_access_flags(Register access_flags, uint32_t flag,
> 305:                            const char* msg, bool stop_by_hit = true) NOT_DEBUG_RETURN;
> 306:   void verify_frame_setup() NOT_DEBUG_RETURN;

OK. Then can you remove the surrounding ASSERT of the use sites for consistency? It becomes unnecessary after adding `NOT_DEBUG_RETURN`. One example:

1075   // start execution
1076 #ifdef ASSERT
1077   __ verify_frame_setup();
1078 #endif

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27894#discussion_r2447668261

From mli at openjdk.org  Tue Oct 21 10:54:29 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Oct 2025 10:54:29 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
 <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>
Message-ID: <FGWyohpMEfM6v08klULdtYIpmRS-vgck5W94RUcHsKg=.a7da868f-45fa-4b39-90a8-09c206e81d20@github.com>

On Tue, 21 Oct 2025 10:45:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add NOT_DEBUG_RETURN
>
> src/hotspot/cpu/riscv/interp_masm_riscv.hpp line 306:
> 
>> 304:   void verify_access_flags(Register access_flags, uint32_t flag,
>> 305:                            const char* msg, bool stop_by_hit = true) NOT_DEBUG_RETURN;
>> 306:   void verify_frame_setup() NOT_DEBUG_RETURN;
> 
> OK. Then can you remove the surrounding ASSERT of the use sites for consistency? It becomes unnecessary after adding `NOT_DEBUG_RETURN`. One example:
> 
> 1075   // start execution
> 1076 #ifdef ASSERT
> 1077   __ verify_frame_setup();
> 1078 #endif

I think the `ASSERT`s around invocation of `verify_frame_setup` are already removed in this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27894#discussion_r2447677408

From fyang at openjdk.org  Tue Oct 21 10:54:30 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Oct 2025 10:54:30 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <FGWyohpMEfM6v08klULdtYIpmRS-vgck5W94RUcHsKg=.a7da868f-45fa-4b39-90a8-09c206e81d20@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
 <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>
 <FGWyohpMEfM6v08klULdtYIpmRS-vgck5W94RUcHsKg=.a7da868f-45fa-4b39-90a8-09c206e81d20@github.com>
Message-ID: <Vx_tLXJ4F40863qG5VOpjF1pHLpoV1OTskyjbrYW3kY=.0c6a570b-a11f-4432-af4d-d49b9c0fc6db@github.com>

On Tue, 21 Oct 2025 10:50:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/interp_masm_riscv.hpp line 306:
>> 
>>> 304:   void verify_access_flags(Register access_flags, uint32_t flag,
>>> 305:                            const char* msg, bool stop_by_hit = true) NOT_DEBUG_RETURN;
>>> 306:   void verify_frame_setup() NOT_DEBUG_RETURN;
>> 
>> OK. Then can you remove the surrounding ASSERT of the use sites for consistency? It becomes unnecessary after adding `NOT_DEBUG_RETURN`. One example:
>> 
>> 1075   // start execution
>> 1076 #ifdef ASSERT
>> 1077   __ verify_frame_setup();
>> 1078 #endif
>
> I think the `ASSERT`s around invocation of `verify_frame_setup` are already removed in this patch.

Ah, yes for this one. Sorry, I missed that. What about `verify_access_flags`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27894#discussion_r2447680968

From mli at openjdk.org  Tue Oct 21 11:06:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Oct 2025 11:06:03 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <Vx_tLXJ4F40863qG5VOpjF1pHLpoV1OTskyjbrYW3kY=.0c6a570b-a11f-4432-af4d-d49b9c0fc6db@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
 <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>
 <FGWyohpMEfM6v08klULdtYIpmRS-vgck5W94RUcHsKg=.a7da868f-45fa-4b39-90a8-09c206e81d20@github.com>
 <Vx_tLXJ4F40863qG5VOpjF1pHLpoV1OTskyjbrYW3kY=.0c6a570b-a11f-4432-af4d-d49b9c0fc6db@github.com>
Message-ID: <m2omdsB5sR5R5f3CBWkV6AbLFLnUTn1cfw2uYvobQdA=.7b4976f7-1827-41e1-aae4-4e0352f91ab0@github.com>

On Tue, 21 Oct 2025 10:51:38 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I think the `ASSERT`s around invocation of `verify_frame_setup` are already removed in this patch.
>
> Ah, yes for this one. Sorry, I missed that. What about `verify_access_flags`?

I also noticed `verify_access_flags`, but as all its usages are accompanied by some non-`NOT_DEBUG_RETURN` like `load_unsigned_short`, I think it's best to keep it as it is. How do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27894#discussion_r2447707795

From duke at openjdk.org  Tue Oct 21 11:15:17 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 21 Oct 2025 11:15:17 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
Message-ID: <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>

On Wed, 15 Oct 2025 14:00:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge from the main branch
>>  - Address review comments
>>  - Address review comments
>>  - Address review comments
>>  - The patch is contributed by @TheRealMDoerr
>>  - Offset the deoptimization handler entry point
>>    
>>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>>  - Revert "Ensure stub code is not adjacent to a call"
>>  - Ensure stub code is not adjacent to a call
>>  - Address review comments
>>  - 8365047: Remove exception handler stub code in C2
>>    
>>    The C2 exception handler stub code is only a trampoline to the
>>    generated exception handler blob. This change removes the extra
>>    step on the way to the generated blob.
>>    
>>    According to some comments in the source code, the exception handler
>>    stub code used to be patched upon deoptimization, however presumably
>>    these comments are outdated as the patching upon deoptimization happens
>>    for post-call NOPs only.
>
> One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
> SIGSEGV in caller_is_deopted:
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
> V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
> v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c
> 
> 
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000
> 
> 
> That address is at the end of the stub section:
> 
> 
> R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
> {0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
>  - ---- fields (total size 5 words):
>  - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
>  - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
>  - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
>  - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
>  - transient 'size' 'I' @24  60 (0x0000003c)
>  - transient 'modCount' 'I' @28  60 (0x0000003c)
>  - 'threshold' 'I' @32  96 (0x00000060)
>  - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
> R1 =0x0000001fd503201f is an unknown value
> R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
> Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
>  total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
>  main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
>  stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
>  mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
>  relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
>  metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
>  immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
>  dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
>  scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
>  scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
>  speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
> 0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
> --------------------------------------------------------------------------------
>   0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
>   0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
> --------------------------------------------------------------------------------
> R3 =0x0000f7cf03817578 points into unknown readable ...

Thank you for the reviews and help with testing, @TheRealMDoerr, @adinn.

Apologies for the delayed response - it is due to being out of office. I'm planning to resume work on this PR from tomorrow.

I believe the specific issue revealed in the failed test is due to the `NativePostCallNop::check` is trying to read both NOP and MOVK in a combined 8-byte read, which requires at least two instructions after the perceived call site to be readable. In this case, the deoptimization handler stub code has only one valid instruction after the entry point. As the stub code is positioned right at the end of a page, presumably with the next page not mapped, the combined read fails. A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.

This issue appears to be potentially independent from the `far_jump` being used instead of `far_call`.

I am planning to spend some time figuring out why tests on my side didn't catch the issue with `far_jump` used instead of `far_call`, and on preparing a test that would deterministically detect the issue with stub code positioned right before an unmapped page.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3426020854

From fyang at openjdk.org  Tue Oct 21 11:27:26 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Oct 2025 11:27:26 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
Message-ID: <34ICSgSHhlPgGKV7y_Ri_254S9Y4W-xqRAq5KOdB3z0=.ecfb0532-a19c-4f9b-bd26-0d4df04a7f40@github.com>

On Tue, 21 Oct 2025 08:32:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this trivial patch?
>> `verify_xxx` verify_xxx in interp_masm_riscv.hpp should be consistent.
>> 
>> Thanks!
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add NOT_DEBUG_RETURN

Thanks!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27894#pullrequestreview-3360088429

From fyang at openjdk.org  Tue Oct 21 11:27:28 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Oct 2025 11:27:28 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <m2omdsB5sR5R5f3CBWkV6AbLFLnUTn1cfw2uYvobQdA=.7b4976f7-1827-41e1-aae4-4e0352f91ab0@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
 <hQMdxc4W4bpOxo6LY9s7bUqlOBXnyQeR6k9Xd--vDFc=.155bd057-5fac-4342-86f5-49edb5d06bf9@github.com>
 <FGWyohpMEfM6v08klULdtYIpmRS-vgck5W94RUcHsKg=.a7da868f-45fa-4b39-90a8-09c206e81d20@github.com>
 <Vx_tLXJ4F40863qG5VOpjF1pHLpoV1OTskyjbrYW3kY=.0c6a570b-a11f-4432-af4d-d49b9c0fc6db@github.com>
 <m2omdsB5sR5R5f3CBWkV6AbLFLnUTn1cfw2uYvobQdA=.7b4976f7-1827-41e1-aae4-4e0352f91ab0@github.com>
Message-ID: <Tasi4M7lwwWNaRXpJDNLGoTVJKJBgZLNiAVZGTwH9Ok=.8dac7b35-1154-439a-8a89-1a980ab4d140@github.com>

On Tue, 21 Oct 2025 11:03:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Ah, yes for this one. Sorry, I missed that. What about `verify_access_flags`?
>
> I also noticed `verify_access_flags`, but as all its usages are accompanied by some non-`NOT_DEBUG_RETURN` like `load_unsigned_short`, I think it's best to keep it as it is. How do you think?

Yes, I see that. I think that's OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27894#discussion_r2447781727

From mli at openjdk.org  Tue Oct 21 11:30:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Oct 2025 11:30:26 GMT
Subject: RFR: 8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp
 [v2]
In-Reply-To: <34ICSgSHhlPgGKV7y_Ri_254S9Y4W-xqRAq5KOdB3z0=.ecfb0532-a19c-4f9b-bd26-0d4df04a7f40@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
 <c4VvYL9HK6t3JPy34eenkFAVEUWWdwzngMXXe-90hQE=.91c36d9c-7007-41de-bbe7-17e000eb70d6@github.com>
 <34ICSgSHhlPgGKV7y_Ri_254S9Y4W-xqRAq5KOdB3z0=.ecfb0532-a19c-4f9b-bd26-0d4df04a7f40@github.com>
Message-ID: <Tcd3lybZOEYQXgNwL5Zx2DEY12X3ptZn1cSWnvk9VU0=.6dc533fd-c241-424c-8395-2f94c902dddc@github.com>

On Tue, 21 Oct 2025 11:24:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add NOT_DEBUG_RETURN
>
> Thanks!

@RealFYang Thank you for the quick response!

I think this is a trivial one, will integrate it later. Otherwise please let me know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27894#issuecomment-3426109389

From epeter at openjdk.org  Tue Oct 21 12:17:23 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 12:17:23 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v8]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <j97hwAtpnFqt0j8aZRfQtX2g5lEqaMde-JswAPvDwis=.c8fa85f2-cf87-4fa6-995f-7e322685b578@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/aaa91d18..ac057395

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From dzhang at openjdk.org  Tue Oct 21 12:19:28 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 21 Oct 2025 12:19:28 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v4]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <nkrwTfdE-6572HYFXQ5sCHRS9so9BizCmnf2CPkyx98=.9b398027-1f28-4fa9-86bc-e67f70f4fe6b@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8368722
 - Merge remote-tracking branch 'upstream/master' into JDK-8368722-20251009
 - Add supports_misaligned_vector_accesses
 - 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access

-------------

Changes: https://git.openjdk.org/jdk/pull/27506/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=03
  Stats: 34 lines in 22 files changed: 33 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From aph at openjdk.org  Tue Oct 21 12:44:23 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 12:44:23 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <leXzT8VDccm4STu0673und3AwpVtGY_1cIkGFrGgHSY=.f85fc215-d22b-4267-b5e6-f6500f410967@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <leXzT8VDccm4STu0673und3AwpVtGY_1cIkGFrGgHSY=.f85fc215-d22b-4267-b5e6-f6500f410967@github.com>
Message-ID: <HS_C7XH0E1ZPX2-TtlzT_x9AjU_5P_-5UMlmC8Nmxe4=.a59b8ed4-dd0a-45b6-b3f9-3ca88a992270@github.com>

On Mon, 20 Oct 2025 14:35:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
>> 
>> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
>> 
>> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
>> 
>> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
>> 
>> We mark all sites that we know will write to code memory with
>> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
>> 
>> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
>> 
>> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
>> 
>> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

Finally, I think this is done. Probably.

I was blocked for a while because the test for healing didn't work on the GitHub builders, but did work whenever people tested it. It turns out that the Virtual Macs on the GitHub systems don't support JIT protection at all, so there's nothing we can do to test this PR in GitHub.

@dean-long, can you give this PR a run through the Oracle internal builders, to be safe? Then I'll integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3426408787

From aph at openjdk.org  Tue Oct 21 12:50:53 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 12:50:53 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <HS_C7XH0E1ZPX2-TtlzT_x9AjU_5P_-5UMlmC8Nmxe4=.a59b8ed4-dd0a-45b6-b3f9-3ca88a992270@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <leXzT8VDccm4STu0673und3AwpVtGY_1cIkGFrGgHSY=.f85fc215-d22b-4267-b5e6-f6500f410967@github.com>
 <HS_C7XH0E1ZPX2-TtlzT_x9AjU_5P_-5UMlmC8Nmxe4=.a59b8ed4-dd0a-45b6-b3f9-3ca88a992270@github.com>
Message-ID: <JmEMJqtGc8y3StpjPyrN4kQQAKaXwz7WvtpW9yDZztQ=.baa9dbf4-5672-4b64-aa6b-4339d40b41ee@github.com>

On Tue, 21 Oct 2025 12:41:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Then I'll integrate.

Hold on, I need to merge from master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3426440055

From aph at openjdk.org  Tue Oct 21 12:51:55 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 12:51:55 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions [v2]
In-Reply-To: <Oa6_2j1Tm2JYxrAPj8D4M08evpBIg-7d-pq6JnFPF7Q=.3ad303df-1af4-48fb-a993-84cffaf62a50@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
 <Oa6_2j1Tm2JYxrAPj8D4M08evpBIg-7d-pq6JnFPF7Q=.3ad303df-1af4-48fb-a993-84cffaf62a50@github.com>
Message-ID: <J4MKZ078lDl9mWUjv2MIw0tsLpxx3BOOm7P5RuZA45o=.6abd4729-1920-4c2a-8aa9-698d53bf5d08@github.com>

On Tue, 14 Oct 2025 10:31:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove the two parameter versions of MacroAssembler::target_addr_for_insn
>
> I did not expect to be saying this but it looks much better with templates!

@adinn please re-review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27649#issuecomment-3426447691

From ayang at openjdk.org  Tue Oct 21 13:06:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:06:11 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <rwoCbZT2B2ILiQ-sF75Up3o55cKjnWF0WCOZyduHFBY=.aca5cea4-f646-42fe-80eb-28085b7cfe33@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27898#issuecomment-3426507694

From ayang at openjdk.org  Tue Oct 21 13:06:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:06:12 GMT
Subject: Integrated: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <2qAezk5K68YOqi1HOuFAao_8Q1oAMjR2LGQx9GQs8rE=.79786d9e-9446-42d1-a762-d137f0c44a93@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 517d5437
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/517d54373fcabf4ef2c1d189b0c703a21be8eaf6
Stats:     13 lines in 5 files changed: 0 ins; 11 del; 2 mod

8370234: Remove CardTableBarrierSet::write_region

Reviewed-by: tschatzl, fandreuzzi

-------------

PR: https://git.openjdk.org/jdk/pull/27898

From eosterlund at openjdk.org  Tue Oct 21 13:06:43 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 13:06:43 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v6]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <L3FEXk8-Ucj9rQfe6kE1mwN-7jgRCc2VwKMTacbyBQA=.605b424f-9e72-4576-8bbd-e8170ef568b1@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision:

 - Clean up VMProps
 - Make AOTStreamableObjects diagnostic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/f7b9f32a..d0b42dfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=04-05

  Stats: 40 lines in 4 files changed: 2 ins; 28 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From alanb at openjdk.org  Tue Oct 21 13:12:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:12:57 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
 <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
Message-ID: <DSVgFKaNd2rNZ9tMNzCo2eGP3nz1YEJRV__1IuPSiGc=.8b7a6da1-cb55-4f73-80a0-320c9bdfc935@github.com>

On Mon, 20 Oct 2025 10:26:44 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

The GarbageCollectionStart and GarbageCollectionFinish events are specified to sent when the VM is "stopped" (VM agnostic wording). The only JVMTI functions specified to be allowed are the raw monitor and the env local storage functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426554971

From d.yamazaki at peya.tokyo  Tue Oct 21 13:22:05 2025
From: d.yamazaki at peya.tokyo (Daisuke Yamazaki)
Date: Tue, 21 Oct 2025 22:22:05 +0900
Subject: =?UTF-8?Q?8357865:_Null_MethodHandle.i?=
 =?UTF-8?Q?nvokeExact_crashes_JDK_8=E2=80=9318.2?=
Message-ID: <19a06ef1ccc.75d7e1243239295.2898833841422701414@peya.tokyo>

Hello HotSpot developers,

This is my first time contributing to OpenJDK.

I have confirmed that JDK-8357865 also occurs on the following version on
native Windows 11 x64 (not WSL): 
  OpenJDK 9.0.4, 10.0.2, 11.0.2, 12.0.2, 13.0.2, 14.0.2, 15.0.2, 16.0.2, 
  17.0.2, 18.0.2.

The crash happens even with -Xint (interpreter mode), 
which suggests that this is a HotSpot native runtime issue, not limited to JIT.

Partial hs_err log:
    A fatal error has been detected by the Java Runtime Environment:
      EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdab1b10d0, pid=27592, tid=67948
    JRE version: OpenJDK Runtime Environment (18.0.2+9) (build 18.0.2+9-61)
    Java VM: OpenJDK 64-Bit Server VM (18.0.2+9-61, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
    Problematic frame:
    V  [jvm.dll+0x110d0]

Full hs_err_pid log is saved locally and can be shared if needed.

It seems that the issue is fixed sometime after JDK 19:
  openjdk version "19.0.1" 2022-10-18

It seems that the issue is fixed sometime after JDK 18, as it does not occur on JDK 19.

Thanks for your attention and guidance.

Best regards,
D. Yamazaki

From alanb at openjdk.org  Tue Oct 21 13:26:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:26:34 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Certainly, thanks for asking. Researchers in GC are using the GC start/end events (https://dl.acm.org/doi/10.1145/3669940.3707217, https://ieeexplore.ieee.org/document/9804613, https://dl.acm.org/doi/10.1145/3764118, https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various costs pertaining to GC. I believe one USP of using a JVMTI agent is that it does not require modification of the benchmarking code and allows usage of powerful features made available by framework such as libpfm.
> 
> So these JVMTI hooks are used to read CPU performance counters to get some estimations of various metrics, be it CPU time, cache-misses etc. However this imposes severe limitations especially when it comes GCs with concurrent parts. This patch will expand the capabilities for these users using JVMTI agents to profile applications.

I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools?  If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426635449

From dzhang at openjdk.org  Tue Oct 21 13:35:45 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 21 Oct 2025 13:35:45 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v5]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <2S1H0NFLgCaRpMNwqROZBg4iIOPu0GBgN-AsHiwQTVg=.16521ffa-7767-493d-81bf-4b5e24925583@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Add misaligned vector check during VM bootstrapping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/a5858ba5..2a2d65c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=03-04

  Stats: 110 lines in 3 files changed: 103 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From dzhang at openjdk.org  Tue Oct 21 13:35:46 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 21 Oct 2025 13:35:46 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <f83An8LDCCHH0mUT3L42RCeaYtR9jtq63k04kBApNcY=.1638d04c-2f60-4cf8-9247-ed75421fed3d@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <b7HOAPNfezUdGKpVFIf9NUu2AjiA0ILCVP0IzbOFqnM=.c47725e6-f84b-4932-a779-96954666992d@github.com>
 <f83An8LDCCHH0mUT3L42RCeaYtR9jtq63k04kBApNcY=.1638d04c-2f60-4cf8-9247-ed75421fed3d@github.com>
Message-ID: <v22mWTx1vX9v8RTWAVc2X6hNmDQqgqtgyTiNNRv4gmA=.fc4899fd-52a1-4c84-b127-7271ea8e70ed@github.com>

On Fri, 10 Oct 2025 09:23:31 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Mind you that the following tests explicitly are testing `-XX:-AlignVector` and won't work on hardware platforms without misaligned vector. But it doesn't seem to me reasonable to add a requirement like `@requires vm.opt.EnableVectorSupport == true` for them as they are superword tests. These tests were once enabled for RISC-V by: https://bugs.openjdk.org/browse/JDK-8352529. Maybe we should simply keep them disabled for this platform?
> 
> Simply distable them on riscv seems not a good idea. Maybe add `@requires (os.arch != "riscv64" | !vm.opt.AlignVector))`?

These tests all report IR-related errors because the first commit did not handle `AlignVector`, only modifying `EnableVectorSupport`. 
This prevented the corresponding nodes from being printed. After implementing AlignVector handling, cases that fail to satisfy constraints are now skipped and no longer generate errors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3426678036

From kbarrett at openjdk.org  Tue Oct 21 13:40:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 21 Oct 2025 13:40:52 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <YcmtJTZnuF3cvk_hmiLJ9iRPuemScRy8-TYOMxwR1aU=.02b82828-147c-4ee4-a653-b811ec505f55@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters 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 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/7b66e192...9d05cb8e

FWIW, I'm prototyping a possible change in g1ParScanThreadState.cpp that might
substantially reduce the amount of generated code there. It might not work
out; I haven't done any performance testing yet, and it's really easy to
introduce performance regressions when making changes to that code. But if it
does work, that might help with the problems here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3426717092

From eosterlund at openjdk.org  Tue Oct 21 13:44:02 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 13:44:02 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
 <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
Message-ID: <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>

On Fri, 10 Oct 2025 04:38:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > This makes the top level os::free_memory() the obvious default to use for most use cases that don't care if we are running in a container or not,
> 
> I have to disagree with the basic premise there. `os::free_memory` has to be specified to return some notion of "free memory" and that will either have to account for, or not account for, containers. The caller can't "not care" because the caller has to know why they are asking for this and what they expect to get back.
> 
> I'm not convinced this API split is actually a good fit in general. The existing os::xxx API exposes some values based on a very old monolithic model of program execution: free-memory, available-memory, swap-space, available-processors. But they are not very well-defined concepts in modern compute environments. We've tried to map these to things that containers expose but there isn't always a clear way to do so - ref "active processors" when CPU quotas are involved. Even on the "machine" side it is far from clear e.g. what should "active processors" return for the "machine"? Your implementation will return sched_getaffinity values which accounts for cpu-sets that can come from the container environment - so that isn't really the "machine" value.
> 
> It might be clearer to just define specific methods for the things that are currently missing that you need to query, rather than trying to generalize the existing poorly-defined API. If you insist that three API's is better then I would like to see clear specifications for what each of the method variants actually returns.

@dholmes-ora I'm struggling to understand where you would like this to go. Do you want users to always explicitly decide whether they want to look through the container or not. In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"? Or is it the word "machine" that you don't like?

Either way, this is what I need that I don't have access to today without breaking through the OS abstractions:
1) CPU quotas when running in a container.
2) The "machine" numbers when running in a container (which get overridden by container numbers).

Are you proposing we add new APIs for these things and leave everything else the way it is?

Just trying to understand what you mean so we can move forward with this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3426734621

From dzhang at openjdk.org  Tue Oct 21 13:45:10 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 21 Oct 2025 13:45:10 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <LhWiVqH80ZsREF0jWKLom-OGbI7DUVZCHlk-VvnGbAo=.0e8cfbc0-d412-4410-ae5a-89faadd85220@github.com>
 <sfsMpiTtLQfMYHEr3ztbNU6A-O2PVQ0kgBXiJjxYpsI=.52e3f953-8325-43e5-b90b-8d49e006de10@github.com>
Message-ID: <ZK9S0W7wawllzB1oL59GsnuiXjJLX2UK256K4cFH2rw=.790428ed-234e-48bc-be09-1028d32bb251@github.com>

On Thu, 9 Oct 2025 18:51:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184:
>> 
>>> 182:     FLAG_SET_DEFAULT(AlignVector,
>>> 183:       unaligned_vector.value() != MISALIGNED_VECTOR_FAST);
>>> 184:   } else if (AlignVector == false) {
>> 
>> Seems these code is not necessary, as when `unaligned_vector` is not retrieved from kernel for any reason, user might want to pass `-XX:-AlignVector`.
>> Your change disable this behaviour.
>
> It seems my advice is the opposite of @iwanowww's, let's see what others think.

Hi @Hamlin-Li @iwanowww
I've added detection logic to cover older kernels without good hwprobe support.
Could you help review it again? Thanks!

Below are some printed logs.
### K1 (kernel 6.6.63)

bianbu at k1:~$ ./jdk-10/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -XX:-AlignVector -version
OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh, it's missing dependent extension(s) v (disabled), Zfh (enabled)
OpenJDK 64-Bit Server VM warning: Misaligned vector accesses are not supported on this CPU
openjdk version "26-internal" 2026-03-17
OpenJDK Runtime Environment (build 26-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 26-internal-adhoc.zhangdingli.jdk, mixed mode)
bianbu at k1:~$ 
bianbu at k1:~$ ./jdk-10/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -XX:+AlignVector -version
OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh, it's missing dependent extension(s) v (disabled), Zfh (enabled)
openjdk version "26-internal" 2026-03-17
OpenJDK Runtime Environment (build 26-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 26-internal-adhoc.zhangdingli.jdk, mixed mode)


### K1 (kernel 6.15.2)

??[zhangdingli at bredos]?(~)
??[21:20]-(^_^)-[$] ./jdk-10/bin/java -XX:-AlignVector -version
OpenJDK 64-Bit Server VM warning: Misaligned vector accesses are not supported on this CPU
openjdk version "26-internal" 2026-03-17
OpenJDK Runtime Environment (build 26-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 26-internal-adhoc.zhangdingli.jdk, mixed mode)

??[zhangdingli at bredos]?(~)
??[21:22]-(^_^)-[$] ./jdk-10/bin/java -XX:+AlignVector -version
openjdk version "26-internal" 2026-03-17
OpenJDK Runtime Environment (build 26-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 26-internal-adhoc.zhangdingli.jdk, mixed mode)

I also conducted tests on QEMU w/ and w/o `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`, and the results were as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2448374184

From epeter at openjdk.org  Tue Oct 21 13:48:31 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 13:48:31 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
Message-ID: <u5JMUUFoMf_kPj4waUqh5z2BNB6TCuYNJpcqISpeMNI=.7630be6d-beb2-4216-8581-99baeb071dbb@github.com>

On Thu, 16 Oct 2025 14:45:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds the type Atomic<T>, to use as the type
>> of a variable that is accessed (including writes) concurrently by multiple
>> threads. This is intended to replace (most) uses of the current HotSpot idiom
>> of declaring a variable volatile and accessing that variable using functions
>> from the AtomicAccess class.
>> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
>> 
>> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
>> 
>> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
>> operationally the same, with the same API, hence uses and gtests didn't need
>> to change in that respect. Thanks to @stefank for raising this issue, and for
>> some suggestions toward improvements.
>> 
>> * Changed how fetch_then_set for atomic translated types is handled, to avoid
>> having the function there at all if it isn't usable, rather than just removing
>> it via SFINAE, leaving an empty overload set.
>> 
>> * Added more gtests.
>> 
>> Testing: mach5 tier1-6, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default construct translated atomic without SFINAE

Drive-by comments, feel free to ignore/resolve without much fuss ;)

src/hotspot/share/runtime/atomic.hpp line 84:

> 82: // Default construction of an atomic integer or atomic byte initializes the
> 83: // value to zero. Default construction of an atomic pointer initializes the
> 84: // value to null.

Suggestion:

// value to nullptr.

Optional, and total nit-pick. Reason: we are in C++ and not Java.

src/hotspot/share/runtime/atomic.hpp line 160:

> 158: //
> 159: // * Rather than load/store operations with a memory order parameter,
> 160: // Atomic<T> provides load_{relaxed,acquire}() and {relaxed,release}_store()

Optional, and totally nit-picky: consider writing them out, so we can grep easily.

test/hotspot/gtest/runtime/test_atomic.cpp line 33:

> 31: 
> 32: // These tests of Atomic<T> only verify functionality.  They don't verify
> 33: // atomicity.

Would that be desirable? Do we have tests, or an issue for it to do it in the future?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27539#pullrequestreview-3360752030
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448291763
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448316965
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448368295

From coleenp at openjdk.org  Tue Oct 21 13:57:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Oct 2025 13:57:27 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
Message-ID: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>

> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
> Tested with the test 100x.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix cut/paste errors.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27907/files
  - new: https://git.openjdk.org/jdk/pull/27907/files/8473e2c0..a392b95c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27907&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27907&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27907/head:pull/27907

PR: https://git.openjdk.org/jdk/pull/27907

From coleenp at openjdk.org  Tue Oct 21 13:57:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Oct 2025 13:57:30 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <Q4VQUW2qE2gK-LoTrQHMaRyKr7OWW9_X3sJJV5TBR4M=.b207fccb-ecfc-41f0-abb8-fed4a953ec5f@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <Q4VQUW2qE2gK-LoTrQHMaRyKr7OWW9_X3sJJV5TBR4M=.b207fccb-ecfc-41f0-abb8-fed4a953ec5f@github.com>
Message-ID: <LVwT0SVAyuqcswn_TTgD3JGdYZeoO2K-VUbsJEpSZjA=.43ea2986-b0b1-40ec-81fc-309ef29ad32c@github.com>

On Tue, 21 Oct 2025 01:49:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cut/paste errors.
>
> test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/PerformChecksHelper.java line 140:
> 
>> 138:             }
>> 139:         } catch (InvocationTargetException ite) {
>> 140:             if (ite.getCause() != null && ite.getCause().getMessage().trim().toLowerCase().contains("Metaspace")) {
> 
> Surely this can never be true as you converted to lowercase and are searching for uppercase 'M'. ??
> 
> And the `trim()` serves no purpose that I can see when you are using `contains`.

I think I did a bit too much cut/paste without reading it.  fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27907#discussion_r2448426452

From adinn at openjdk.org  Tue Oct 21 13:59:31 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 21 Oct 2025 13:59:31 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
Message-ID: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>

On Tue, 21 Oct 2025 11:12:45 GMT, Ruben <duke at openjdk.org> wrote:

> I believe the specific issue revealed in the failed test is due to the NativePostCallNop::check is trying to read both NOP and MOVK in a combined 8-byte read, which requires at least two instructions after the perceived call site to be readable. In this case, the deoptimization handler stub code has only one valid instruction after the entry point. As the stub code is positioned right at the end of a page, presumably with the next page not mapped, the combined read fails. A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.
> 
> This issue appears to be potentially independent from the far_jump being used instead of far_call.

You may well be correct in your assumption that the error is happening in `NativePostCallNop::check()`. I believe the check for in deopt may well do that. However, the `check()` method does not do a combined 8 byte read. What it does is a 4 byte read at the supplied pc (i.e one instruction's worth of data) to test whether those bytes encode a `nop` instruction. As the comment in the check method makes clear there is no need to test for a following `movz` because the JIT never generates a `bl; nop` or `brl; nop` that is not then followed by a `movz`.

The problem in this error case appears to be that the pc address being tested is `0x0000f7cf03c60000` which is indeed just off the end of the mapped heap, 2 words beyond the branch instruction that took us into the deopt handling code. That would indicate that this value somehow got installed into the link register `lr`. Now this register would have been written with `0x0000f7cf03c5fffc` if the C1 code had used `far_call`. Since we got to the check via a `far_jump` unfortunately `lr` did not get updated with the expected return address. It may be that `0x0000f7cf03c60000` ended up there by chance because `lr` was being used by the JITted code as a data register (that can happen).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3426822695

From adinn at openjdk.org  Tue Oct 21 14:09:27 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 21 Oct 2025 14:09:27 GMT
Subject: RFR: 8369211: AArch64: Devirtualize class RelocActions [v2]
In-Reply-To: <V8CHbJsAhpO_3OeV289k46NxoUa0O8wM8DKjTBFcIHQ=.aa25f0b7-6270-4a49-b6a3-511f806428c8@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
 <V8CHbJsAhpO_3OeV289k46NxoUa0O8wM8DKjTBFcIHQ=.aa25f0b7-6270-4a49-b6a3-511f806428c8@github.com>
Message-ID: <E9JjujLZmmTs_oONmhDl3f78bJuw6zl70n7y0o6ZKKU=.ce5f5233-7981-42fe-999f-d1ca294d0d09@github.com>

On Thu, 16 Oct 2025 15:52:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
>> 
>> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the two parameter versions of MacroAssembler::target_addr_for_insn

Still good.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27649#pullrequestreview-3361003522

From aph at openjdk.org  Tue Oct 21 14:29:56 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 14:29:56 GMT
Subject: Integrated: 8369211: AArch64: Devirtualize class RelocActions
In-Reply-To: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
References: <bUSR5ackNY561BdI_58V-TMKN6Up1ftRJeAWTl4TOFU=.627ad6af-ee9b-4de1-b8f0-10bb8a875ef0@github.com>
Message-ID: <SOBNBF266ojvDWA35On8v9wb9eBzgCiR4mE2Zc6beaU=.33f29cda-7605-4b9e-a827-abd672b97eec@github.com>

On Mon, 6 Oct 2025 15:14:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> RelocActions is instantiated every time we need to apply a reloc. There's really no need for this, and the use of virtual member functions and function pointers obfuscates the code.
> 
> While C++ compilers can devirtualize much of this, they don't always devirtualize all of it. Let's make RelocActions all static.

This pull request has now been integrated.

Changeset: 9a88d7f4
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a88d7f468cdd040bdf4e1ff9441dc9c66eab03e
Stats:     125 lines in 2 files changed: 5 ins; 44 del; 76 mod

8369211: AArch64: Devirtualize class RelocActions

Reviewed-by: adinn, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/27649

From kbarrett at openjdk.org  Tue Oct 21 14:58:30 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 21 Oct 2025 14:58:30 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
Message-ID: <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>

> Please review this change that adds the type Atomic<T>, to use as the type
> of a variable that is accessed (including writes) concurrently by multiple
> threads. This is intended to replace (most) uses of the current HotSpot idiom
> of declaring a variable volatile and accessing that variable using functions
> from the AtomicAccess class.
> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
> 
> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
> 
> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
> operationally the same, with the same API, hence uses and gtests didn't need
> to change in that respect. Thanks to @stefank for raising this issue, and for
> some suggestions toward improvements.
> 
> * Changed how fetch_then_set for atomic translated types is handled, to avoid
> having the function there at all if it isn't usable, rather than just removing
> it via SFINAE, leaving an empty overload set.
> 
> * Added more gtests.
> 
> Testing: mach5 tier1-6, GHA sanity tests

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  rename relaxed_store => store_relaxed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27539/files
  - new: https://git.openjdk.org/jdk/pull/27539/files/934a4ed2..f7e2d950

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=03-04

  Stats: 52 lines in 8 files changed: 0 ins; 0 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/27539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27539/head:pull/27539

PR: https://git.openjdk.org/jdk/pull/27539

From kbarrett at openjdk.org  Tue Oct 21 14:58:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 21 Oct 2025 14:58:34 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <u5JMUUFoMf_kPj4waUqh5z2BNB6TCuYNJpcqISpeMNI=.7630be6d-beb2-4216-8581-99baeb071dbb@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
 <u5JMUUFoMf_kPj4waUqh5z2BNB6TCuYNJpcqISpeMNI=.7630be6d-beb2-4216-8581-99baeb071dbb@github.com>
Message-ID: <Ed3OiUsqL5vqiBjck-DxzJ5m8UR1PX3RwooeYxlMikM=.83412047-08c2-4833-9700-5424642ee975@github.com>

On Tue, 21 Oct 2025 13:27:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   default construct translated atomic without SFINAE
>
> src/hotspot/share/runtime/atomic.hpp line 84:
> 
>> 82: // Default construction of an atomic integer or atomic byte initializes the
>> 83: // value to zero. Default construction of an atomic pointer initializes the
>> 84: // value to null.
> 
> Suggestion:
> 
> // value to nullptr.
> 
> Optional, and total nit-pick. Reason: we are in C++ and not Java.

We generally use "null" in comments, unless it's part of a code snippet.

> src/hotspot/share/runtime/atomic.hpp line 160:
> 
>> 158: //
>> 159: // * Rather than load/store operations with a memory order parameter,
>> 160: // Atomic<T> provides load_{relaxed,acquire}() and {relaxed,release}_store()
> 
> Optional, and totally nit-picky: consider writing them out, so we can grep easily.

Done. I'd missed that "relaxed_store" when renaming to "store_relaxed".

> test/hotspot/gtest/runtime/test_atomic.cpp line 33:
> 
>> 31: 
>> 32: // These tests of Atomic<T> only verify functionality.  They don't verify
>> 33: // atomicity.
> 
> Would that be desirable? Do we have tests, or an issue for it to do it in the future?

The comment is there to set expectations. Actually testing atomicity seems
like it would be really hard (maybe expensive and complex stress tests?), and
of little benefit. Failures could only arise if we have an obviously wrong
implementation (missing "lock" prefix, ll/sc, ordered load/store operations,
&etc as appropriate to the architecture), a broken compiler, or broken
hardware.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448658705
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448659543
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2448656589

From eosterlund at openjdk.org  Tue Oct 21 15:16:06 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:16:06 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Change streaming/mapping states to be binary instead of tri states

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/d0b42dfc..70fb7acc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=05-06

  Stats: 240 lines in 24 files changed: 105 ins; 87 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From mbaesken at openjdk.org  Tue Oct 21 15:18:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Oct 2025 15:18:32 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v2]
In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
Message-ID: <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>

> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
> error output is :
> 
> 
> java.lang.RuntimeException: Expected source information missing from output
> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
> 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:1474)

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27899/files
  - new: https://git.openjdk.org/jdk/pull/27899/files/090fcf27..13a1b423

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=00-01

  Stats: 25 lines in 4 files changed: 23 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899

PR: https://git.openjdk.org/jdk/pull/27899

From eosterlund at openjdk.org  Tue Oct 21 15:20:32 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:20:32 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
 <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
 <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>
Message-ID: <i5kBskWAAQEYzTPv_i90PiMpoDV0Pd3_6Gw6q49uqXI=.2944dd5a-c3be-48be-bbc0-bb0628e0ff5d@github.com>

On Mon, 20 Oct 2025 21:36:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Okay. @stefank is having a look at fixing this.
>
> I've sort-of implemented the second part of your comment about removing the tri-state:
> https://github.com/fisk/jdk/compare/8326035_JEP_object_streaming_v6...stefank:jdk:8326035_JEP_object_streaming_v6_stefank
> 
> The enum had *four* states (`uninitialized`, `mapping`, `streaming`, `none`) and while reading this PR the `none` part seemed unusual. After working on the proposed patch I think the `none` value served a purpose, but let's see if a patch without it makes sense.
> 
> The patch still uses an enum instead of two booleans. I think that makes the code more readable because we encode the three states with three enum values. If we were to use two booleans we would end up with four possible states and then the reader of the code would have to figure out which of the forth state is an invalid state. I think what we have in the patch above is safer. (Let's revisit this if this still is a blocker)
> 
> So, I removed `none` and added strict asserts that you are not allowed to ask for the mode until the variable has transitioned away from `uninitialized` to either `mapping` or `streaming`. After the variable has been initialized the questions are binary and you have `is_loading_mapping_mode() == !is_loading_streaming_mode()`. I don't see the appeal to remove one of these two functions, because that just adds negation to the code and that makes it harder to read. (We can experiment with that in a separate patch)
> 
> I tried to take it even further and join these `is_loading` functions with the `is_archived_heap_in_use` and the `is_in_use` properties, but that hit problems with error-edge cases. I have a feeling that the `none` value dealt with these problems.
> 
> Some more details about the edge-case problems:
> 
> During loading of the heap archive there is a duration where we have decided that we are going to load the archived heap and what loading mode to use, but the archive has not been loaded enough have the `is_archived_heap_in_use` function return `true`. During these early stages we must use the `is_loading` and `is_loading_` functions. After `is_archived_heap_in_use` starts to return the correct value, the code likely needs to use that function instead of the `is_loading` functions. Some parts of the AOT/CDS code will bug out if you try to use the `is_loading` functions after an error.
> 
> So, I've tried to keep the usages of `is_loading` functions inside AOT/CDS code. The `is_archived_heap_in_use`, or one of it's sub-components (E.g. `AOTMappedHeapLoader:is_in_use()`), are...

Thank you for the contribution, @stefank. I added it to the PR. @iklam hope this addresses your concerns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2448732105

From eosterlund at openjdk.org  Tue Oct 21 15:20:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:20:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <Jrqk8NmgvIbXGHjFR-HHlMRBdOMdpDJxty4NBlm61S8=.71b10538-fd36-4d1a-8245-08f4f13d7320@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

We discussed that the AOTStreamableObjects should be a diagnostic JVM option. There isn't really a good reason for users to fiddle with it, but is there as a diagnostic thing. So I made that change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3427217293

From dzhang at openjdk.org  Tue Oct 21 15:37:27 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 21 Oct 2025 15:37:27 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v6]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <CCMuKoy2E8f163rL81YzVoJvdECCgspSAd9Mk5aMiWk=.fcc7163c-88ad-464a-91ee-e53ea7ff58a1@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Simplify supports_misaligned_vector_accesses

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/2a2d65c6..33eba42f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=04-05

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From aph at openjdk.org  Tue Oct 21 15:54:18 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 15:54:18 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v22]
In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
Message-ID: <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>

> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
> 
> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
> 
> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
> 
> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
> 
> We mark all sites that we know will write to code memory with
> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
> 
> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
> 
> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
> 
> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ...

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge from maaster
 - Merge from maaster
 - Merge branch 'master' into JDK-8328306
 - Cleanup
 - Check for working WX
 - Check for working WX
 - Check for working WX
 - Check for working WX
 - Check for working WX
 - Check for working WX
 - ... and 33 more: https://git.openjdk.org/jdk/compare/9a88d7f4...42e5505d

-------------

Changes: https://git.openjdk.org/jdk/pull/26562/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=21
  Stats: 458 lines in 35 files changed: 387 ins; 28 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562

PR: https://git.openjdk.org/jdk/pull/26562

From aph at openjdk.org  Tue Oct 21 15:54:19 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Oct 2025 15:54:19 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v21]
In-Reply-To: <JmEMJqtGc8y3StpjPyrN4kQQAKaXwz7WvtpW9yDZztQ=.baa9dbf4-5672-4b64-aa6b-4339d40b41ee@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <leXzT8VDccm4STu0673und3AwpVtGY_1cIkGFrGgHSY=.f85fc215-d22b-4267-b5e6-f6500f410967@github.com>
 <HS_C7XH0E1ZPX2-TtlzT_x9AjU_5P_-5UMlmC8Nmxe4=.a59b8ed4-dd0a-45b6-b3f9-3ca88a992270@github.com>
 <JmEMJqtGc8y3StpjPyrN4kQQAKaXwz7WvtpW9yDZztQ=.baa9dbf4-5672-4b64-aa6b-4339d40b41ee@github.com>
Message-ID: <ebT-ps8mc6UsCcojwnkKGh1fQtwhTVt3WeDFq8p_o90=.541776cd-2221-4ab9-807e-78c1e9c6bd57@github.com>

On Tue, 21 Oct 2025 12:48:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Then I'll integrate.
> 
> Hold on, I need to merge from master.

Ready now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3427361776

From epeter at openjdk.org  Tue Oct 21 15:57:16 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 15:57:16 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v8]
In-Reply-To: <j97hwAtpnFqt0j8aZRfQtX2g5lEqaMde-JswAPvDwis=.c8fa85f2-cf87-4fa6-995f-7e322685b578@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <j97hwAtpnFqt0j8aZRfQtX2g5lEqaMde-JswAPvDwis=.c8fa85f2-cf87-4fa6-995f-7e322685b578@github.com>
Message-ID: <gCYYH2Z77VqH0hvfGAH0Z6qjbd4TSUujm8w8F3W7U-o=.75c72a20-54c8-4cc7-9fb8-e4b19a86d0e8@github.com>

On Tue, 21 Oct 2025 12:17:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
>> 
>> Here, I'm doing the following:
>> - Add more documentation, and improve it in other cases.
>> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
>> - Made some methods private, and added some additional asserts.
>> 
>> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
>> 
>> Related issues:
>> https://github.com/openjdk/jdk/pull/27889
>> https://github.com/openjdk/jdk/pull/15720
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Seems GHA is giving me some failures I did not see in our internal testing:

`compiler.lib.ir_framework.flag.FlagVM compiler.gcbarriers.TestShenandoahBarrierExpansion
`

#  Internal Error (/home/runner/work/jdk/jdk/src/hotspot/share/opto/loopnode.hpp:1168), pid=5884, tid=5904
#  assert(!has_ctrl(old_node) && old_node->is_CFG() && old_node->in(0) == nullptr) failed: must be dead ctrl (CFG) node


This is part of the assert I added. Will have to investigate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27892#issuecomment-3427379718

From krk at openjdk.org  Tue Oct 21 16:31:48 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 21 Oct 2025 16:31:48 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat 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 elfdecoder-JDK-8334866
 - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
 - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
 - 8334866: Cache debug_aranges for faster address lookups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/fe32a078..623870ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=02-03

  Stats: 25938 lines in 681 files changed: 14672 ins; 8044 del; 3222 mod
  Patch: https://git.openjdk.org/jdk/pull/27337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337

PR: https://git.openjdk.org/jdk/pull/27337

From phubner at openjdk.org  Tue Oct 21 16:43:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 21 Oct 2025 16:43:50 GMT
Subject: RFR: 8365896: Remove unnecessary explicit buffer nul-termination after
 using os::snprintf
Message-ID: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>

Hi all,

This PR removes some leftover null terminators and buffer reservations for null terminators, which have been made redundant with the new `snprintf` family of functions. 

In order to find these occurrences, I methodologically used multiple regular expressions over the entire codebase. I took a look at around 130 files in total, and updated where appropriate. 

I?ve tested this through tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64) and Windows (x64). I?ve also successfully compiled for PowerPC and Zero on Linux.

-------------

Commit messages:
 - Remove unneccessary null terminator reservations.
 - Remove redundant null termination.

Changes: https://git.openjdk.org/jdk/pull/27920/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27920&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365896
  Stats: 23 lines in 10 files changed: 1 ins; 9 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27920/head:pull/27920

PR: https://git.openjdk.org/jdk/pull/27920

From valeriep at openjdk.org  Tue Oct 21 18:22:20 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 21 Oct 2025 18:22:20 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
Message-ID: <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>

On Tue, 21 Oct 2025 00:05:31 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

Changes look fine, thanks~

-------------

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27807#pullrequestreview-3362117409

From fandreuzzi at openjdk.org  Tue Oct 21 18:55:00 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 18:55:00 GMT
Subject: RFR: 8370229: Remove unused method declarations after JDK-8322630
Message-ID: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>

Trivial removal of two methods declarations which are unused after JDK-8322630.

-------------

Commit messages:
 - remove

Changes: https://git.openjdk.org/jdk/pull/27923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370229
  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27923/head:pull/27923

PR: https://git.openjdk.org/jdk/pull/27923

From sspitsyn at openjdk.org  Tue Oct 21 19:08:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:48 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
 <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
Message-ID: <y9wgNd7XViOW43bMP3CEAR5EVv7DVCoABHhvgXXul2o=.d5fbd3cc-5a28-4322-b808-759974d5c1e1@github.com>

On Tue, 21 Oct 2025 13:24:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools? If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

Thank you, Alan. There was some offline Slack conversation with Ron and Jonas. Conclusion is the JMX support should be enough for this. So, I've closed the enhancement as WNF and this PR as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3428949447

From sspitsyn at openjdk.org  Tue Oct 21 19:08:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:49 GMT
Subject: Withdrawn: 8369449: Spec: introduce new JVMTI function
 GetTotalGCCpuTime
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <_ipWevP4P2gHRrOmOncxXrrOXkwa1kn9rvLtKUHKK_Q=.87a85881-c8ea-4321-87f1-67240d06883a@github.com>

On Fri, 17 Oct 2025 21:02:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27879

From amenkov at openjdk.org  Tue Oct 21 21:28:50 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 21 Oct 2025 21:28:50 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
Message-ID: <PRjp8AbuSMpbTneAlLJ2pYxbQqLshCDjgGA3SnJWOaM=.039679a9-7525-44bb-ad38-e9122edf289b@github.com>

On Tue, 21 Oct 2025 09:47:52 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3362764848

From sspitsyn at openjdk.org  Tue Oct 21 22:53:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 22:53:49 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
Message-ID: <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>

On Tue, 21 Oct 2025 09:47:52 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

The fix is good. I've posted a couple of nits though.

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 47:

> 45:  * @run junit TestEarlyDynamicLoad
> 46:  */
> 47: public class TestEarlyDynamicLoad {

Nit: It is convenient if the test folder name matches the test class name. There are several cases where this is broken in our testbase. But it is still a good idea to keep this invariant where possible.

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 54:

> 52:     fprintf(stderr, "JVMTI error occurred during SetEventNotificationMode\n");
> 53:     return 1;
> 54:   }

Nit: The returned values have to be JNI_ERR or JNI_OK.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3362992561
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2449910819
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2449902636

From dlong at openjdk.org  Tue Oct 21 23:22:18 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 21 Oct 2025 23:22:18 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
 <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
 <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>
Message-ID: <4Cj8ndIna8Do2EfcPsFR85vpAsHGPKtwAvrgp2dTkxU=.e996f1ed-c3a7-45be-a723-190db1bbea73@github.com>

On Sat, 18 Oct 2025 10:13:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I am tempted to say yes, for consistency, but it probably won't make much of a difference either way.  But now I am wondering, if these cold native wrappers continue to be immortal, then do they really need to give them nmethod entry barriers?  Removing the barrier could remove some overhead.  Whatever direction we decide to go, it would be good to add a comment here explaining the decision and/or trade-offs.
>
> Is it actually possible to remove entry barriers for _any_ garbage collectable nmethod? How can we know an nmethod is not used anymore, even when it is made not entrant? `is_cold()` bails out when an nmethod does not support entry barriers:
> 
> // On platforms that don't support nmethod entry barriers, we can't
> // trust the temporal aspect of the gc epochs. So we can't detect
> // cold nmethods on such platforms.
> 
> So, the decision of removing entry barriers for native nmethods would make the memory leak I'm trying to fix here effectively unfixable? Let me know if I'm missing something.

If we mark them as not-entrant, then the is_not_entrant() check below will still catch them, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2449951151

From david.holmes at oracle.com  Wed Oct 22 01:25:06 2025
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Oct 2025 11:25:06 +1000
Subject: =?UTF-8?Q?Re=3A_8357865=3A_Null_MethodHandle=2EinvokeExact_crashes_?=
 =?UTF-8?B?SkRLIDjigJMxOC4y?=
In-Reply-To: <19a06ef1ccc.75d7e1243239295.2898833841422701414@peya.tokyo>
References: <19a06ef1ccc.75d7e1243239295.2898833841422701414@peya.tokyo>
Message-ID: <2e8f5332-984a-48ab-a823-a2e64429ce7d@oracle.com>

Hi,

Thanks for the information. I've added your report to the JBS issue.

Cheers,
David

On 21/10/2025 11:22 pm, Daisuke Yamazaki wrote:
> Hello HotSpot developers,
> 
> This is my first time contributing to OpenJDK.
> 
> I have confirmed that JDK-8357865 also occurs on the following version on
> native Windows 11 x64 (not WSL):
>    OpenJDK 9.0.4, 10.0.2, 11.0.2, 12.0.2, 13.0.2, 14.0.2, 15.0.2, 16.0.2,
>    17.0.2, 18.0.2.
> 
> The crash happens even with -Xint (interpreter mode),
> which suggests that this is a HotSpot native runtime issue, not limited to JIT.
> 
> Partial hs_err log:
>      A fatal error has been detected by the Java Runtime Environment:
>        EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdab1b10d0, pid=27592, tid=67948
>      JRE version: OpenJDK Runtime Environment (18.0.2+9) (build 18.0.2+9-61)
>      Java VM: OpenJDK 64-Bit Server VM (18.0.2+9-61, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
>      Problematic frame:
>      V  [jvm.dll+0x110d0]
> 
> Full hs_err_pid log is saved locally and can be shared if needed.
> 
> It seems that the issue is fixed sometime after JDK 19:
>    openjdk version "19.0.1" 2022-10-18
> 
> It seems that the issue is fixed sometime after JDK 18, as it does not occur on JDK 19.
> 
> Thanks for your attention and guidance.
> 
> Best regards,
> D. Yamazaki


From dzhang at openjdk.org  Wed Oct 22 01:41:21 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 22 Oct 2025 01:41:21 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v7]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <1Z7iEJgvZNbrAvVASOBJMIY4-oHloGVrYXBYcaBTm1Q=.165aa03a-9d46-4c4a-9318-3f3110ed91b1@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Replace NULL with nullptr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/33eba42f..344e3c66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=05-06

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From dzhang at openjdk.org  Wed Oct 22 02:13:38 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 22 Oct 2025 02:13:38 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v8]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <aGVmOIFYFufPc0JW7HDbjZaAVXwKVX0g_mequ8Rxigc=.0fac7171-21f4-46d6-8cca-c4f3873aea4b@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Add missing headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/344e3c66..928c3df4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=06-07

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From liach at openjdk.org  Wed Oct 22 02:24:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Oct 2025 02:24:10 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <-czbEuOCg7MyDiAr7PJ94Wrp-ycdaRFGBWOC-Z6rAK4=.e1bf40b6-d5e7-4505-959b-c32d22513532@github.com>

On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>> 
>> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

Keep alive; is this not a good minimal unit for hotspot reviewers to review? I intentionally avoided including changes to Objects.requireNonNull directly to minimize hotspot review efforts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3430251443

From fyang at openjdk.org  Wed Oct 22 02:27:04 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 22 Oct 2025 02:27:04 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <v22mWTx1vX9v8RTWAVc2X6hNmDQqgqtgyTiNNRv4gmA=.fc4899fd-52a1-4c84-b127-7271ea8e70ed@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <b7HOAPNfezUdGKpVFIf9NUu2AjiA0ILCVP0IzbOFqnM=.c47725e6-f84b-4932-a779-96954666992d@github.com>
 <f83An8LDCCHH0mUT3L42RCeaYtR9jtq63k04kBApNcY=.1638d04c-2f60-4cf8-9247-ed75421fed3d@github.com>
 <v22mWTx1vX9v8RTWAVc2X6hNmDQqgqtgyTiNNRv4gmA=.fc4899fd-52a1-4c84-b127-7271ea8e70ed@github.com>
Message-ID: <JuNQqrU_lZCxt6D9WwbtKHYemVkKDi8wYAgZO_UDbhc=.94fcc430-f923-42f1-876d-8afeb26e6666@github.com>

On Tue, 21 Oct 2025 13:30:57 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> > > Mind you that the following tests explicitly are testing `-XX:-AlignVector` and won't work on hardware platforms without misaligned vector. But it doesn't seem to me reasonable to add a requirement like `@requires vm.opt.EnableVectorSupport == true` for them as they are superword tests. These tests were once enabled for RISC-V by: https://bugs.openjdk.org/browse/JDK-8352529. Maybe we should simply keep them disabled for this platform?
> > 
> > 
> > Simply distable them on riscv seems not a good idea. Maybe add `@requires (os.arch != "riscv64" | !vm.opt.AlignVector))`?
> 
> These tests all report IR-related errors because the first commit did not handle `AlignVector`, only modifying `EnableVectorSupport`. This prevented the corresponding nodes from being printed. After implementing AlignVector handling, cases that fail to satisfy constraints are now skipped and no longer generate errors.

OK, that seems to work. I re-run these tests with your latest change and I see they are passing now. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3430256233

From dholmes at openjdk.org  Wed Oct 22 02:27:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:27:05 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
Message-ID: <qo8FLK2SjNcowCt306WP2ZQnbqVojhw8v7_K2klo7P4=.9a066cfb-9ced-4710-be8f-22280ee30cfc@github.com>

On Tue, 21 Oct 2025 13:57:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
>> Tested with the test 100x.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste errors.

That looks fine. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27907#pullrequestreview-3363476240

From asmehra at openjdk.org  Wed Oct 22 02:30:30 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 02:30:30 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during preimage
 generation in the training run
Message-ID: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>

This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

-------------

Commit messages:
 - 8370377: Avoid resolving constant pool entries during preimage generation in the training run

Changes: https://git.openjdk.org/jdk/pull/27927/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27927&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370377
  Stats: 114 lines in 4 files changed: 53 ins; 12 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27927.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27927/head:pull/27927

PR: https://git.openjdk.org/jdk/pull/27927

From asmehra at openjdk.org  Wed Oct 22 02:34:07 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 02:34:07 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
Message-ID: <z-wRaUKREk1AbEMuuAF0V2wuDe9RHIlp9UXRnvXkMR4=.e9ddbbcd-732c-49fa-ba42-5a02e78efb47@github.com>

On Wed, 22 Oct 2025 02:23:32 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

@iklam - fyi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27927#issuecomment-3430266229

From dzhang at openjdk.org  Wed Oct 22 02:34:14 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 22 Oct 2025 02:34:14 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v3]
In-Reply-To: <R6_qkijz8Qac6kUZpez9FRYLh8f2N-UsPHfokzyu70g=.70b5ee38-1261-4604-90ab-9a4601e6c798@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <MksIgv3yvA3rHSkxgFW0PejAADgmwe1WaCjK6qZjZFU=.d970a050-ccf2-4109-a9d6-a7e36b01566c@github.com>
 <6yqFOMZnkRjdwq3kdtieWXIpATCbDozJF_EHeUF_zDw=.fd63620d-5264-4b1a-86a4-3ae812e5e303@github.com>
 <R6_qkijz8Qac6kUZpez9FRYLh8f2N-UsPHfokzyu70g=.70b5ee38-1261-4604-90ab-9a4601e6c798@github.com>
Message-ID: <gdHj7-CyGaMmCxKLsgTefQt-TtxSkBZzg7gU5YP_QU0=.d482b120-2329-4873-9e7c-46a3af0c7c9e@github.com>

On Fri, 10 Oct 2025 01:47:15 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 202:
>> 
>>> 200:   constexpr static bool supports_secondary_supers_table() { return true; }
>>> 201: 
>>> 202:   constexpr static bool supports_misaligned_vector_accesses() { return true; }
>> 
>> Does this `supports_misaligned_vector_accesses` equal to `AlignVector` option?
>
> For RISC-V, `supports_misaligned_vector_accesses` is only determined by hwprode, while `AlignVector` can also be modified by the user on platforms that support misaligned vector accesses.

The latest value for `supports_misaligned_vector_accesses` is the inverse of `AlignVector`. The determination logic is already reflected in `vm_version_riscv.cpp`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2450244586

From dholmes at openjdk.org  Wed Oct 22 02:42:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:42:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <M-Q5y1kspwQl2U7mjsr6tRwi91F54r_owZgXWzXfFQc=.42fb1143-69c0-490a-9082-dc72e6ccea2f@github.com>

On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>> 
>> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

As I said earlier the hotspot changes seem reasonable. I find the enum usage a bit clunky but that is just me.

I will approve for hotspot side - though as hotspot requires two reviews you should wait for a second hotspot review. Thanks.

test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullCheckAPITest.java line 65:

> 63:     }
> 64: 
> 65:     static void throwNpe() {

Nit: `throwNPE`

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3363495671
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2450252079

From dholmes at openjdk.org  Wed Oct 22 02:55:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:55:01 GMT
Subject: RFR: 8365896: Remove unnecessary explicit buffer nul-termination
 after using os::snprintf
In-Reply-To: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>
References: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>
Message-ID: <v9Tbe4vIJvgWOTo_EC-0AjDsjizdSEm5LZA_iAtAH9U=.5bd42eaa-1570-4b1e-8324-993aa682278c@github.com>

On Tue, 21 Oct 2025 16:05:31 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR removes some leftover null terminators and buffer reservations for null terminators, which have been made redundant with the new `snprintf` family of functions. 
> 
> In order to find these occurrences, I methodologically used multiple regular expressions over the entire codebase. I took a look at around 130 files in total, and updated where appropriate. 
> 
> I?ve tested this through tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64) and Windows (x64). I?ve also successfully compiled for PowerPC and Zero on Linux.

They all seem fine to me. Thanks for doing this cleanup.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27920#pullrequestreview-3363518323

From lmesnik at openjdk.org  Wed Oct 22 03:46:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 03:46:01 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
Message-ID: <rlYp9o2jF1Fydmm0MgxQB7jkHIvaSml1GtEMxfAsxIM=.2b7d3d5f-2be2-41cd-a5b8-303aa349366d@github.com>

On Tue, 21 Oct 2025 13:57:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
>> Tested with the test 100x.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste errors.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27907#pullrequestreview-3363587697

From iklam at openjdk.org  Wed Oct 22 03:46:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Oct 2025 03:46:02 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
Message-ID: <f7x8kOE3SCvCZLn_kzDd3KRW61q4v8UId9EdNvvO7Mk=.7152f0fc-8520-4a4e-9496-0cfd5150e112@github.com>

On Tue, 21 Oct 2025 13:57:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
>> Tested with the test 100x.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste errors.

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27907#pullrequestreview-3363590851

From fyang at openjdk.org  Wed Oct 22 04:06:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 22 Oct 2025 04:06:05 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v8]
In-Reply-To: <aGVmOIFYFufPc0JW7HDbjZaAVXwKVX0g_mequ8Rxigc=.0fac7171-21f4-46d6-8cca-c4f3873aea4b@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <aGVmOIFYFufPc0JW7HDbjZaAVXwKVX0g_mequ8Rxigc=.0fac7171-21f4-46d6-8cca-c4f3873aea4b@github.com>
Message-ID: <-95x1F9Wq8G9mmgARQoHT4gEIq9CeJFUkZZdxrR6RmY=.89552196-3193-4c2a-bac8-3d16d2ec84c3@github.com>

On Wed, 22 Oct 2025 02:13:38 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch? Thanks!
>> 
>> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
>> 
>> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
>> 
>> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
>> 
>> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
>> 
>> We can check the status of EnableVectorSupport as follows:
>> 
>> On k1
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [0.737s][info][compilation] EnableVectorSupport=false
>> [0.738s][info][compilation] EnableVectorReboxing=false
>> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
>> 
>> On qemu
>> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
>> [3.048s][info][compilation] EnableVectorSupport=true
>> [3.050s][info][compilation] EnableVectorReboxing=true
>> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
>> 
>> 
>> ### Test (fastdebug)
>> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing headers

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 228:

> 226:   if (UseRVV) {
> 227:     if (!unaligned_vector.enabled() && AlignVector == false) {
> 228:       if (!VM_Version::detect_misaligned_vector_support()){

Suggestion:

    // The hwprobe syscall won't be able to detect support for misaligned vector accesses on old kernels.
    // Resort to detect_misaligned_vector_support() to see if misaligned vector accesses may trap or not.
    if (!unaligned_vector.enabled()) {
      if (AlignVector == false && !VM_Version::detect_misaligned_vector_support()) {

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 574:

> 572:     return true;
> 573:   }
> 574:   return false;

Suggestion: `return detect_misaligned_vector_stub() == 1;`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2450346243
PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2450343332

From dholmes at openjdk.org  Wed Oct 22 04:26:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 04:26:06 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <Ed3OiUsqL5vqiBjck-DxzJ5m8UR1PX3RwooeYxlMikM=.83412047-08c2-4833-9700-5424642ee975@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
 <u5JMUUFoMf_kPj4waUqh5z2BNB6TCuYNJpcqISpeMNI=.7630be6d-beb2-4216-8581-99baeb071dbb@github.com>
 <Ed3OiUsqL5vqiBjck-DxzJ5m8UR1PX3RwooeYxlMikM=.83412047-08c2-4833-9700-5424642ee975@github.com>
Message-ID: <_rPdgEavrQbAP-VbXUeXBMzJkcjHWgG05LR05PGO9lA=.3bb9988d-6f3c-4d08-a62e-12fd43b3d374@github.com>

On Tue, 21 Oct 2025 14:54:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/atomic.hpp line 84:
>> 
>>> 82: // Default construction of an atomic integer or atomic byte initializes the
>>> 83: // value to zero. Default construction of an atomic pointer initializes the
>>> 84: // value to null.
>> 
>> Suggestion:
>> 
>> // value to nullptr.
>> 
>> Optional, and total nit-pick. Reason: we are in C++ and not Java.
>
> We generally use "null" in comments, unless it's part of a code snippet.

Yes the convention is that we can talk generally about the concept of null-ness and of a value being null, and only use `nullptr` when referring to actual code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2450390239

From dzhang at openjdk.org  Wed Oct 22 04:42:23 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 22 Oct 2025 04:42:23 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v9]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <6eUtpl3aVn2MWEuQtD-x7mPKtOJyGJEGKHUZsOm-TKs=.bc4cd469-2629-4fde-bd1a-60ca2ccfb3e4@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Adjust format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/928c3df4..e1d857c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=07-08

  Stats: 12 lines in 1 file changed: 2 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From dzhang at openjdk.org  Wed Oct 22 04:42:25 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 22 Oct 2025 04:42:25 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v8]
In-Reply-To: <-95x1F9Wq8G9mmgARQoHT4gEIq9CeJFUkZZdxrR6RmY=.89552196-3193-4c2a-bac8-3d16d2ec84c3@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
 <aGVmOIFYFufPc0JW7HDbjZaAVXwKVX0g_mequ8Rxigc=.0fac7171-21f4-46d6-8cca-c4f3873aea4b@github.com>
 <-95x1F9Wq8G9mmgARQoHT4gEIq9CeJFUkZZdxrR6RmY=.89552196-3193-4c2a-bac8-3d16d2ec84c3@github.com>
Message-ID: <_nzpuQzOcGJcEDFI_vblGUSbJnp1AyLG6YNcecWI7N4=.443dcccc-759d-4370-a622-455bc8d6b5e7@github.com>

On Wed, 22 Oct 2025 03:47:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing headers
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 228:
> 
>> 226:   if (UseRVV) {
>> 227:     if (!unaligned_vector.enabled() && AlignVector == false) {
>> 228:       if (!VM_Version::detect_misaligned_vector_support()){
> 
> Suggestion:
> 
>     // The hwprobe syscall won't be able to detect support for misaligned vector accesses on old kernels.
>     // Resort to detect_misaligned_vector_support() to see if misaligned vector accesses may trap or not.
>     if (!unaligned_vector.enabled()) {
>       if (AlignVector == false && !VM_Version::detect_misaligned_vector_support()) {

Fixed.

> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 574:
> 
>> 572:     return true;
>> 573:   }
>> 574:   return false;
> 
> Suggestion: `return detect_misaligned_vector_stub() == 1;`

Thanks! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2450411901
PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2450411248

From dholmes at openjdk.org  Wed Oct 22 05:15:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 05:15:03 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
 <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
 <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>
Message-ID: <gJK08Exq-7GPbQObgBJbZakGF7dBPLxVKLwIoZ_zDes=.001f4968-a30d-4fd5-9d25-ce544bd7a540@github.com>

On Tue, 21 Oct 2025 13:40:52 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?

@fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.

> CPU quotas when running in a container.

Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.

> The "machine" numbers when running in a container (which get overridden by container numbers).

Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 

Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3430526062

From epeter at openjdk.org  Wed Oct 22 05:48:03 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Oct 2025 05:48:03 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v4]
In-Reply-To: <_rPdgEavrQbAP-VbXUeXBMzJkcjHWgG05LR05PGO9lA=.3bb9988d-6f3c-4d08-a62e-12fd43b3d374@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <iAV0Wh_fsKgHWkxENNLZjSzWhfMG0IgiBjvZ5Qwf1GE=.f56de381-1d43-4fd7-bfb1-116a536337ea@github.com>
 <u5JMUUFoMf_kPj4waUqh5z2BNB6TCuYNJpcqISpeMNI=.7630be6d-beb2-4216-8581-99baeb071dbb@github.com>
 <Ed3OiUsqL5vqiBjck-DxzJ5m8UR1PX3RwooeYxlMikM=.83412047-08c2-4833-9700-5424642ee975@github.com>
 <_rPdgEavrQbAP-VbXUeXBMzJkcjHWgG05LR05PGO9lA=.3bb9988d-6f3c-4d08-a62e-12fd43b3d374@github.com>
Message-ID: <emiRRbnLEcIGvfETBN-6fcQQa9EieVP_dIEd1AlRVQM=.b26951b6-fbc5-41b1-869d-edd0c888f62e@github.com>

On Wed, 22 Oct 2025 04:22:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We generally use "null" in comments, unless it's part of a code snippet.
>
> Yes the convention is that we can talk generally about the concept of null-ness and of a value being null, and only use `nullptr` when referring to actual code.

Ok, sounds good. Will keep that in mind ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2450500217

From syan at openjdk.org  Wed Oct 22 05:58:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 22 Oct 2025 05:58:01 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
Message-ID: <Axdu5sjbrYJfF_4Aw3zGEs_BFfqShYyLNmPGgX2KqlQ=.e95e1dd7-4c67-4fe5-a089-5c2107600411@github.com>

On Tue, 21 Oct 2025 13:57:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
>> Tested with the test 100x.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste errors.

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27907#pullrequestreview-3363808936

From dholmes at openjdk.org  Wed Oct 22 06:11:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 06:11:05 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>
Message-ID: <sw8sGdGhk15nI659oQfosmj4UpsfFAnHJ60Ya7KL1Us=.6174a78b-a5fd-4202-bca5-56f0b2c07cdc@github.com>

On Mon, 20 Oct 2025 19:07:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/oops/klass.hpp line 583:
>> 
>>> 581:   // initializes the klass
>>> 582:   virtual void initialize(TRAPS);
>>> 583:   virtual void initialize_preemptable(TRAPS);
>> 
>> Can we not define these on `instanceKlass` instead of `klass`? Seems really odd to declare virtual methods for which the base class version should never be called (they should be pure virtuals in that case I would think?).
>
> Ok. Just to double check, casting to `InstanceKlass*` where we call `initialize_preemptable` for the `invokestatic` and `getstatic/putstatic` cases should be always safe right? I don?t see how we could get there for an `ArrayKlass`.

Hmmm seems there is an `objArrayKlass::initialize` (and an empty `typeArrayKlass::initialize`) but I don't know when such classes would be initialized. I would not expect them to be the target of invokestatic/getstatic/putstatic, nor for "new" but a "new array" would have to do the initialization of the bottom class (at least that is what `objArrayKlass::initialize` does) - and I don't think the current changes address that case. ??

Anyway leave the placement as-is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2450537248

From dholmes at openjdk.org  Wed Oct 22 06:26:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 06:26:03 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <4RnCaK-UiAcxujqvgB6zbTe70SMXBkJDJieP9U0tzg4=.3fbda558-c9b3-4d5a-a0e0-e009005d9a50@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <4RnCaK-UiAcxujqvgB6zbTe70SMXBkJDJieP9U0tzg4=.3fbda558-c9b3-4d5a-a0e0-e009005d9a50@github.com>
Message-ID: <6OgwhFiJQKmo3c-NsbctFTk7kbYSI1_wNYZRZisq-tU=.e26dcbc5-3334-4d43-8525-dca8b204ff8e@github.com>

On Mon, 20 Oct 2025 19:19:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 315:
>> 
>>> 313: }
>>> 314: 
>>> 315: // Keep object protected during ObjectLocker preemption.
>> 
>> I don't understand why this is necessary.
>
> Once the thread initializing the class finishes the initialization and calls `InstanceKlass::fence_and_clear_init_lock()`, the init_lock oop can be GC?ed, unless there is some other `Handle` protecting it (`ObjectMonitor::_object` is only a `WeakHandle`). But we could still have preempted virtual threads using the ObjectMonitor, so we need to protect the oop. In practice, I don?t see paths in `ObjectMonitor::resume_operation` where we try to get the oop out of the monitor, but I?m not sure if we want to break the invariant where the object needs to be alive while using its ObjectMonitor.

I see - platforms threads have a Handle to the oop whilst they wait, but vthreads have left that code, so we need the OM to maintain the strong reference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2450563031

From dholmes at openjdk.org  Wed Oct 22 06:32:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 06:32:08 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <4RnCaK-UiAcxujqvgB6zbTe70SMXBkJDJieP9U0tzg4=.3fbda558-c9b3-4d5a-a0e0-e009005d9a50@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <4RnCaK-UiAcxujqvgB6zbTe70SMXBkJDJieP9U0tzg4=.3fbda558-c9b3-4d5a-a0e0-e009005d9a50@github.com>
Message-ID: <bHfqWGuEXrUzGhZE0y2ytYbBjQ8CfvW1pKXqpmloJ4E=.c885fb6a-7fef-4c46-aa6a-17c8d9af09b4@github.com>

On Mon, 20 Oct 2025 19:20:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/interpreter/linkResolver.cpp line 1122:
>> 
>>> 1120:       resolved_klass->initialize(CHECK);
>>> 1121:     } else if (static_mode == StaticMode::initialize_klass_preemptable) {
>>> 1122:       resolved_klass->initialize_preemptable(CHECK);
>> 
>> Why is this not CHECK_AND_CLEAR_PREEMPTED?
>
> We need to let the exception propagate all the way back to the VM entry point, and only then we can clear it.

Right - sorry - I though this was the entry point, but it is up in IRT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2450573813

From epeter at openjdk.org  Wed Oct 22 06:33:54 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Oct 2025 06:33:54 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v9]
In-Reply-To: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
Message-ID: <ZINqzQJzYBbODilu77HjqtJjvlYLamRhSY_CKLXxrSg=.c2e16332-fb7d-4639-978b-635ba3dd23c8@github.com>

> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
> 
> Here, I'm doing the following:
> - Add more documentation, and improve it in other cases.
> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
> - Made some methods private, and added some additional asserts.
> 
> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
> 
> Related issues:
> https://github.com/openjdk/jdk/pull/27889
> https://github.com/openjdk/jdk/pull/15720

Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8370220-get-ctrl-documentation' of https://github.com/eme64/jdk into JDK-8370220-get-ctrl-documentation
 - fix shenandoah replace for phis

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27892/files
  - new: https://git.openjdk.org/jdk/pull/27892/files/ac057395..44e808bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27892&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27892/head:pull/27892

PR: https://git.openjdk.org/jdk/pull/27892

From aboldtch at openjdk.org  Wed Oct 22 06:42:06 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 22 Oct 2025 06:42:06 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
Message-ID: <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>

On Tue, 21 Oct 2025 14:58:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds the type Atomic<T>, to use as the type
>> of a variable that is accessed (including writes) concurrently by multiple
>> threads. This is intended to replace (most) uses of the current HotSpot idiom
>> of declaring a variable volatile and accessing that variable using functions
>> from the AtomicAccess class.
>> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147
>> 
>> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are
>> 
>> * Substantially restructured `Atomic<T>`, to be IDE friendly. It's
>> operationally the same, with the same API, hence uses and gtests didn't need
>> to change in that respect. Thanks to @stefank for raising this issue, and for
>> some suggestions toward improvements.
>> 
>> * Changed how fetch_then_set for atomic translated types is handled, to avoid
>> having the function there at all if it isn't usable, rather than just removing
>> it via SFINAE, leaving an empty overload set.
>> 
>> * Added more gtests.
>> 
>> Testing: mach5 tier1-6, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename relaxed_store => store_relaxed

I played around with this a bit. I think the implementation and API looks good, but have a couple of questions and I found one issue with certain types which unexpectedly do not compile.

So in the following code snippet neither `Atomic<EnumClass16>` nor `Atomic<uint16_t>` can be compiled. 

```C++
enum class EnumClass8 : uint8_t {};
enum class EnumClass16 : uint16_t {};
enum class EnumClass32 : uint32_t {};

enum class SpecialEnumClass8 : uint8_t {};
enum class SpecialEnumClass16 : uint16_t {};
enum class SpecialEnumClass32 : uint32_t {};

template<> struct PrimitiveConversions::Translate<SpecialEnumClass8> : public std::true_type {
  using Value = SpecialEnumClass8;
  using Decayed = uint32_t;

  static Decayed decay(Value x) { return (Decayed)(uint16_t)x; }
  static Value recover(Decayed x) { return Value(x); }
};

template<> struct PrimitiveConversions::Translate<SpecialEnumClass16> : public std::true_type {
  using Value = SpecialEnumClass16;
  using Decayed = uint32_t;

  static Decayed decay(Value x) { return (Decayed)(uint16_t)x; }
  static Value recover(Decayed x) { return Value(x); }
};

template<> struct PrimitiveConversions::Translate<SpecialEnumClass32> : public std::true_type {
  using Value = SpecialEnumClass32;
  using Decayed = uint32_t;

  static Decayed decay(Value x) { return (Decayed)(uint16_t)x; }
  static Value recover(Decayed x) { return Value(x); }
};

TEST_VM(AtomicValueAccessTest, type_test) {
  // Commented lines do no compile

  Atomic<EnumClass8> aec8;
  // Atomic<EnumClass16> aec16; // Unexpected
  Atomic<EnumClass32> aec32;

  // aec8.fetch_then_set(EnumClass8{}); // Expected
  // aec16.fetch_then_set(EnumClass16{}); // Expected
  aec32.fetch_then_set(EnumClass32{});

  aec8.cmpxchg(EnumClass8{}, EnumClass8{});
  // aec16.cmpxchg(EnumClass16{}, EnumClass16{});
  aec32.cmpxchg(EnumClass32{}, EnumClass32{});

  Atomic<uint8_t> a8;
  // Atomic<uint16_t> a16;  // Unexpected
  Atomic<uint32_t> a32;

  // a8.fetch_then_set(uint8_t{}); // Expected
  // a16.fetch_then_set(uint16_t{}); // Expected
  a32.fetch_then_set(uint32_t{});

  a8.cmpxchg(uint8_t{}, uint8_t{});
  // a16.cmpxchg(uint16_t{}, uint16_t{});
  a32.cmpxchg(uint32_t{}, uint32_t{});

  Atomic<SpecialEnumClass8> asec8;
  Atomic<SpecialEnumClass16> asec16;
  Atomic<SpecialEnumClass32> asec32;

  asec8.fetch_then_set(SpecialEnumClass8{});
  asec16.fetch_then_set(SpecialEnumClass16{});
  asec32.fetch_then_set(SpecialEnumClass32{});

  asec8.cmpxchg(SpecialEnumClass8{}, SpecialEnumClass8{});
  asec16.cmpxchg(SpecialEnumClass16{}, SpecialEnumClass16{});
  asec32.cmpxchg(SpecialEnumClass32{}, SpecialEnumClass32{});
}

src/hotspot/share/runtime/atomic.hpp line 299:

> 297:                    atomic_memory_order order = memory_order_conservative) {
> 298:     return AtomicAccess::xchg(this->value_ptr(), new_value);
> 299:   }

I am not sure I understood the motivation behind the changing of the `xchg` name, nor why `cmpxchg` did not get a similar treatment. Could you provide some elaboration here?

Is there any plan to change the naming in the AtomicAccess layer as well?

test/hotspot/gtest/runtime/test_atomic.cpp line 604:

> 602: // Verify that explicit instantiation doesn't attempt to reference the
> 603: // non-existent fetch_then_set of the atomic decayed type.
> 604: template class AtomicImpl::Atomic<TranslatedAtomicByteObject>;

Preexisting: 
Why do we not suport exchange on 8 and 16 byte sized types? 

Especially given that we have `AtomicAccess::XchgUsingCmpxchg` and do support `cmpxchg`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27539#pullrequestreview-3363818171
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2450522649
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2450586436

From eosterlund at openjdk.org  Wed Oct 22 06:46:03 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 22 Oct 2025 06:46:03 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <gJK08Exq-7GPbQObgBJbZakGF7dBPLxVKLwIoZ_zDes=.001f4968-a30d-4fd5-9d25-ce544bd7a540@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
 <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
 <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>
 <gJK08Exq-7GPbQObgBJbZakGF7dBPLxVKLwIoZ_zDes=.001f4968-a30d-4fd5-9d25-ce544bd7a540@github.com>
Message-ID: <BrW3i4TlbIULQS5xJeJ7KMoBOQC6h8PPnXlHsWCmF28=.d3ad90ff-c1dd-40e8-803b-ee46f0884c46@github.com>

On Wed, 22 Oct 2025 05:12:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> >  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?
> 
> 
> 
> @fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.
> 

Okay. Let's start with the problem domain then.

> 
> > CPU quotas when running in a container.
> 
> 
> 
> Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.
> 

While that is true, I was hoping for an API that isn't just the exact Linux implementation that screams of Linux for no good reason. What I mean by that is that having the available processors as a double seems general enough that potentially other OS containers could use it, whether or not they implemented CPU throttling in the same way. Having an explicit fraction instead does not help me much as a user.

> 
> > The "machine" numbers when running in a container (which get overridden by container numbers).
> 
> 
> 
> Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 
> 

What I specifically care about is how many cores the JVM is allowed to be scheduled to run on. These cores are shared across containers and utilizing them has a shared latency impact.

The container layer might throttle how often you are allowed to run on said processors and for how long. But neither cgroup CPU limit constrains how many processors the JVM is allowed to run on. It might run on all of them for a very short period of time.

> 
> Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?

So the reason this matters to me is that GC latency with a concurrent GC is all about CPU utilization. As CPU utilization grows, response times grow too across all percentiles.

So when in a position to pick how to pay for GC in terms of memory vs CPU, I want to increasingly bias the cost more towards using memory when the shared cores the container is allowed to run on get saturated, despite the individual container using less CPU.

In other words, there are trade-offs between latency, CPU and memory. All of these are shared across containers. So keeping within the container limits is a good start, but the container resources are shared. Therefore, making decisions to better share resources and latency pain across containers is even better. The same sharing story goes for memory which is also a shared resource across containers.

I don't expect a lot of code to reason about these things, but it is important for writing good GC heuristics. I can grab the values by piercing through the OS abstractions with some horrible #if LINUX CGroups::foo type of code, but I was hoping we could admit that both the resource view from within and outside of the container are important enough to have a proper API.

I have seen other sprinklings of code piercing through the container limit, like JFR CPU load metrics. It felt like it would be nice if we had a proper API for this.

So that's the problem domain.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3430714497

From epeter at openjdk.org  Wed Oct 22 06:49:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Oct 2025 06:49:05 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v9]
In-Reply-To: <ZINqzQJzYBbODilu77HjqtJjvlYLamRhSY_CKLXxrSg=.c2e16332-fb7d-4639-978b-635ba3dd23c8@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <ZINqzQJzYBbODilu77HjqtJjvlYLamRhSY_CKLXxrSg=.c2e16332-fb7d-4639-978b-635ba3dd23c8@github.com>
Message-ID: <fYpI3AQyqYtN4un0RAfNanCOYzW0yh5gfY0wHtq_E3w=.088a66e0-848f-419e-a47b-5b511acd53bd@github.com>

On Wed, 22 Oct 2025 06:33:54 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> When working on https://github.com/openjdk/jdk/pull/27889, I was irritated by the lack of documentation and suboptimal naming.
>> 
>> Here, I'm doing the following:
>> - Add more documentation, and improve it in other cases.
>> - Rename "lazy" methods: "lazy" could indicate that we delay it somehow until later, but it is unclear what is delayed.
>>   - `lazy_replace` -> `replace_ctrl_node_and_forward_ctrl_and_idom`
>>   - `lazy_update` -> `install_lazy_ctrl_and_idom_forwarding`
>> - Made some methods private, and added some additional asserts.
>> 
>> I'd be more than happy for even better names, and suggestions how to improve the documentation further :)
>> 
>> Related issues:
>> https://github.com/openjdk/jdk/pull/27889
>> https://github.com/openjdk/jdk/pull/15720
>
> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370220-get-ctrl-documentation' of https://github.com/eme64/jdk into JDK-8370220-get-ctrl-documentation
>  - fix shenandoah replace for phis

src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 1780:

> 1778:             fix_memory_uses(u, n, n, c);
> 1779:           } else if (_phase->C->get_alias_index(u->adr_type()) == _alias) {
> 1780:             _phase->igvn().replace_node(u, n);

As far as I can see, the `lazy_replace` only did `igvn.replace_node` for non-ctrl nodes anyway. Since we are dealing with `PhiNode`s here, we might as well only use `igvn.replace_node`.

I discovered this, because it hit my `!old_node->is_CFG()` check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2450605644

From aboldtch at openjdk.org  Wed Oct 22 06:55:10 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 22 Oct 2025 06:55:10 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
Message-ID: <cEQjUolOt1oAoqDES9lhH6z7lYar9kdUr1fLsDxxzwE=.fb849e0d-ffde-47ed-a6aa-492f602e59a8@github.com>

On Wed, 22 Oct 2025 06:39:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> So in the following code snippet neither `Atomic<EnumClass16>` nor `Atomic<uint16_t>` can be compiled.

It seems like this is expected by the implementation (only allow Integer 32/64, or Byte 8).  But it is unexpected for me that `Atomic<T>` does not support these types while AtomicAccess does.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3430734730

From adinn at openjdk.org  Wed Oct 22 07:43:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 22 Oct 2025 07:43:37 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
Message-ID: <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>

On Wed, 22 Oct 2025 02:23:32 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

This looks good to me but I'll defer to Ioi's yea or nay.

src/hotspot/share/cds/finalImageRecipes.cpp line 130:

> 128: 
> 129:     if (cp_indices.length() > 0) {
> 130:       LogStreamHandle(Trace, aot, resolve) log;

This is very helpful information However, am I right in thinking this log output is going to be emitted during the training run?

It would really help if we could log details of which CP entries are resolved during an assembly run and/or a production run so we could associate linkage info, including any referenced metadata and/or heap roots, with the corresponding CP/CPCache/Klass. That would allow the map analysis to be extended to show how assets in the cache are connected to their owning Klass(es).

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27927#pullrequestreview-3364075088
PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2450721294

From epeter at openjdk.org  Wed Oct 22 07:59:33 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Oct 2025 07:59:33 GMT
Subject: RFR: 8370220: C2: rename methods and improve documentation around
 get_ctrl and idom lazy updating/forwarding of ctrl and idom via dead
 ctrl nodes [v9]
In-Reply-To: <fYpI3AQyqYtN4un0RAfNanCOYzW0yh5gfY0wHtq_E3w=.088a66e0-848f-419e-a47b-5b511acd53bd@github.com>
References: <BSPIvH5DWtNSmO9WFGelAsZm5CaILRHm1rtqwWKvo0k=.01472479-9752-49a9-b400-fcb389b11ff6@github.com>
 <ZINqzQJzYBbODilu77HjqtJjvlYLamRhSY_CKLXxrSg=.c2e16332-fb7d-4639-978b-635ba3dd23c8@github.com>
 <fYpI3AQyqYtN4un0RAfNanCOYzW0yh5gfY0wHtq_E3w=.088a66e0-848f-419e-a47b-5b511acd53bd@github.com>
Message-ID: <XR7FwjQnPQqH0SS9mWF7e_kZg77r9FmcO0M7HYrxz58=.8320b995-f379-430b-b450-407f4ce208ee@github.com>

On Wed, 22 Oct 2025 06:46:21 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370220-get-ctrl-documentation' of https://github.com/eme64/jdk into JDK-8370220-get-ctrl-documentation
>>  - fix shenandoah replace for phis
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 1780:
> 
>> 1778:             fix_memory_uses(u, n, n, c);
>> 1779:           } else if (_phase->C->get_alias_index(u->adr_type()) == _alias) {
>> 1780:             _phase->igvn().replace_node(u, n);
> 
> As far as I can see, the `lazy_replace` only did `igvn.replace_node` for non-ctrl nodes anyway. Since we are dealing with `PhiNode`s here, we might as well only use `igvn.replace_node`.
> 
> I discovered this, because it hit my `!old_node->is_CFG()` check.

@rwestrel Do you have an opinion on this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27892#discussion_r2450776790

From mli at openjdk.org  Wed Oct 22 08:15:25 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 22 Oct 2025 08:15:25 GMT
Subject: Integrated: 8370225: RISC-V: cleanup verify_xxx in
 interp_masm_riscv.hpp
In-Reply-To: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
References: <hCQrFftJiFwoyARalObAoZRtdJEVPEUSD13SzkiBu8U=.07141f19-78ed-4572-8a9c-f70d039111b5@github.com>
Message-ID: <GgwwmL8Y-TrhTy4xqmsHRl6cnjzuu7S4Gu99AzkukIc=.92d83132-66b9-4dc0-8324-7dff0f77c5d4@github.com>

On Mon, 20 Oct 2025 09:36:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this trivial patch?
> `verify_xxx` verify_xxx in interp_masm_riscv.hpp should be consistent.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 27c83c73
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27c83c730d8b0f87bb51230c35e4fe261c9d2723
Stats:     9 lines in 2 files changed: 0 ins; 7 del; 2 mod

8370225: RISC-V: cleanup verify_xxx in interp_masm_riscv.hpp

Reviewed-by: fyang

-------------

PR: https://git.openjdk.org/jdk/pull/27894

From fandreuzzi at openjdk.org  Wed Oct 22 08:41:15 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 08:41:15 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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 40 additional commits since the last revision:

 - rename
 - Merge branch 'master' into JDK-8359472
 - return value
 - cc
 - empty stderr
 - jvmti errors
 - indent
 - close
 - rephrase
 - PidJcmdExecutor. unused import. cc
 - ... and 30 more: https://git.openjdk.org/jdk/compare/4ae824a9...1dafec32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/ba3dc024..1dafec32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=15-16

  Stats: 28747 lines in 729 files changed: 16521 ins; 8454 del; 3772 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

PR: https://git.openjdk.org/jdk/pull/27766

From fandreuzzi at openjdk.org  Wed Oct 22 08:41:20 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 08:41:20 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
 <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>
Message-ID: <CEspiX_jVCIUKuPGfoVLKm_kikMQSIg3XykoTeXJ4fc=.4f11c250-4ebb-4163-b887-a75e95b4efdd@github.com>

On Tue, 21 Oct 2025 22:49:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cc
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 47:
> 
>> 45:  * @run junit TestEarlyDynamicLoad
>> 46:  */
>> 47: public class TestEarlyDynamicLoad {
> 
> Nit: It is convenient if the test folder name matches the test class name. There are several cases where this is broken in our testbase. But it is still a good idea to keep this invariant where possible.

Renamed in 1dafec32b57ac557b66dfe91c4bd2964019c9ff1

> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 54:
> 
>> 52:     fprintf(stderr, "JVMTI error occurred during SetEventNotificationMode\n");
>> 53:     return 1;
>> 54:   }
> 
> Nit: The returned values have to be JNI_ERR or JNI_OK.

Fixed in 205967939772764946e3df0e1633d6cec9e7d4a1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2450933247
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2450933709

From qpzhang at openjdk.org  Wed Oct 22 08:43:56 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Wed, 22 Oct 2025 08:43:56 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v4]
In-Reply-To: <AWBsjcYr3xUS5h2Tu_tu-3-qnp345tRxR4S_RVARYtA=.4d34e726-6753-47cd-92ef-00dd4bea87d9@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <ojYKlYh3GgnfdImR6oA93RRs-0uc0a7ukpb9fi5ZXsQ=.2ae7f457-9b3a-4768-babc-e1c92b532fab@github.com>
 <bxtYdFD36_D9PtwWyKKPkC2z7hxC4ArDiovwWOKaMhc=.8c858f44-2d75-40b8-b91c-bdda2ff85745@github.com>
 <AWBsjcYr3xUS5h2Tu_tu-3-qnp345tRxR4S_RVARYtA=.4d34e726-6753-47cd-92ef-00dd4bea87d9@github.com>
Message-ID: <HSGgYMh0eXTLkfvMKIYvASej2QLJ5hA70uVS5I-utc4=.2b296425-2eda-4bdc-9966-e19cee59f82f@github.com>

On Sun, 7 Sep 2025 01:49:09 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> I can't see any statistically-significant improvement. Please tell us your test results and your test conditions.

Hi @theRealAph , Do you have any further comments on the updates? Aside from the code changes to `BlockZeroingLowLimit`, the refinements to code-gen, added comments, and tests help improve code clarity and reduce potential technical debt, offering long-term value beyond an immediate performance gain to execution time.  Would appreciate your approval of this PR. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3431123897

From ayang at openjdk.org  Wed Oct 22 08:48:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 22 Oct 2025 08:48:28 GMT
Subject: RFR: 8370229: Remove unused method declarations after JDK-8322630
In-Reply-To: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
References: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
Message-ID: <GuHv9y9wQNL2dmOTokz1nBAoJl8TeQ-lqwowE6jx9cU=.8a406710-2d10-4141-ae38-0226eda63062@github.com>

On Tue, 21 Oct 2025 18:47:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Trivial removal of two methods declarations which are unused after JDK-8322630.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27923#pullrequestreview-3364371581

From jsikstro at openjdk.org  Wed Oct 22 09:03:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 22 Oct 2025 09:03:51 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
Message-ID: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>

Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.

The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.

For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.

A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs to consider. Averaging the accounting may mask allocation pressure on specific LGRPs and could result in the allocation history of TLABs being updated more/less frequently. In summary, considering the whole eden space (i.e., the entire MutableNUMASpace) instead of just a single LGRP when accounting for TLABs should give a more holistic view.

I plan to clean up the `Thread*` parameter to tlab_capacity, tlab_used and unsafe_max_tlab_alloc in a following RFE. Since it is a pretty significant cleanup

Testing:
* No performance impact on SPECjbb2015/SPECjbb2005 running with `-XX:+UseParallelGC -XX:+UseNUMA`
* hotspot:tier1-4 on a local NUMA machine

-------------

Commit messages:
 - 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace

Changes: https://git.openjdk.org/jdk/pull/27935/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370345
  Stats: 65 lines in 5 files changed: 17 ins; 26 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27935/head:pull/27935

PR: https://git.openjdk.org/jdk/pull/27935

From dholmes at openjdk.org  Wed Oct 22 09:14:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 09:14:44 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v2]
In-Reply-To: <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>
Message-ID: <zTwDuxXXTWGSPyCn6YrB0k7eLGzqOq-31z5GhMCQ-jg=.c6ff67bf-6fac-4a37-9eec-bac0ff47945b@github.com>

On Tue, 21 Oct 2025 15:18:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test

make/hotspot/lib/CompileJvm.gmk line 163:

> 161:   ifeq ($(SHIP_DEBUG_SYMBOLS), public)
> 162:     JVM_CFLAGS += -DHAS_STRIPPED_DEBUGINFO
> 163:   endif

But IIUC building the stripped pdb files doesn't necessarily mean you have deployed them in your image.

Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27899#discussion_r2451097941

From dholmes at openjdk.org  Wed Oct 22 09:21:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 09:21:41 GMT
Subject: RFR: 8370229: Remove unused method declarations after JDK-8322630
In-Reply-To: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
References: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
Message-ID: <TFpDQKBudACQp4bauRFhP3ntWf9l-R25uLapf9s5umw=.08d34a1f-f991-476b-a5bc-2b967bbe9f83@github.com>

On Tue, 21 Oct 2025 18:47:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Trivial removal of two methods declarations which are unused after JDK-8322630.

LGTM (and trivial)

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27923#pullrequestreview-3364568128

From fandreuzzi at openjdk.org  Wed Oct 22 09:21:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 09:21:43 GMT
Subject: RFR: 8370229: Remove unused method declarations after JDK-8322630
In-Reply-To: <GuHv9y9wQNL2dmOTokz1nBAoJl8TeQ-lqwowE6jx9cU=.8a406710-2d10-4141-ae38-0226eda63062@github.com>
References: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
 <GuHv9y9wQNL2dmOTokz1nBAoJl8TeQ-lqwowE6jx9cU=.8a406710-2d10-4141-ae38-0226eda63062@github.com>
Message-ID: <WU22yC4PcK1fkh3tusSzlHGHUnz3HKEWdKAk5J4EOuk=.6b9f2896-a3e3-430a-b164-de46cd0b2edc@github.com>

On Wed, 22 Oct 2025 08:45:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removal of two methods declarations which are unused after JDK-8322630.
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the review @albertnetymk and @dholmes-ora.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27923#issuecomment-3431284896

From duke at openjdk.org  Wed Oct 22 09:21:45 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Oct 2025 09:21:45 GMT
Subject: RFR: 8370229: Remove unused method declarations after JDK-8322630
In-Reply-To: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
References: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
Message-ID: <Ji1NC70KKlwUjBs1SavhsWzn8pF4NNGLVSdDPUgFvY0=.728c7667-6f01-47ce-a3b1-3725aad65dac@github.com>

On Tue, 21 Oct 2025 18:47:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Trivial removal of two methods declarations which are unused after JDK-8322630.

@fandreuz 
Your change (at version 79d9aaafa5c92e4725be5f1c1b64e98ddc116ecd) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27923#issuecomment-3431293504

From fandreuzzi at openjdk.org  Wed Oct 22 09:38:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 09:38:19 GMT
Subject: Integrated: 8370229: Remove unused method declarations after
 JDK-8322630
In-Reply-To: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
References: <sGuzyC2a4Pb-AOLfMPt7i67cEUSCHfCtCJ6q_tCQtXA=.ffc6c170-5aa4-46a9-a5de-8bd95dd55851@github.com>
Message-ID: <I0FuTGIZsWFbfG9N06TDj9uv_CmiYipE3jRq-3oi1-s=.aa4588ec-c048-4cb1-abfb-8aab0c8e820d@github.com>

On Tue, 21 Oct 2025 18:47:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Trivial removal of two methods declarations which are unused after JDK-8322630.

This pull request has now been integrated.

Changeset: b8d3c904
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8d3c9049c2b2557e51752c4ed90d7be54731b36
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8370229: Remove unused method declarations after JDK-8322630

Reviewed-by: ayang, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/27923

From aph at openjdk.org  Wed Oct 22 10:05:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Oct 2025 10:05:09 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
Message-ID: <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>

On Tue, 21 Oct 2025 13:56:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.

SafeFetch was designed specifically for problems like this one.


diff --git a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
index df5d97c2376..eff84ac195f 100644
--- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
+++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
@@ -29,7 +29,7 @@
 #include "asm/assembler.hpp"
 #include "runtime/icache.hpp"
 #include "runtime/os.hpp"
-#include "runtime/os.hpp"
+#include "runtime/safefetch.hpp"
 #if INCLUDE_JVMCI
 #include "jvmci/jvmciExceptions.hpp"
 #endif
@@ -528,7 +528,7 @@ inline NativeLdSt* NativeLdSt_at(address addr) {
 class NativePostCallNop: public NativeInstruction {
 public:
   bool check() const {
-    uint64_t insns = *(uint64_t*)addr_at(0);
+    uint64_t insns = SafeFetchN((intptr_t*)addr_at(0), 0);
     // Check for two instructions: nop; movk zr, xx
     // These instructions only ever appear together in a post-call
     // NOP, so it's unnecessary to check that the third instruction is

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3431497753

From dholmes at openjdk.org  Wed Oct 22 10:32:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 10:32:37 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <BrW3i4TlbIULQS5xJeJ7KMoBOQC6h8PPnXlHsWCmF28=.d3ad90ff-c1dd-40e8-803b-ee46f0884c46@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
 <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
 <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>
 <gJK08Exq-7GPbQObgBJbZakGF7dBPLxVKLwIoZ_zDes=.001f4968-a30d-4fd5-9d25-ce544bd7a540@github.com>
 <BrW3i4TlbIULQS5xJeJ7KMoBOQC6h8PPnXlHsWCmF28=.d3ad90ff-c1dd-40e8-803b-ee46f0884c46@github.com>
Message-ID: <HuYi_4KG9eSKsimnnzBTroc7y0am7htRwffPAZTZAD0=.bf714f94-938c-4b19-a938-fad98c035093@github.com>

On Wed, 22 Oct 2025 06:43:33 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>>  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?
>> 
>> @fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.
>> 
>>> CPU quotas when running in a container.
>> 
>> Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.
>> 
>>> The "machine" numbers when running in a container (which get overridden by container numbers).
>> 
>> Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 
>> 
>> Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?
>
>> >  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?
>> 
>> 
>> 
>> @fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.
>> 
> 
> Okay. Let's start with the problem domain then.
> 
>> 
>> > CPU quotas when running in a container.
>> 
>> 
>> 
>> Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.
>> 
> 
> While that is true, I was hoping for an API that isn't just the exact Linux implementation that screams of Linux for no good reason. What I mean by that is that having the available processors as a double seems general enough that potentially other OS containers could use it, whether or not they implemented CPU throttling in the same way. Having an explicit fraction instead does not help me much as a user.
> 
>> 
>> > The "machine" numbers when running in a container (which get overridden by container numbers).
>> 
>> 
>> 
>> Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 
>> 
> 
> What I specifically care about is how many cores the JVM is allowed to be scheduled to run on. These cores are shared across containers and utilizing them has a shared latency impact.
> 
> The container layer might throttle how often you are allowed to run on said processors and for how long. But neither cgroup CPU limit constrains how many processors the JVM is allowed to run on. It might run on all of them for a very short period of time.
> 
>> 
>> Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?
> 
> So the reason this matters to me is that GC latency with a concurrent GC is all about CPU utilization. As CPU utilization grows, response times grow too across all percentiles.
> 
> So when in a position to pick how to pay for GC in terms of memory vs CPU, I want to increasingly bias the cost more towards using memory when the shared cores the container is allowed to run on get saturated, despite the individual container using less CPU.
> 
> In other words, there are trade-offs between latency, CPU and memory. All of these ar...

@fisk there seem to be some assumptions involved in how the container actually operates to achieve its configured limits. If your CPU quota is 50% you don't know whether you will get all cores for 50% of the time or 50% of the cores for all the time - unless your container environment tells you how it operates. My recollection was that you could limit both the number of CPUs and the quota of CPU time allocated. So this would very much be a CGroups API not a generic "container" API (but although we call it a Container API it has been totally shaped by CGroups anyway ...)

You then want to be able to ask the execution environment that executes the container what resources it has available for processes (like the container). This is where I am less convinced that a suitable API exists for you to query these values from a process inside the container environment. Calling this outer layer "machine" is not really accurate, but "os" is already taken and you can't change the semantics of the existing os:: API.

But again I think it a mistake to take the existing os:: API and and define Container and Machine versions of it, because that existing os:: API does not really map cleanly to what you want to ask. I would look at what you want to ask and define Machine and Container APIs that do that, without trying to tie it back to the existing os API (implementation can of course be shared underneath).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3431642216

From shade at openjdk.org  Wed Oct 22 11:16:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Oct 2025 11:16:42 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
Message-ID: <Nex6TqrMadaKDC4paS-S55uE-wQqy01Mo9NbYa0h1_k=.b252a623-f1c8-472d-985b-7838f842de79@github.com>

On Tue, 21 Oct 2025 16:31:48 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

This looks very promising. I think we need to tighten up the style before we can integrate. @chhagedorn, who I see wrote the significant if not the entire part of this might want to take a look as well.

src/hotspot/share/utilities/elfFile.cpp line 695:

> 693:   } else {
> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());
> 695:     DebugAranges debug_aranges(this);

This honestly looks like we want to pull `DebugAranges` up to be a permanent member of `DwarfFIle`, and put the cache there? This would also resolve fairly awkward passing `ArangeCache&` around, since `DebugAranges` itself would do most of the heavy-lifting, including managing its own (internal) cache. Is there anything in the way of doing so?

src/hotspot/share/utilities/elfFile.cpp line 744:

> 742:   assert(cache._count == 0, "need fresh cache");
> 743:   assert(!cache._initialized, "need fresh cache");
> 744:   assert(!cache._failed, "need fresh cache");

I think it makes sense to test the flags only.

Suggestion:

  assert(!cache._initialized && !cache._failed, "Do it once");

src/hotspot/share/utilities/elfFile.cpp line 806:

> 804:   return;
> 805: 
> 806: cleanup_and_fail:

Goto statements are against HS code style: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md. Consider pulling this cleanup code into `ArangesCache` helper method, and then call it like this:


 if (failing-condition) {
   cache.destroy();
   return;
 }

src/hotspot/share/utilities/elfFile.hpp line 549:

> 547:    private:
> 548:     static int compare_aranges_entries(const void* a, const void* b);
> 549:     void sort() {

Just inline it into the only use?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3365234528
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451728417
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451661420
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451688112
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451734051

From mbaesken at openjdk.org  Wed Oct 22 11:28:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 Oct 2025 11:28:05 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v2]
In-Reply-To: <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>
Message-ID: <ILHRjSFYSIJpMO2yJly3aMjzs0amesgHHBYrqTWOL5A=.4d13865e-1c98-4f5f-91db-73073102ad07@github.com>

On Tue, 21 Oct 2025 15:18:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows: add hasExternalSymbolsStripped to WhiteBox, use it in our test

> But IIUC building the stripped pdb files doesn't necessarily mean you have deployed them in your image.

True, but in the end you have the stripped pdbs in place so it is possible you test with those and the test fails (for a good reason).
It is better than ALWAYS switching off the source file name check on Windows .

> Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp?

Yes I could do this, if you prefer ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3431898876

From duke at openjdk.org  Wed Oct 22 11:28:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 11:28:34 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v5]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/8d83dd97..a188df0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From chagedorn at openjdk.org  Wed Oct 22 11:52:11 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 22 Oct 2025 11:52:11 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
Message-ID: <kEfiOlOm76_pzyA4H7WnGkfMED9MokXLMF7BCbbmGpI=.845b5f8e-2847-46d3-9f42-63a27ae0014e@github.com>

On Tue, 21 Oct 2025 16:31:48 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

This looks indeed very promising, thanks for working on improving the DWARF parsing speed! I always wanted to come back to the parser at some point to improve it by adding some caches but never found the time to do it. So, thanks a lot for addressing that :-)

I'm curious, how much speed-up did you get for some normal stack traces? You could, for example, try out [TestDwarf](https://github.com/chhagedorn/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java) which crashes the VM in some different ways and exercises the DWARF parser. No need to do some extensive benchmarking but would be interesting to see the effect of this patch on `TestDwarf`.

src/hotspot/share/utilities/elfFile.cpp line 694:

> 692:     found = _aranges_cache.find_compilation_unit_offset(offset_in_library, &compilation_unit_offset);
> 693:   } else {
> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());

Maybe add a comment here about when we need to fall back to a linear scan.

src/hotspot/share/utilities/elfFile.cpp line 720:

> 718: }
> 719: 
> 720: int DwarfFile::ArangesCache::compare_aranges_entries(const void* a, const void* b) {

Can you add a method comment here how the sorting is done?

src/hotspot/share/utilities/elfFile.hpp line 523:

> 521: 
> 522:   // Cache for .debug_aranges to enable binary search for address lookup
> 523:   struct ArangesCache {

I suggest to add some more details about why we have this cache and how it works. Could be here and/or at the appropriate methods.

src/hotspot/share/utilities/elfFile.hpp line 533:

> 531: 
> 532:     ArangesCache() : _entries(nullptr), _count(0), _capacity(0), _initialized(false), _failed(false) {}
> 533:     ArangesCache(ArangesCache&& other) : _entries(other._entries), _count(other._count), _capacity(other._capacity),

According to the style guide, move constructors/semantics is a feature we are undecided about and we should currently refrain from using them until a consensus is reached: [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#additional-undecided-features).

src/hotspot/share/utilities/elfFile.hpp line 956:

> 954:       return;
> 955:     }
> 956:     DebugAranges debug_aranges(const_cast<DwarfFile*>(this));

I don't think the `const_cast` is required since the constructor takes a non-const pointer.


Suggestion:

    DebugAranges debug_aranges(this);

-------------

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3365144647
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451772244
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451792883
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451780142
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451785943
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451769349

From chagedorn at openjdk.org  Wed Oct 22 11:52:14 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 22 Oct 2025 11:52:14 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <Nex6TqrMadaKDC4paS-S55uE-wQqy01Mo9NbYa0h1_k=.b252a623-f1c8-472d-985b-7838f842de79@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
 <Nex6TqrMadaKDC4paS-S55uE-wQqy01Mo9NbYa0h1_k=.b252a623-f1c8-472d-985b-7838f842de79@github.com>
Message-ID: <2IkRmoeJcGaNyBHHp-6EOyJ_4BKYcWvNJz2yMK5VNNY=.853df936-aa0c-463a-9ae8-dd760bd1213f@github.com>

On Wed, 22 Oct 2025 11:10:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kerem Kat 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 elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - 8334866: Cache debug_aranges for faster address lookups
>
> src/hotspot/share/utilities/elfFile.cpp line 695:
> 
>> 693:   } else {
>> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());
>> 695:     DebugAranges debug_aranges(this);
> 
> This honestly looks like we want to pull `DebugAranges` up to be a permanent member of `DwarfFIle`, and put the cache there? This would also resolve fairly awkward passing `ArangeCache&` around, since `DebugAranges` itself would do most of the heavy-lifting, including managing its own (internal) cache. Is there anything in the way of doing so?

I was about to ask the same. Since we have an easy caching mechanism and `.debug_aranges` does not change, we could hide the cache inside `DebugAranges`. Then from the `DwarfFile` point of view, it does not need to care about how the queries to `DebugAranges` are actually answered and we have a better separation of concerns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451765525

From adinn at openjdk.org  Wed Oct 22 12:03:14 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 22 Oct 2025 12:03:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
Message-ID: <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>

On Wed, 22 Oct 2025 10:01:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> SafeFetch was designed specifically for problems like this one.

It was. However, I do not believe we should be in a situation where we are checking a call branch that is the last instruction in a code buffer -- which means there is no need to incur the cost of a SafeFetch. In particular, the failure that happened here only arose because a `far_jump` was used instead of a `far_call`. If a `far_call` had been generated then the value in lr would have been the last word in the buffer rather than a word off the end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432012676

From coleenp at openjdk.org  Wed Oct 22 12:36:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Oct 2025 12:36:35 GMT
Subject: RFR: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace [v2]
In-Reply-To: <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
 <VDYnxpPB7JDgW2Mliccdr8Vrim1etMsBpWE-DukzmBE=.d78a1ee3-ca25-4ff2-9b9c-a82648c73c09@github.com>
Message-ID: <K5acwQVW0-g5VdyVwnOzxjDrZV9vy1h4BwP7hClNtIU=.0f2ed4f8-81af-458b-a098-172f623bc2a2@github.com>

On Tue, 21 Oct 2025 13:57:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
>> Tested with the test 100x.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste errors.

Thanks for all the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27907#issuecomment-3432136458

From coleenp at openjdk.org  Wed Oct 22 12:36:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Oct 2025 12:36:36 GMT
Subject: Integrated: 8361451: Test
 vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java
 fails with OutOfMemoryError: Metaspace
In-Reply-To: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
References: <z_Pk1Wgi3hod2FFt4KmSD0Cyl30cQz6HqFSx2SvUNeI=.7206a831-f092-48d5-9b8d-a268f70c5987@github.com>
Message-ID: <hns54incW1PJMSO1B5LkZu3qMNzdfL4R0PvXYoDIU8U=.642b835e-4d69-438a-ba5f-23f8b7a3a16d@github.com>

On Mon, 20 Oct 2025 20:53:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This adds a catch clause for InvocationTargetException that can happen for OOM while invoking MethodHandles code.  Thanks to @iklam for diagnosis and fix.
> Tested with the test 100x.

This pull request has now been integrated.

Changeset: 92e380c5
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92e380c59c2498b1bc94e26658b07b383deae59a
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8361451: Test vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java fails with OutOfMemoryError: Metaspace

Reviewed-by: dholmes, lmesnik, iklam, syan

-------------

PR: https://git.openjdk.org/jdk/pull/27907

From kbarrett at openjdk.org  Wed Oct 22 13:07:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 22 Oct 2025 13:07:15 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
Message-ID: <tuFtvO3dhIln9LORocYeYdRiPNqm2m9a-A2hr08twEo=.3d6707bf-f4e6-49fa-a4fb-ab471f8628e3@github.com>

On Tue, 21 Oct 2025 16:31:48 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

src/hotspot/share/utilities/elfFile.hpp line 551:

> 549:     void sort() {
> 550:       qsort(_entries, _count, sizeof(ArangesEntry), DwarfFile::ArangesCache::compare_aranges_entries);
> 551:     }

[drive-by comment] Use of qsort is questionable.  See https://bugs.openjdk.org/browse/JDK-8248137

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2452029592

From stefank at openjdk.org  Wed Oct 22 13:21:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Oct 2025 13:21:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <1kOiLxe1Tj1aHVgliTVBfNvnSuAUUton2j9YW2xlWeo=.1c6e3095-9b5f-49cc-b87a-a897f2a0949f@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

Fix for minimal:

diff --git a/src/hotspot/share/cds/heapShared.hpp b/src/hotspot/share/cds/heapShared.hpp
index 8fa00b8f47d..4cf3e53011e 100644
--- a/src/hotspot/share/cds/heapShared.hpp
+++ b/src/hotspot/share/cds/heapShared.hpp
@@ -576,9 +576,9 @@ class HeapShared: AllStatic {
   static void setup_test_class(const char* test_class_name) PRODUCT_RETURN;
 #endif // INCLUDE_CDS_JAVA_HEAP

+ public:
   static void finish_materialize_objects() NOT_CDS_JAVA_HEAP_RETURN;

- public:
   static void write_heap(ArchiveMappedHeapInfo* mapped_heap_info, ArchiveStreamedHeapInfo* streamed_heap_info) NOT_CDS_JAVA_HEAP_RETURN;
   static objArrayOop scratch_resolved_references(ConstantPool* src);
   static void add_scratch_resolved_references(ConstantPool* src, objArrayOop dest) NOT_CDS_JAVA_HEAP_RETURN;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3432332019

From stefank at openjdk.org  Wed Oct 22 13:44:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Oct 2025 13:44:57 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3432428816

From jsikstro at openjdk.org  Wed Oct 22 13:56:14 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 22 Oct 2025 13:56:14 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v2]
In-Reply-To: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
Message-ID: <uWb3hAk6qJfqXsUJC6v9Uzia5fcEEaKjFaYuogyY0RM=.3627cbd2-f2b1-48db-893b-4dc7b3c9fd38@github.com>

> Hello,
> 
> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
> 
> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
> 
> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
> 
> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  unsafe_max_tlab_alloc must be aligned to MinObjAlignmentInBytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27935/files
  - new: https://git.openjdk.org/jdk/pull/27935/files/703a7dcf..c8a2182f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27935&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27935&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27935/head:pull/27935

PR: https://git.openjdk.org/jdk/pull/27935

From mdoerr at openjdk.org  Wed Oct 22 14:15:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Oct 2025 14:15:22 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <kjOyL3ITlJABvb6bLszTY3neOZ_ar_pkPq36xsHMv-A=.a462171b-fd91-4e38-9d63-9d56f459f2ed@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Btw. the disassembled instructions above are coming from https://github.com/openjdk/jdk/pull/27530 which we currently use in our test environment. Reviews would help to get it integrated.

0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432573526

From kbarrett at openjdk.org  Wed Oct 22 14:17:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 22 Oct 2025 14:17:43 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
Message-ID: <v5soAnMeGVatvTNu9zQMoWiryB3zzU0j8KoaZpRvreQ=.50914cb4-6b06-4086-a5d6-67e578eb058a@github.com>

On Wed, 22 Oct 2025 06:39:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> I played around with this a bit. I think the implementation and API looks good, but have a couple of questions and I found one issue with certain types which unexpectedly do not compile.
> 
> So in the following code snippet neither `Atomic<EnumClass16>` nor `Atomic<uint16_t>` can be compiled.

16bit values are not supported because we've never implemented support for
them in the AtomicAccess layer. Presumably that's because nobody has had a
use-case for them. Or at least not one compelling enough to convince someone
to do the implementation work (across all platforms). This is discussed in the
"notes" toward the end of the big block comment at the head of atomic.hpp.

> src/hotspot/share/runtime/atomic.hpp line 299:
> 
>> 297:                    atomic_memory_order order = memory_order_conservative) {
>> 298:     return AtomicAccess::xchg(this->value_ptr(), new_value);
>> 299:   }
> 
> I am not sure I understood the motivation behind the changing of the `xchg` name, nor why `cmpxchg` did not get a similar treatment. Could you provide some elaboration here?
> 
> Is there any plan to change the naming in the AtomicAccess layer as well?

The name "xchg" is pretty generic (it could just as easily be used for a
non-atomic exchange in some other class). The explicit `Atomic::` (now
`AtomicAccess::`) qualifier made for easy disambiguation. Similarly for the
others, like "inc" and "dec", and not providing short forms for "add" and
"sub". (And remember that we mostly eschew operator overloading, though I
think not always to our benefit. If not for that, such other classes probably
would be doing that rather than named operations for arithmetic.) I think
"cmpxchg" is pretty well understood to be atomic; I think if one tried to use
that name for a non-atomic operation in some other class one might well get
some push-back.

Personally, I also find the short names are harder to spot in the middle of
other code, and I liked that `AtomicAccess::foo` (formerly `Atomic::foo` was
easy to spot.

I think updating AtomicAccess to be consistent with what we decide for
Atomic<T> should be done, but only after Atomic<T> has been fully adopted, so
we're only dealing the the remaining resudue. This has already been discussed
with regard to explicit "relaxed" load/store qualifiers.

> test/hotspot/gtest/runtime/test_atomic.cpp line 604:
> 
>> 602: // Verify that explicit instantiation doesn't attempt to reference the
>> 603: // non-existent fetch_then_set of the atomic decayed type.
>> 604: template class AtomicImpl::Atomic<TranslatedAtomicByteObject>;
> 
> Preexisting: 
> Why do we not suport exchange on 8 and 16 byte sized types? 
> 
> Especially given that we have `AtomicAccess::XchgUsingCmpxchg` and do support `cmpxchg`.

Again, what's the use-case, and someone needs to do the work. That's all.
Just a mere matter of programming...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3432577864
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2452239941
PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2452245123

From mbaesken at openjdk.org  Wed Oct 22 14:17:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 Oct 2025 14:17:43 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <8w70YHXPApfQ_Hp1DJAQsijiUU0AXkm6ZgziOn3zj0I=.71b5defe-02e5-4d2b-930f-8d7615aacf88@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <PBoEGxOPlNQQIrRAlOU431MpwxPVlELp6yO9w3NVaj4=.c29168ff-870f-4b3d-a6f5-bec0bab955c4@github.com>
 <8w70YHXPApfQ_Hp1DJAQsijiUU0AXkm6ZgziOn3zj0I=.71b5defe-02e5-4d2b-930f-8d7615aacf88@github.com>
Message-ID: <ANy6Q1n6Ikl1tQe0nk2GnwcOejxGiilzGucj4Rm11Qc=.719d437d-028c-4f69-9b47-160624a83456@github.com>

On Mon, 20 Oct 2025 21:08:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?
> 
> Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

Yeah, maybe something like

LINK_TIME_OPTIMIZATION := YES

that can be set by lib owners and passed as an optional parameter to  SetupJdkLibrary / SetupNativeCompilation or similar.
We just need the lto settings per toolchain in 'make/autoconf'  (probably the c/cxx/ld flags can be borrowed from Hotspot where the functionality was available for some time as a configurable 'JVMFeature') , and in case LINK_TIME_OPTIMIZATION was set for a lib, we have to add them in a proper way.
(On the other hand, we need some LIB owners testing and hopefully using it, otherwise the new functionality just rots in the m4-files)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3432544610

From fandreuzzi at openjdk.org  Wed Oct 22 14:17:44 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 14:17:44 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <4Cj8ndIna8Do2EfcPsFR85vpAsHGPKtwAvrgp2dTkxU=.e996f1ed-c3a7-45be-a723-190db1bbea73@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
 <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
 <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>
 <4Cj8ndIna8Do2EfcPsFR85vpAsHGPKtwAvrgp2dTkxU=.e996f1ed-c3a7-45be-a723-190db1bbea73@github.com>
Message-ID: <sLtuESmB1LD7LYYeqHk84OVupPdUKAzHm3iHgWW2YDY=.6349e1c3-34cd-4b42-9a75-0766040432aa@github.com>

On Tue, 21 Oct 2025 23:19:48 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Is it actually possible to remove entry barriers for _any_ garbage collectable nmethod? How can we know an nmethod is not used anymore, even when it is made not entrant? `is_cold()` bails out when an nmethod does not support entry barriers:
>> 
>> // On platforms that don't support nmethod entry barriers, we can't
>> // trust the temporal aspect of the gc epochs. So we can't detect
>> // cold nmethods on such platforms.
>> 
>> So, the decision of removing entry barriers for native nmethods would make the memory leak I'm trying to fix here effectively unfixable? Let me know if I'm missing something.
>
> If we mark them as not-entrant, then the is_not_entrant() check below will still catch them, right?

I see, I assumed an nmethod couldn't be marked as on-stack without entry barriers, but that doesn't seem to be the case.

But on second thought, do you agree with the fix I'm proposing in this PR? I think the following two work items could  be implemented and reviewed in two separate chunks:
- allow not-entrant nmethod to be collected during GC
- review and possibly remove entry barriers for native wrappers

Would you agree with this @dean-long ? I could create another ticket to handle the second part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2452257035

From asmehra at openjdk.org  Wed Oct 22 14:21:36 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 14:21:36 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
Message-ID: <i9DJOb2p-PQhkzh2cAiw0Ll6KOjPiaa__sxBX3ao7FI=.89212960-2357-4409-9ec3-fd623414d3e2@github.com>

On Wed, 22 Oct 2025 07:40:54 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> This looks good to me but I'll defer to Ioi's yea or nay.

@adinn thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27927#issuecomment-3432600498

From asmehra at openjdk.org  Wed Oct 22 14:26:05 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 14:26:05 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
Message-ID: <iHNL57XqnVSiR9oll49uIO5Go9Gk4074D8cgVNJ1DJA=.b8037dfb-4b85-4a77-b9f8-a4ba9356b974@github.com>

On Wed, 22 Oct 2025 07:39:19 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> src/hotspot/share/cds/finalImageRecipes.cpp line 130:
> 
>> 128: 
>> 129:     if (cp_indices.length() > 0) {
>> 130:       LogStreamHandle(Trace, aot, resolve) log;
> 
> This is very helpful information However, am I right in thinking this log output is going to be emitted during the training run?
> 
> It would really help if we could log details of which CP entries are resolved during an assembly run and/or a production run so we could associate linkage info, including any referenced metadata and/or heap roots, with the corresponding CP/CPCache/Klass. That would allow the map analysis to be extended to show how assets in the cache are connected to their owning Klass(es).

There is existing logging (enabled by -Xlog:aot+resolve=trace) during the assembly phase when the pre-resolution happens. It prints information like this:

[0.556s][trace][aot,resolve] Resolved class  [  8] java.lang.Object -> java.lang.Object
[0.556s][trace][aot,resolve] Resolved class  [ 50] java.lang.Object -> java.lang.Thread
[0.556s][trace][aot,resolve] Resolved class  [ 55] java.lang.Object -> java.lang.VirtualThread
[0.556s][trace][aot,resolve] Resolved invokevirtual [ 57] java.lang.Object -> java.lang.Object.wait0:(J)V
[0.556s][trace][aot,resolve] Resolved invokevirtual [ 38] java.lang.Object -> java.lang.Object.wait:(J)V

Can you please add what additional information is needed here to help with the map analysis?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452283946

From kbarrett at openjdk.org  Wed Oct 22 14:26:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 22 Oct 2025 14:26:07 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <cEQjUolOt1oAoqDES9lhH6z7lYar9kdUr1fLsDxxzwE=.fb849e0d-ffde-47ed-a6aa-492f602e59a8@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
 <cEQjUolOt1oAoqDES9lhH6z7lYar9kdUr1fLsDxxzwE=.fb849e0d-ffde-47ed-a6aa-492f602e59a8@github.com>
Message-ID: <J-PHiQjLtis-QsjY6YmB_VAmjcUOhR6KUu9v4ctPv4U=.3dfe6830-0842-4f9a-8e8f-260cb98e6c95@github.com>

On Wed, 22 Oct 2025 06:51:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > So in the following code snippet neither `Atomic<EnumClass16>` nor `Atomic<uint16_t>` can be compiled.
> 
> It seems like this is expected by the implementation (only allow Integer 32/64, or Byte 8). But it is unexpected for me that `Atomic<T>` does not support these types while AtomicAccess does. At least for loads and stores. (Or is that not true on all platforms)

I don't think `AtomicAccess` supports 16bit accesses on any platform.  I also don't think `AtomicAccess` supports
8bit exchange on any platform. I wondered if I was wrong about that, but didn't find any sign of support for such.
There are some tools, like `XchgUsingCmpxchg`, that could be used to do that. Currently that's only used by some
32bit platforms to get 64bit xchg.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3432627759

From aph at openjdk.org  Wed Oct 22 14:31:27 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Oct 2025 14:31:27 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
 <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>
Message-ID: <5iAA02mfIcpLopYEOzalRicQdisil2rAJetzwkSPNQM=.62fda538-ef10-48e7-b741-e17150de4d22@github.com>

On Wed, 22 Oct 2025 12:00:04 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > SafeFetch was designed specifically for problems like this one.
> 
> It was. However, I do not believe we should be in a situation where we are checking a call branch that is the last instruction in a code buffer -- which means there is no need to incur the cost of a SafeFetch.

It's still incorrect, though, because we can't guarantee that a call can't be at the end of a mapped region. Please include this fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432654503

From stefank at openjdk.org  Wed Oct 22 14:51:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Oct 2025 14:51:52 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <v5soAnMeGVatvTNu9zQMoWiryB3zzU0j8KoaZpRvreQ=.50914cb4-6b06-4086-a5d6-67e578eb058a@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
 <v5soAnMeGVatvTNu9zQMoWiryB3zzU0j8KoaZpRvreQ=.50914cb4-6b06-4086-a5d6-67e578eb058a@github.com>
Message-ID: <1KFTUzTIgKxfgJwTjn0op2n6yTfU92Xqy3a_bjuI7pQ=.2256b468-45fe-42f2-9e27-e28ae3d25238@github.com>

On Wed, 22 Oct 2025 14:09:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/atomic.hpp line 299:
>> 
>>> 297:                    atomic_memory_order order = memory_order_conservative) {
>>> 298:     return AtomicAccess::xchg(this->value_ptr(), new_value);
>>> 299:   }
>> 
>> I am not sure I understood the motivation behind the changing of the `xchg` name, nor why `cmpxchg` did not get a similar treatment. Could you provide some elaboration here?
>> 
>> Is there any plan to change the naming in the AtomicAccess layer as well?
>
> The name "xchg" is pretty generic (it could just as easily be used for a
> non-atomic exchange in some other class). The explicit `Atomic::` (now
> `AtomicAccess::`) qualifier made for easy disambiguation. Similarly for the
> others, like "inc" and "dec", and not providing short forms for "add" and
> "sub". (And remember that we mostly eschew operator overloading, though I
> think not always to our benefit. If not for that, such other classes probably
> would be doing that rather than named operations for arithmetic.) I think
> "cmpxchg" is pretty well understood to be atomic; I think if one tried to use
> that name for a non-atomic operation in some other class one might well get
> some push-back.
> 
> Personally, I also find the short names are harder to spot in the middle of
> other code, and I liked that `AtomicAccess::foo` (formerly `Atomic::foo` was
> easy to spot.
> 
> I think updating AtomicAccess to be consistent with what we decide for
> Atomic<T> should be done, but only after Atomic<T> has been fully adopted, so
> we're only dealing the the remaining resudue. This has already been discussed
> with regard to explicit "relaxed" load/store qualifiers.

I don't know if I've said it here or only offline, so I post it here. I would have preferred if this patch retained the names from `AtomicAccess`. I don't think it would be problematic to understand that `var.xchg()` requires you to understand what `var` is. And if you know that `var` is an `Atomic` then you know what `var` is then this is no more confusing than a call to `AtomicAccess::xchg`. The same for `inc` and `dec`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2452374535

From adinn at openjdk.org  Wed Oct 22 15:30:26 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 22 Oct 2025 15:30:26 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <iHNL57XqnVSiR9oll49uIO5Go9Gk4074D8cgVNJ1DJA=.b8037dfb-4b85-4a77-b9f8-a4ba9356b974@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
 <iHNL57XqnVSiR9oll49uIO5Go9Gk4074D8cgVNJ1DJA=.b8037dfb-4b85-4a77-b9f8-a4ba9356b974@github.com>
Message-ID: <DCPVqIFi-3oNueAK0EtozQQPEQNCrNdVKpL9mCz8GHs=.26dc96a3-2630-4e24-a611-d6ed13900bcd@github.com>

On Wed, 22 Oct 2025 14:22:09 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/cds/finalImageRecipes.cpp line 130:
>> 
>>> 128: 
>>> 129:     if (cp_indices.length() > 0) {
>>> 130:       LogStreamHandle(Trace, aot, resolve) log;
>> 
>> This is very helpful information However, am I right in thinking this log output is going to be emitted during the training run?
>> 
>> It would really help if we could log details of which CP entries are resolved during an assembly run and/or a production run so we could associate linkage info, including any referenced metadata and/or heap roots, with the corresponding CP/CPCache/Klass. That would allow the map analysis to be extended to show how assets in the cache are connected to their owning Klass(es).
>
> There is existing logging (enabled by -Xlog:aot+resolve=trace) during the assembly phase when the pre-resolution happens. It prints information like this:
> 
> [0.556s][trace][aot,resolve] Resolved class  [  8] java.lang.Object -> java.lang.Object
> [0.556s][trace][aot,resolve] Resolved class  [ 50] java.lang.Object -> java.lang.Thread
> [0.556s][trace][aot,resolve] Resolved class  [ 55] java.lang.Object -> java.lang.VirtualThread
> [0.556s][trace][aot,resolve] Resolved invokevirtual [ 57] java.lang.Object -> java.lang.Object.wait0:(J)V
> [0.556s][trace][aot,resolve] Resolved invokevirtual [ 38] java.lang.Object -> java.lang.Object.wait:(J)V
> 
> Can you please add what additional information is needed here to help with the map analysis?

This is probably ok as a supplement to the data that is in the map. The source and target names can be used to associated a CP owning Klass with the corresponding Klass asset that owns the field, or Method asset that is th etarget of the method or handle call
However, this output will only be available at assembly time and only when trace level logging is enabled for aot+resolve. That's not very helpful when a user has built a cache and is trying to use aot+map trace to see what is in it. We could either regenerate the same aot+resolve trace inprocustion and require logging for those tags to be enabled. Alternatively, we could iterate over ConstantPool entries when generating the aot+map log output and print the details as part of the dump of an @@ConstantPool asset. The latter approach provides redundant info but would be easier for a log analyzer to process.
Also, if we add this to the map output we don't actually need use the raw_index to format the target names into the output. We could just use the info in the CPCcahe entry to identify what we have resolved (Klass that owns the field, Method or MethodHandle direct target) and print the offset of the target in the map. These can be translated to the relevant names by the analysis tool. This would also be the right approach for resolved Strings and j.l.Classes linked from the ConstatPool via the resolved_references array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452488844

From duke at openjdk.org  Wed Oct 22 15:30:27 2025
From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=)
Date: Wed, 22 Oct 2025 15:30:27 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <DCPVqIFi-3oNueAK0EtozQQPEQNCrNdVKpL9mCz8GHs=.26dc96a3-2630-4e24-a611-d6ed13900bcd@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
 <iHNL57XqnVSiR9oll49uIO5Go9Gk4074D8cgVNJ1DJA=.b8037dfb-4b85-4a77-b9f8-a4ba9356b974@github.com>
 <DCPVqIFi-3oNueAK0EtozQQPEQNCrNdVKpL9mCz8GHs=.26dc96a3-2630-4e24-a611-d6ed13900bcd@github.com>
Message-ID: <f_-un0_tk-lX66pVZ8iHtkuONM6bqAMJ3uoILQxNbug=.76fed9f8-abef-4a20-976b-a5bcf5d4b32e@github.com>

On Wed, 22 Oct 2025 15:25:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> There is existing logging (enabled by -Xlog:aot+resolve=trace) during the assembly phase when the pre-resolution happens. It prints information like this:
>> 
>> [0.556s][trace][aot,resolve] Resolved class  [  8] java.lang.Object -> java.lang.Object
>> [0.556s][trace][aot,resolve] Resolved class  [ 50] java.lang.Object -> java.lang.Thread
>> [0.556s][trace][aot,resolve] Resolved class  [ 55] java.lang.Object -> java.lang.VirtualThread
>> [0.556s][trace][aot,resolve] Resolved invokevirtual [ 57] java.lang.Object -> java.lang.Object.wait0:(J)V
>> [0.556s][trace][aot,resolve] Resolved invokevirtual [ 38] java.lang.Object -> java.lang.Object.wait:(J)V
>> 
>> Can you please add what additional information is needed here to help with the map analysis?
>
> This is probably ok as a supplement to the data that is in the map. The source and target names can be used to associated a CP owning Klass with the corresponding Klass asset that owns the field, or Method asset that is th etarget of the method or handle call
> However, this output will only be available at assembly time and only when trace level logging is enabled for aot+resolve. That's not very helpful when a user has built a cache and is trying to use aot+map trace to see what is in it. We could either regenerate the same aot+resolve trace inprocustion and require logging for those tags to be enabled. Alternatively, we could iterate over ConstantPool entries when generating the aot+map log output and print the details as part of the dump of an @@ConstantPool asset. The latter approach provides redundant info but would be easier for a log analyzer to process.
> Also, if we add this to the map output we don't actually need use the raw_index to format the target names into the output. We could just use the info in the CPCcahe entry to identify what we have resolved (Klass that owns the field, Method or MethodHandle direct target) and print the offset of the target in the map. These can be translated to the relevant names by the analysis tool. This would also be the right approach for resolved Strings and j.l.Classes linked from the ConstatPool via the resolved_references array.

Maybe I am a bit out of context here, but: The index there between "[" and "]", does it correspond to anything on the AOT Cache (map file)? Maybe the order of elements on the CP is the same as in the map file so I can count and index them? Can I rely on that to know what element we are talking about? And on the right hand side of the arrow, can I map that to anything on the cache too? Maybe to `Class` and `Method` assets inside the cache with the same name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452491547

From adinn at openjdk.org  Wed Oct 22 15:46:22 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 22 Oct 2025 15:46:22 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <f_-un0_tk-lX66pVZ8iHtkuONM6bqAMJ3uoILQxNbug=.76fed9f8-abef-4a20-976b-a5bcf5d4b32e@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <EvpfU12l9hjxFXHW9OaYaL10IwJHvJ8lbJjcr3UJgBc=.154c732b-0983-490c-b06e-9c20dfa81e49@github.com>
 <iHNL57XqnVSiR9oll49uIO5Go9Gk4074D8cgVNJ1DJA=.b8037dfb-4b85-4a77-b9f8-a4ba9356b974@github.com>
 <DCPVqIFi-3oNueAK0EtozQQPEQNCrNdVKpL9mCz8GHs=.26dc96a3-2630-4e24-a611-d6ed13900bcd@github.com>
 <f_-un0_tk-lX66pVZ8iHtkuONM6bqAMJ3uoILQxNbug=.76fed9f8-abef-4a20-976b-a5bcf5d4b32e@github.com>
Message-ID: <FGn11giFT-1tPGCLq_za6TQn6lqLU7rDO3C9tpxfWws=.392d9c6f-e061-4bb9-8352-e94180455109@github.com>

On Wed, 22 Oct 2025 15:26:06 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

>> This is probably ok as a supplement to the data that is in the map. The source and target names can be used to associated a CP owning Klass with the corresponding Klass asset that owns the field, or Method asset that is th etarget of the method or handle call
>> However, this output will only be available at assembly time and only when trace level logging is enabled for aot+resolve. That's not very helpful when a user has built a cache and is trying to use aot+map trace to see what is in it. We could either regenerate the same aot+resolve trace inprocustion and require logging for those tags to be enabled. Alternatively, we could iterate over ConstantPool entries when generating the aot+map log output and print the details as part of the dump of an @@ConstantPool asset. The latter approach provides redundant info but would be easier for a log analyzer to process.
>> Also, if we add this to the map output we don't actually need use the raw_index to format the target names into the output. We could just use the info in the CPCcahe entry to identify what we have resolved (Klass that owns the field, Method or MethodHandle direct target) and print the offset of the target in the map. These can be translated to the relevant names by the analysis tool. This would also be the right approach for resolved Strings and j.l.Classes linked from the ConstatPool via the resolved_references array.
>
> Maybe I am a bit out of context here, but: The index there between "[" and "]", does it correspond to anything on the AOT Cache (map file)? Maybe the order of elements on the CP is the same as in the map file so I can count and index them? Can I rely on that to know what element we are talking about? And on the right hand side of the arrow, can I map that to anything on the cache too? Maybe to `Class` and `Method` assets inside the cache with the same name?

The (cp) index identifies the offset of slot for the resolved entry in the ConstantPool's data array. There is a corresponding raw index which identifies the offset of the slot in the ConstantPoolCache's ResolvedField/Method/Handle data array. The loaded method bytecode starts off using the cp index. However, it is rewritten during class loading to use the raw index. The ResolvedField/Method/Handle entry caches the raw index so it can be translated back to the cp index.
Fo rlog analysis we either need to print the same info with a cache map offset or else you need to translate the printed name to an asset of the type indicated by the bytecode (e.g.Method when the bytecode is, say, invokevirtual).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452533142

From iklam at openjdk.org  Wed Oct 22 15:46:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Oct 2025 15:46:20 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
Message-ID: <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>

On Wed, 22 Oct 2025 02:23:32 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

Looks good overall. I think the handling of fast bytecodes can be simplified.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 225:

> 223:     while (!bcs.is_last_bytecode()) {
> 224:       bcs.next();
> 225:       Bytecodes::Code raw_bc = bcs.raw_code();

Maybe we can avoid listing all the `_nofast` and `_fast` bytecodes with 


Bytecodes::Code raw = bcs.code();

-------------

PR Review: https://git.openjdk.org/jdk/pull/27927#pullrequestreview-3366420407
PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452539553

From duke at openjdk.org  Wed Oct 22 16:11:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 16:11:53 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <1mJDNP4BPxU6lH_5D0Z7V_zssJMjfzT9VCC42c89r1Y=.dcc53858-9d25-475c-937c-1f7f3f956234@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

@kevinjwalls 

> Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.
>
> The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

I think I'm leaning towards jdk.lang/com.sun over java.lang since there are GC algorithms out there (which we don't have in HotSpot), that make this method sometimes less useful. A method in java.lang may need to consider the most generic situation. For instance, GCs that pushes out most of its work onto mutators. It may be hard to accurately measure this at mutator level and we don't want to force JDK implementors to do so. As such this should be categorized as a JDK-specific method. I understand we would prefer jdk.lang over com.sun for new additions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3433172604

From asmehra at openjdk.org  Wed Oct 22 16:17:31 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 16:17:31 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>
Message-ID: <QbzTnaqU13OhSB9fz5nv35vN7nubVrRdxEx5HGa25oI=.89d13dff-0252-4c06-95d5-dcb730075d54@github.com>

On Wed, 22 Oct 2025 15:42:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 225:
> 
>> 223:     while (!bcs.is_last_bytecode()) {
>> 224:       bcs.next();
>> 225:       Bytecodes::Code raw_bc = bcs.raw_code();
> 
> Maybe we can avoid listing all the `_nofast` and `_fast` bytecodes with 
> 
> 
> Bytecodes::Code raw = bcs.code();

Yes, this is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452629751

From asmehra at openjdk.org  Wed Oct 22 16:23:58 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 16:23:58 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <QbzTnaqU13OhSB9fz5nv35vN7nubVrRdxEx5HGa25oI=.89d13dff-0252-4c06-95d5-dcb730075d54@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>
 <QbzTnaqU13OhSB9fz5nv35vN7nubVrRdxEx5HGa25oI=.89d13dff-0252-4c06-95d5-dcb730075d54@github.com>
Message-ID: <QSzNNcM1M6seuztwhRDHQ6oa7vXtp_ptKZFxFn4Jf0A=.df0bd5e7-378d-4212-82e2-b0c5a000b741@github.com>

On Wed, 22 Oct 2025 16:15:05 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 225:
>> 
>>> 223:     while (!bcs.is_last_bytecode()) {
>>> 224:       bcs.next();
>>> 225:       Bytecodes::Code raw_bc = bcs.raw_code();
>> 
>> Maybe we can avoid listing all the `_nofast` and `_fast` bytecodes with 
>> 
>> 
>> Bytecodes::Code raw = bcs.code();
>
> Yes, this is better.

But there is also "invokehandle" which is not a Java bytecode, and it needs to be handled separately. So I guess can't use bcs.code() here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452644990

From asmehra at openjdk.org  Wed Oct 22 16:43:52 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 16:43:52 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <QrrvXNSklTiGjqcsH33Eqn4IQXik7cOfUfFLKzz8bhU=.31ec0e5d-f0b6-4640-bec0-be32901df73d@github.com>
Message-ID: <9VBpClOeM963tjtCf6Ev8KAKi03nPwg76wvXmFRi3_g=.3b810a14-1b69-4507-8c5f-6be6684f4e9f@github.com>

On Wed, 22 Oct 2025 15:42:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 225:
> 
>> 223:     while (!bcs.is_last_bytecode()) {
>> 224:       bcs.next();
>> 225:       Bytecodes::Code raw_bc = bcs.raw_code();
> 
> Maybe we can avoid listing all the `_nofast` and `_fast` bytecodes with 
> 
> 
> Bytecodes::Code raw = bcs.code();

@iklam I guess we will have to stick with what I have here because of `invokehandle`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452697500

From iklam at openjdk.org  Wed Oct 22 17:17:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Oct 2025 17:17:18 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
Message-ID: <x0Zu0jkYq8NeJNDXpbKMwZS4jfkkkk-Y-WTdAsrlUrU=.0f811009-5fc6-4bf0-a46e-ee3b7ae080a2@github.com>

On Wed, 22 Oct 2025 02:23:32 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27927#pullrequestreview-3366731537

From asmehra at openjdk.org  Wed Oct 22 18:07:05 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 18:07:05 GMT
Subject: RFR: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <x0Zu0jkYq8NeJNDXpbKMwZS4jfkkkk-Y-WTdAsrlUrU=.0f811009-5fc6-4bf0-a46e-ee3b7ae080a2@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
 <x0Zu0jkYq8NeJNDXpbKMwZS4jfkkkk-Y-WTdAsrlUrU=.0f811009-5fc6-4bf0-a46e-ee3b7ae080a2@github.com>
Message-ID: <pv5mgJKWKOzMCyP6CmH64D2zrZMTWedBR5PWpGpqonA=.409a8179-1f7d-426f-8c23-3e320a7aaff9@github.com>

On Wed, 22 Oct 2025 17:14:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> Marked as reviewed by iklam (Reviewer).

@iklam thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27927#issuecomment-3433575898

From asmehra at openjdk.org  Wed Oct 22 19:15:21 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 22 Oct 2025 19:15:21 GMT
Subject: Integrated: 8370377: Avoid resolving constant pool entries during
 preimage generation in the training run
In-Reply-To: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
References: <4XfCoQkRx0sKVfWRjXnA0F9G3B7HzcO8pOWM0Xim2Gs=.592de96c-3294-4ee7-a582-8a402716017d@github.com>
Message-ID: <tfEqCkUmY1OUdhBNPf64vk65OCnHCAjBiaH-6LztiU4=.63f8d1e8-2097-41f3-866e-6efd0cd3a764@github.com>

On Wed, 22 Oct 2025 02:23:32 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.

This pull request has now been integrated.

Changeset: d8ebe387
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8ebe387595af43e2cdbbce396547d6daaf8c7dc
Stats:     114 lines in 4 files changed: 53 ins; 12 del; 49 mod

8370377: Avoid resolving constant pool entries during preimage generation in the training run

Reviewed-by: adinn, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/27927

From kbarrett at openjdk.org  Wed Oct 22 20:09:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 22 Oct 2025 20:09:47 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <1KFTUzTIgKxfgJwTjn0op2n6yTfU92Xqy3a_bjuI7pQ=.2256b468-45fe-42f2-9e27-e28ae3d25238@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
 <v5soAnMeGVatvTNu9zQMoWiryB3zzU0j8KoaZpRvreQ=.50914cb4-6b06-4086-a5d6-67e578eb058a@github.com>
 <1KFTUzTIgKxfgJwTjn0op2n6yTfU92Xqy3a_bjuI7pQ=.2256b468-45fe-42f2-9e27-e28ae3d25238@github.com>
Message-ID: <LWU69SWHgvzIyNWFJWLsw8v9oBX_b9k19cxWgJZ4Nk0=.e6c4e745-5f6a-4675-87b4-18e5fbc2ac3a@github.com>

On Wed, 22 Oct 2025 14:48:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The name "xchg" is pretty generic (it could just as easily be used for a
>> non-atomic exchange in some other class). The explicit `Atomic::` (now
>> `AtomicAccess::`) qualifier made for easy disambiguation. Similarly for the
>> others, like "inc" and "dec", and not providing short forms for "add" and
>> "sub". (And remember that we mostly eschew operator overloading, though I
>> think not always to our benefit. If not for that, such other classes probably
>> would be doing that rather than named operations for arithmetic.) I think
>> "cmpxchg" is pretty well understood to be atomic; I think if one tried to use
>> that name for a non-atomic operation in some other class one might well get
>> some push-back.
>> 
>> Personally, I also find the short names are harder to spot in the middle of
>> other code, and I liked that `AtomicAccess::foo` (formerly `Atomic::foo` was
>> easy to spot.
>> 
>> I think updating AtomicAccess to be consistent with what we decide for
>> Atomic<T> should be done, but only after Atomic<T> has been fully adopted, so
>> we're only dealing the the remaining resudue. This has already been discussed
>> with regard to explicit "relaxed" load/store qualifiers.
>
> I don't know if I've said it here or only offline, so I post it here. I would have preferred if this patch retained the names from `AtomicAccess`. I don't think it would be problematic to understand that `var.xchg()` requires you to understand what `var` is. And if you know that `var` is an `Atomic` then you know what `var` is then this is no more confusing than a call to `AtomicAccess::xchg`. The same for `inc` and `dec`.

Obviously, I disagree. I think using those names would be strictly (and
noticeably) worse that what is currently proposed, and have explained why I
think that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2453224169

From fandreuzzi at openjdk.org  Wed Oct 22 20:58:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 20:58:24 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v5]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <7XgDXusUBZA5Q-PRV2YL8eWTuTxXOFqO6ev7ScAQfUc=.7ce457ee-bddd-45a8-9199-470e1d507177@github.com>

> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nn

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/8ea13b6e..98754ee8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From sspitsyn at openjdk.org  Wed Oct 22 21:20:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:20:50 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <ucrHL3nlJgKb7E_2KHjyxrMpGylqA6BGsESX3iPRB0w=.cb058e91-3254-4daf-b987-76e1ead00c06@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/6f9bacd9...1dafec32

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3367580190

From lmesnik at openjdk.org  Wed Oct 22 21:39:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 21:39:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <CTime1EP201OKQEGclEXb6y0DSE44d7Z6us3y2K8iCo=.5cbf8ee2-9b63-477d-98c4-cd2aa4f213ec@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/99431d1f...1dafec32

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3367619935

From duke at openjdk.org  Wed Oct 22 21:45:40 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Oct 2025 21:45:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <dTtuCCP3VlnvnGwEgNcviisq3DDMigSX-Zcwkf16F_s=.d7dc9da0-ec3a-45f7-b122-a3d652eb7672@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/a9898f46...1dafec32

@fandreuz 
Your change (at version 1dafec32b57ac557b66dfe91c4bd2964019c9ff1) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434297134

From sspitsyn at openjdk.org  Wed Oct 22 21:45:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:45:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <2JEh_c2gMQIJurFDLNjpaO3ydq0B2n78STax6f2zI7Y=.b844616e-98cb-46ab-a207-c431f2b3bb1b@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/a9898f46...1dafec32

Thank you for the updates!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434297489

From fandreuzzi at openjdk.org  Wed Oct 22 21:45:34 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 21:45:34 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
 <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
Message-ID: <QzeAsbPW6NlEGulMufStCbCpOCK4NFzmXRcCXFjVXl4=.03d85465-15c1-470a-9c01-ea02f7ad6d2b@github.com>

On Thu, 16 Oct 2025 22:31:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert
>>  - replace
>
> The approach looks okay to me. Thank you for taking care about this issue!

Thanks for the review @sspitsyn, @sspitsyn, @alexmenkov and @dholmes-ora.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434293942

From sspitsyn at openjdk.org  Wed Oct 22 21:45:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:45:42 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
 <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>
Message-ID: <32BnXBMwR8EaozsDvNyBfNdBFUwNOyWW3abUCgsdd3w=.a4922c46-d388-4e77-88c1-29cdc9703a0f@github.com>

On Tue, 21 Oct 2025 09:28:21 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:
>> 
>>> 45: 
>>> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
>>> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);
>> 
>> Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)
>
> Fixed in a401f0a118785f600e70ca0099802ff05e967bc9 and 925f9fc828597f920e4b800d63428e414f8b0345. I thought the error could be printed with `jvmti->GetErrorName`, but I guess that would introduce unnecessary complication. Let me know what you think @sspitsyn.

Usually, we use the test library functions `check_jvmti_error()` and `check_jvmti_status()` from the `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp`. The `jvmti->GetErrorName()` can be used there but it is not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2453414160

From fandreuzzi at openjdk.org  Wed Oct 22 21:50:38 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 21:50:38 GMT
Subject: Integrated: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <lynjWEOl6hkABzTog2n6gqJiVWi6IOyj7RU8yJqnkgs=.11b843bc-f202-4b72-a89d-af78c8f743cb@github.com>

On Mon, 13 Oct 2025 11:26:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 2a8cbd94
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a8cbd944ba4d8896e48181e396c65f70e5aa215
Stats:     167 lines in 3 files changed: 167 ins; 0 del; 0 mod

8359472: JVM crashes when attaching a dynamic agent before JVMTI_PHASE_LIVE

Reviewed-by: lmesnik, sspitsyn, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/27766

From dlong at openjdk.org  Wed Oct 22 22:05:06 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 22 Oct 2025 22:05:06 GMT
Subject: RFR: 8367002: Missing compiled exception handler for "recursive"
 exception [v4]
In-Reply-To: <xxNhE1D3x3BKBDaPG8xJfkABkAaFnlXA55vPtymJ5bk=.26acc27f-23c3-408e-bf9f-f4fdfb5619d6@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
 <pVnexVhsaToGDHvVeOYJI-ixgQNh6VssZTWdq95PBvs=.66851498-310a-4b4c-8d42-0cc4549510bf@github.com>
 <xxNhE1D3x3BKBDaPG8xJfkABkAaFnlXA55vPtymJ5bk=.26acc27f-23c3-408e-bf9f-f4fdfb5619d6@github.com>
Message-ID: <Tx0aGAigyk1FNmNUQ2LcZCOoICk6wM1Skl54HqGMSp8=.f64c18d9-1f11-4aba-baf8-2e2e9d032aed@github.com>

On Mon, 20 Oct 2025 09:01:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete test/hotspot/jtreg/compiler/exceptions/a
>
> That looks good to me.

Thanks @TobiHartmann and @vnkozlov .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27683#issuecomment-3434330647

From dlong at openjdk.org  Wed Oct 22 22:05:07 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 22 Oct 2025 22:05:07 GMT
Subject: Integrated: 8367002: Missing compiled exception handler for
 "recursive" exception
In-Reply-To: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
References: <DBGnAaviD-KHmt9qrJomkp05Pt5y99i-nfeKDYUmmnE=.7e75480e-a7a9-4ec8-a314-8a8cd406f3d7@github.com>
Message-ID: <uqL96u9Y7S5O6IqZ-rL3zhnk15dP32_62gRpLYoof3Q=.b4720749-4a2a-46b6-a5ab-7cf437850fd9@github.com>

On Wed, 8 Oct 2025 02:09:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> In some rare cases, such as a catch type that is loadable but inaccessible, a compiled exception handler may be missing, causing exception handling to incorrectly skip that handler.  Instead, with this fix, we will deoptimize and let the interpreter handle it.  This aligns compiled execution with interpreted.  The new test checks this with a somewhat odd construction: an exception handler that is considered not because it is a match, but because the type in the catch is inaccessible.  In this case the interpreter rethrows IllegalAccessError, not from the bci of the instruction that caused the original exception, but from the bci of the non-matching exception handler.  Whether or not this is the correct behavior for the interpreter is a separate issue.  For now the compiler will continue to follow the precedent set by the interpreter.

This pull request has now been integrated.

Changeset: 0744db83
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0744db8366183a0fd07f42ee1ce6ef677bf4136e
Stats:     166 lines in 6 files changed: 155 ins; 7 del; 4 mod

8367002: Missing compiled exception handler for "recursive" exception

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/27683

From dholmes at openjdk.org  Thu Oct 23 01:10:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Oct 2025 01:10:10 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v2]
In-Reply-To: <ILHRjSFYSIJpMO2yJly3aMjzs0amesgHHBYrqTWOL5A=.4d13865e-1c98-4f5f-91db-73073102ad07@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <tMYudbv3unsZ31OdT7Fbbs7RSCTmnIOJHpCF7HED55w=.a3ae9b37-c1f7-445e-8c9a-f1fdffdecec3@github.com>
 <ILHRjSFYSIJpMO2yJly3aMjzs0amesgHHBYrqTWOL5A=.4d13865e-1c98-4f5f-91db-73073102ad07@github.com>
Message-ID: <Osow7acN9VgiKWT_NFMEjdVaqvzmKG1dUkR3ubptqKU=.118b375b-8da7-4d1e-a103-daae66faad36@github.com>

On Wed, 22 Oct 2025 11:25:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Also isn't there a way to define file specific flags so this only gets set for whitebox.cpp?
> 
> Yes I could do this, if you prefer ?

Please - best to always do the most minimal build change. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3434724364

From dlong at openjdk.org  Thu Oct 23 02:38:06 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Oct 2025 02:38:06 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v22]
In-Reply-To: <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
Message-ID: <KumGJr38Xh1EzI8bTzu3soKOu1FaAKuu2E2no3_lnc4=.77244b55-d88f-41c6-9b6a-81ad6d605e0a@github.com>

On Tue, 21 Oct 2025 15:54:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
>> 
>> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
>> 
>> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
>> 
>> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
>> 
>> We mark all sites that we know will write to code memory with
>> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
>> 
>> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
>> 
>> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
>> 
>> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - Merge from maaster
>  - Merge from maaster
>  - Merge branch 'master' into JDK-8328306
>  - Cleanup
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/9a88d7f4...42e5505d

OK, I just submitted testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3434855009

From dlong at openjdk.org  Thu Oct 23 03:02:06 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Oct 2025 03:02:06 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <sLtuESmB1LD7LYYeqHk84OVupPdUKAzHm3iHgWW2YDY=.6349e1c3-34cd-4b42-9a75-0766040432aa@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
 <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
 <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>
 <4Cj8ndIna8Do2EfcPsFR85vpAsHGPKtwAvrgp2dTkxU=.e996f1ed-c3a7-45be-a723-190db1bbea73@github.com>
 <sLtuESmB1LD7LYYeqHk84OVupPdUKAzHm3iHgWW2YDY=.6349e1c3-34cd-4b42-9a75-0766040432aa@github.com>
Message-ID: <RDWhfCJyxBidVx1C5Vyz_O_YdsLJbs4j61lpnx-18c4=.8cf64e6d-b858-4975-89e5-31ae0abd7584@github.com>

On Wed, 22 Oct 2025 14:15:12 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> If we mark them as not-entrant, then the is_not_entrant() check below will still catch them, right?
>
> I see, I assumed an nmethod couldn't be marked as on-stack without entry barriers, but that doesn't seem to be the case.
> 
> But on second thought, do you agree with the fix I'm proposing in this PR? I think the following two work items could be implemented and reviewed in separate changesets:
> - Allow not-entrant nmethod to be collected during GC (I removed `is_static_method()` from L2599, so native nmethods are treated just like normal nmethods)
> - Evaluate the implications of removing entry barriers for native nmethods, thus letting GC reclaim them whenever `!is_maybe_on_stack() && is_not_entrant()`, but without the overhead of entry barriers.
> 
> I'm proposing this because I guess the latter will need more discussion and is technically not needed to fix the memory leak I address in this PR. Do you agree @dean-long ? I could create another ticket to handle the second item.

Yes, I'm fine with it being a separate issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2453797323

From duke at openjdk.org  Thu Oct 23 03:24:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 23 Oct 2025 03:24:08 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
 <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>
Message-ID: <rTQYPPSgaDKWJX_WfasiM94eRXXdkYtd5yk9nar3TkY=.8f6ccdbc-9b96-4ca5-a051-d0ed875bbcff@github.com>

On Tue, 21 Oct 2025 18:19:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> Changes look fine, thanks~

Thank you @valeriepeng, @iwanowww, and @eme64 for your comments.  After code review comment updates, all recommended regression tests have been executed and have passed (with all known failures).  Benchmarks have been reran in each of the modes supported by intrinsics and these results have matched to those of pre-code review update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27807#issuecomment-3434921841

From duke at openjdk.org  Thu Oct 23 03:24:09 2025
From: duke at openjdk.org (duke)
Date: Thu, 23 Oct 2025 03:24:09 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
Message-ID: <K6fZMfg9ZQRhOrX43ljA8EoWhtvQrt7mdefDtTQ6dG8=.e701db3d-4590-4545-b12b-e6dce984033f@github.com>

On Tue, 21 Oct 2025 00:05:31 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

@smemery 
Your change (at version fdfd38929d3c7b725cf44312eba5d2f0d7da7b0a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27807#issuecomment-3434923911

From stefank at openjdk.org  Thu Oct 23 05:17:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Oct 2025 05:17:02 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <LWU69SWHgvzIyNWFJWLsw8v9oBX_b9k19cxWgJZ4Nk0=.e6c4e745-5f6a-4675-87b4-18e5fbc2ac3a@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
 <v5soAnMeGVatvTNu9zQMoWiryB3zzU0j8KoaZpRvreQ=.50914cb4-6b06-4086-a5d6-67e578eb058a@github.com>
 <1KFTUzTIgKxfgJwTjn0op2n6yTfU92Xqy3a_bjuI7pQ=.2256b468-45fe-42f2-9e27-e28ae3d25238@github.com>
 <LWU69SWHgvzIyNWFJWLsw8v9oBX_b9k19cxWgJZ4Nk0=.e6c4e745-5f6a-4675-87b4-18e5fbc2ac3a@github.com>
Message-ID: <rxemHjPB4I2CHhZxdW03Gnyqm-OALpCXRpNmHGShq28=.9562951d-4aff-4639-9b21-062370486e24@github.com>

On Wed, 22 Oct 2025 20:06:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I don't know if I've said it here or only offline, so I post it here. I would have preferred if this patch retained the names from `AtomicAccess`. I don't think it would be problematic to understand that `var.xchg()` requires you to understand what `var` is. And if you know that `var` is an `Atomic` then you know what `var` is then this is no more confusing than a call to `AtomicAccess::xchg`. The same for `inc` and `dec`.
>
> Obviously, I disagree. I think using those names would be strictly (and
> noticeably) worse that what is currently proposed, and have explained why I
> think that.

Of course. I brought this up to show that one person has so far said that xchg is a bad name and two has said that they prefer to keep it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2453941344

From fandreuzzi at openjdk.org  Thu Oct 23 08:25:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 23 Oct 2025 08:25:04 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v4]
In-Reply-To: <RDWhfCJyxBidVx1C5Vyz_O_YdsLJbs4j61lpnx-18c4=.8cf64e6d-b858-4975-89e5-31ae0abd7584@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <GkrEUTLY6WAUtuNoOcd_IUrCIhqw6-Z8dtu089MN4og=.ec961a7a-834f-4751-aee7-6d3677957c15@github.com>
 <DPqNjKEvFbbtf8cO0gwikCbZtqRwF8T4ANF1pPMCqDg=.bc0dba08-4c11-4a10-b630-ecfb044d8b38@github.com>
 <NLC-M26q1Juyy3x-B-qMOp-s3a5jq_TLspw-0jFiMRY=.d6d436b8-0afa-46ba-bd0a-278116b8bac1@github.com>
 <XiiKnk057W-WYPTQ_LEYg3oTwIsN6Z62-tT9npTBQK0=.5c829909-7aec-49c9-b304-4094e0964e8b@github.com>
 <D1AlehbByLmbJZ48HkfNgUh25mbVeJ8TsjGqzelpp_8=.6121fa25-969c-44a7-b5b1-b011062d3021@github.com>
 <4Cj8ndIna8Do2EfcPsFR85vpAsHGPKtwAvrgp2dTkxU=.e996f1ed-c3a7-45be-a723-190db1bbea73@github.com>
 <sLtuESmB1LD7LYYeqHk84OVupPdUKAzHm3iHgWW2YDY=.6349e1c3-34cd-4b42-9a75-0766040432aa@github.com>
 <RDWhfCJyxBidVx1C5Vyz_O_YdsLJbs4j61lpnx-18c4=.8cf64e6d-b858-4975-89e5-31ae0abd7584@github.com>
Message-ID: <DgF3bD7vqsJnInNTU7XTIi3s9lyzHznE_lOzVRZnFIA=.4e84dbdb-266d-4e23-8c3f-f5346877da4e@github.com>

On Thu, 23 Oct 2025 02:59:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I see, I assumed an nmethod couldn't be marked as on-stack without entry barriers, but that doesn't seem to be the case.
>> 
>> But on second thought, do you agree with the fix I'm proposing in this PR? I think the following two work items could be implemented and reviewed in separate changesets:
>> - Allow not-entrant nmethod to be collected during GC (I removed `is_static_method()` from L2599, so native nmethods are treated just like normal nmethods)
>> - Evaluate the implications of removing entry barriers for native nmethods, thus letting GC reclaim them whenever `!is_maybe_on_stack() && is_not_entrant()`, but without the overhead of entry barriers.
>> 
>> I'm proposing this because I guess the latter will need more discussion and is technically not needed to fix the memory leak I address in this PR. Do you agree @dean-long ? I could create another ticket to handle the second item.
>
> Yes, I'm fine with it being a separate issue.

https://bugs.openjdk.org/browse/JDK-8370472

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2454316998

From iwalulya at openjdk.org  Thu Oct 23 08:32:08 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 23 Oct 2025 08:32:08 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <vZ97HL26jFcy2AndqwbM-oUk2aS2PYwzHYCIh_5nPCU=.e93b2b9b-6fd5-43fa-a774-331a3cd91205@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3368792334

From fbredberg at openjdk.org  Thu Oct 23 08:37:34 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 23 Oct 2025 08:37:34 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
Message-ID: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>

This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.

The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.

This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.

Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

-------------

Commit messages:
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367982
  Stats: 2851 lines in 76 files changed: 1233 ins; 1369 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

PR: https://git.openjdk.org/jdk/pull/27915

From fbredberg at openjdk.org  Thu Oct 23 08:41:12 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 23 Oct 2025 08:41:12 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

@bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar
Hi guys!
This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code.
So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it.
Thanks in advance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3435760553

From fandreuzzi at openjdk.org  Thu Oct 23 08:44:44 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 23 Oct 2025 08:44:44 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v6]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <NRaTDA6_nwxuMP-swgW-9j71c_rUYS4iqy1aj3-Qqjw=.a5997a99-a5db-4174-b73e-d31c8f8a2966@github.com>

> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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 15 additional commits since the last revision:

 - cc
 - Merge branch 'master' into JDK-8369219
 - nn
 - update foundOne
 - fix summary
 - nn
 - Merge branch 'master' into JDK-8369219
 - trigger
 - nn
 - othervm
 - ... and 5 more: https://git.openjdk.org/jdk/compare/61d601ae...b6d94cf8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/98754ee8..b6d94cf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=04-05

  Stats: 32964 lines in 799 files changed: 19857 ins; 8954 del; 4153 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From duke at openjdk.org  Thu Oct 23 08:52:10 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 23 Oct 2025 08:52:10 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
Message-ID: <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>

On Tue, 21 Oct 2025 13:56:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> What it does is a 4 byte read at the supplied pc (i.e one instruction's worth of data) to test whether those bytes encode a nop instruction

I meant to refer to this `check` implementation, which reads 8 bytes from where `LR` points to and checks whether they contain the NOP+MOVK sequence.

https://github.com/openjdk/jdk/blob/dcf46a0a195d7386ed0bc872f60eb9c586425cc8/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L531

class NativePostCallNop: public NativeInstruction {
public:
  bool check() const {
    uint64_t insns = *(uint64_t*)addr_at(0);
    // Check for two instructions: nop; movk zr, xx
    // These instructions only ever appear together in a post-call
    // NOP, so it's unnecessary to check that the third instruction is
    // a MOVK as well.
    return (insns & 0xffe0001fffffffff) == 0xf280001fd503201f;
  }
  ```

In case of deoptimization, the LR is pointing to the entry point of the deoptimization handler stub code located one instruction before the end of the code blob - in this case, `0x0000f7cf03c5fffc`:


  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8


If I understand correctly, the `si_addr` reported by the kernel for the SIGSEGV is the address of memory location which caused the SIGSEGV. In this case it would be reported as follows, both in case the memory access was 8-byte starting at `0x0000f7cf03c5fffc` or 4-byte starting at `0x0000f7cf03c60000`:

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000


It should be possible to solve this by either using SafeFetch or by checking for NOP and MOVK separately in 4-byte reads. Both should work, however it appears the latter might be preferrable: the outcome of the check should not depend on anything outside the current code blob. Using SafeFetch can hide the issue.


@theRealAph, thank you for the advice on the SafeFetch interface - I wasn't aware it exists.
However, as it might introduce performance overhead on what appears to be designed as a fast path, and potentially might hide this kind of issue where content outside the code blob is checked, would it be suitable for you if the alternative is implemented?

The `check` is only meant to access the bytes pointed to by return address. I believe it wouldn't be correct for it to check an arbitrary location as there are no guarantees to match the constraints expected by the NativePostCallNop logic outside the compiled code. So, it should only be reading within the compiled code. When continuations are enabled, every call site should have the post-call NOP sequences following it.
The exception to this is deoptimization - where the perceived call site actually is within the deoptimization handler stub code and, with this change, is followed by the entry point of the stub code. The entry point is never going to be a NOP, so checking for NOP first would prevent the second read checking for MOVK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3435796978

From jsikstro at openjdk.org  Thu Oct 23 08:53:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 08:53:25 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM flag
Message-ID: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>

Hello,

Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.

MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.

Testing:
* Oracle's tier1-8

-------------

Commit messages:
 - 8369346: Remove default value of and deprecate the MaxRAM flag

Changes: https://git.openjdk.org/jdk/pull/27952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369346
  Stats: 59 lines in 17 files changed: 2 ins; 44 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27952/head:pull/27952

PR: https://git.openjdk.org/jdk/pull/27952

From duke at openjdk.org  Thu Oct 23 09:03:39 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 23 Oct 2025 09:03:39 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <URgBhHO4qIMlpIuj92Dzt8Cm2qLuwGrGKrri8VdViLM=.d26cb92e-bc21-451d-8bcd-49bdf0db929a@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

I've also looked into the `far_jump` vs `far_call` issue - attempting to identify why tests on my side didn't catch this.
It appears that normally methods load the return address from stack to `LR` before using `RET`, so by chance the `LR` happens to point to the entry point of the stub code upon entering the stub code.

I've managed to reproduce a situation when it isn't the case - deoptimization of parked virtual threads - where the control flow is transferred to the deoptimization handler stub code via the signal handler. In this case, the LR is pointing to the post-call sequence (which was patched to cause a `SIGILL`) within the same method. However, even in this case, the test completed successfully as apparently the `fetch_unroll_info_helper` is designed in a way that can handle both frames pointing to deoptimized methods and frames to non-deoptimized methods where execution should continue in interpreter (for example, uncommon trap).

It might be beneficial to add an assertion in the `fetch_unroll_info_helper` that ensures, for case `exec_mode` is `Unpack_deopt` (and potentially, for `Unpack_exception` too) that the LR is indeed pointing to the deoptimization handler stub code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3435836587

From jsikstro at openjdk.org  Thu Oct 23 09:04:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 09:04:21 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v2]
In-Reply-To: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
Message-ID: <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>

> Hello,
> 
> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
> 
> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
> 
> Testing:
> * Oracle's tier1-8

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Move MaxRAM to deprecated section in java.md

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27952/files
  - new: https://git.openjdk.org/jdk/pull/27952/files/c9b672f6..03188828

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27952&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27952&range=00-01

  Stats: 38 lines in 1 file changed: 19 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27952/head:pull/27952

PR: https://git.openjdk.org/jdk/pull/27952

From stuefe at openjdk.org  Thu Oct 23 09:13:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Oct 2025 09:13:55 GMT
Subject: RFR: 8368365: ASAN errors should produce hs-err files and core
 dumps [v8]
In-Reply-To: <sgyYPIJ087_0IsRvvllZcMypMvJG4gjWPcxXwjfA8hY=.bcd956e2-c3a5-4668-a969-3e12ac45ba5d@github.com>
References: <sgyYPIJ087_0IsRvvllZcMypMvJG4gjWPcxXwjfA8hY=.bcd956e2-c3a5-4668-a969-3e12ac45ba5d@github.com>
Message-ID: <P69QEb2PUx7v0f_W1yq0DErfK1o36DHgmeJc6UlC-mU=.b9250191-8400-4a07-915e-a1fd56a8c4b3@github.com>

> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks.
> 
> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply).
> 
> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below.
> 
> ---
> 
> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'openjdk:master' into JDK-8368365-ASAN-errors-should-generate-hs-err-files-and-core-dumps
 - Update address.cpp
 - Update address.cpp
 - Comment reference to asan_interface.h
 - fix
 - rethink core file behavior
 - Update address.cpp
 - remove stray modification
 - stupid sort includes test
 - add jtreg test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/aec13888...f6f84b28

-------------

Changes: https://git.openjdk.org/jdk/pull/27446/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=07
  Stats: 245 lines in 7 files changed: 243 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446

PR: https://git.openjdk.org/jdk/pull/27446

From eosterlund at openjdk.org  Thu Oct 23 09:20:48 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 09:20:48 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <BrW3i4TlbIULQS5xJeJ7KMoBOQC6h8PPnXlHsWCmF28=.d3ad90ff-c1dd-40e8-803b-ee46f0884c46@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <DHuCyWlHguKroDZYzd603AiXJdTgHVD47TYv6yVpe7E=.ce1abfb3-221b-4577-b441-75f41c75b935@github.com>
 <Z08dJ9DLajOjYGtlLItE5Q6JaGDfPRwJIfsZxNKJwdE=.ecce58c8-a6f5-4ba3-9b00-21653b1e225a@github.com>
 <4nEcE9s464ja-6i90ELsNmuxS-f9uLZyOBZlk0YylnU=.bceacf2b-ac7f-44bd-a9a4-bc78ed267e98@github.com>
 <X4kJvtZr4vARdKfQIATuOUl-K5NvPLhEbGP16VlotFc=.5b10869f-d9c0-469c-a6a3-b7e9d1b32014@github.com>
 <gJK08Exq-7GPbQObgBJbZakGF7dBPLxVKLwIoZ_zDes=.001f4968-a30d-4fd5-9d25-ce544bd7a540@github.com>
 <BrW3i4TlbIULQS5xJeJ7KMoBOQC6h8PPnXlHsWCmF28=.d3ad90ff-c1dd-40e8-803b-ee46f0884c46@github.com>
Message-ID: <kfOFL47pAcUUv1Pc9hLET2grx0INlnn0zUGeo8lu6Xw=.98b5934f-9eb9-44d8-8c86-c0ae5021a2d2@github.com>

On Wed, 22 Oct 2025 06:43:33 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>>  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?
>> 
>> @fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.
>> 
>>> CPU quotas when running in a container.
>> 
>> Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.
>> 
>>> The "machine" numbers when running in a container (which get overridden by container numbers).
>> 
>> Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 
>> 
>> Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?
>
>> >  In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"?
>> 
>> 
>> 
>> @fisk I am "against" trying to shoe-horn a poorly-defined  legacy API into a dichotomy of "container value" versus "machine value". The concepts are not at all clean or well-defined for both variants.
>> 
> 
> Okay. Let's start with the problem domain then.
> 
>> 
>> > CPU quotas when running in a container.
>> 
>> 
>> 
>> Then you need an explicit API for that. No contortion of "available processors" is going to tell you what your quota is.
>> 
> 
> While that is true, I was hoping for an API that isn't just the exact Linux implementation that screams of Linux for no good reason. What I mean by that is that having the available processors as a double seems general enough that potentially other OS containers could use it, whether or not they implemented CPU throttling in the same way. Having an explicit fraction instead does not help me much as a user.
> 
>> 
>> > The "machine" numbers when running in a container (which get overridden by container numbers).
>> 
>> 
>> 
>> Sounds simple but is it well-defined? Can you even ask the question (again I come back to available processors where sched_getaffinity will already account for the presence of the container if tasksets are used - what answer would you want for the "machine"?). 
>> 
> 
> What I specifically care about is how many cores the JVM is allowed to be scheduled to run on. These cores are shared across containers and utilizing them has a shared latency impact.
> 
> The container layer might throttle how often you are allowed to run on said processors and for how long. But neither cgroup CPU limit constrains how many processors the JVM is allowed to run on. It might run on all of them for a very short period of time.
> 
>> 
>> Aside: even if you can ask the question what use are these values if you are running within the container? Is there some means to bypass the container constraints?
> 
> So the reason this matters to me is that GC latency with a concurrent GC is all about CPU utilization. As CPU utilization grows, response times grow too across all percentiles.
> 
> So when in a position to pick how to pay for GC in terms of memory vs CPU, I want to increasingly bias the cost more towards using memory when the shared cores the container is allowed to run on get saturated, despite the individual container using less CPU.
> 
> In other words, there are trade-offs between latency, CPU and memory. All of these ar...

> @fisk there seem to be some assumptions involved in how the container actually operates to achieve its configured limits. If your CPU quota is 50% you don't know whether you will get all cores for 50% of the time or 50% of the cores for all the time - unless your container environment tells you how it operates. My recollection was that you could limit both the number of CPUs and the quota of CPU time allocated. So this would very much be a CGroups API not a generic "container" API (but although we call it a Container API it has been totally shaped by CGroups anyway ...)

It is true that you can a) configure CPU quotas, b) configure CPU weights, and C) configure the set of CPUs a cgroup container can run in, I'm not sure I follow though how we are making assumptions about the cgroup implementation in the proposed API. The API exposes only the CPU quotas/limits. I'm not sure I follow where any controversial assumptions are made about the implementation of cgroups in the API. It exposes what number of processors, on average, the container is limited to run on. Are you afraid that some exotic new container implementation might not map cleanly to describe how many processors on average is available to the container? If so - while that is possible, I'd cross that bridge when/if we get there; it sounds like a strange container environment. But perhaps that was not your point?

> You then want to be able to ask the execution environment that executes the container what resources it has available for processes (like the container). This is where I am less convinced that a suitable API exists for you to query these values from a process inside the container environment. Calling this outer layer "machine" is not really accurate, but "os" is already taken and you can't change the semantics of the existing os:: API.

Right. There is no intention to change the semantics of the existing os:: API. If the word ?machine? is not a good one, perhaps we can find a better word. Perhaps ?system? as it talks about the system resources?

> But again I think it a mistake to take the existing os:: API and and define Container and Machine versions of it, because that existing os:: API does not really map cleanly to what you want to ask. I would look at what you want to ask and define Machine and Container APIs that do that, without trying to tie it back to the existing os API (implementation can of course be shared underneath).

The questions I have are:

1) How close am I to hitting a memory limit on the container level.
2) How close am I to hitting a memory limit on the system level.
3) How close am I to hitting a CPU limit on the container level.
4) How close am I to hitting a CPU limit on the system level.

I think the proposed APIs do map cleanly to what I want to ask (+/- names). It seems like a pretty good mapping to expose what the corresponding resource usage and limits are on the container and system levels to get answers to those questions. We have modelled answers to that question in exactly the same way when you run within a container and when you run outside a container, except that you only get to ask questions about the innermost layers and not the outer layer.

Other than that, I think the main notable difference to the other os:: APIs we have, is that the CPU limit is an average on the container level. That is why it was represented as a double which better reflects that. The existing os:: API will round up to one when you have 0.125 cores available on average, because it was not designed to be an average, but is probably a good enough approximation for many use cases. But sometimes better precision is needed. Would it perhaps help if the word ?average? or ?avg? was in the name of the CPU limit function, to avoid confusion?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3435906478

From eosterlund at openjdk.org  Thu Oct 23 09:34:09 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 09:34:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v8]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <ASHQR1eTDVtk-Sfr7Oe_zVYbEdhoQw3zQt64C83WUpI=.d266ffee-2a3c-4a19-bfb2-7057f9408bc8@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Fix for minimal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/70fb7acc..99726c72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=06-07

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From adinn at openjdk.org  Thu Oct 23 09:44:18 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 23 Oct 2025 09:44:18 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>
Message-ID: <m_DJYnayvyWlslRy6BJn0gYoKkA5NT_rNOTQIo0AjBQ=.c57489f2-469c-4a90-afb9-046f9fea6392@github.com>

On Thu, 23 Oct 2025 08:48:54 GMT, Ruben <duke at openjdk.org> wrote:

> I meant to refer to this check implementation, which reads 8 bytes from where LR points to and checks whether they contain the NOP+MOVK sequence.

Ah, my apologies for misunderstanding you and also and what was going on in this code. It is indeed reading two instructions at once and checking them both in one go.

I agree with you that this is best split up into two separate reads+checks to deal with the case where we don't have a NOP and might drop off the end of the current buffer. I think this will still be less work than using SafeFetch but @theRealAph may want to override me here.

> It might be beneficial to add an assertion in the `fetch_unroll_info_helper` that ensures, for case `exec_mode` is `Unpack_deopt` (and potentially, for `Unpack_exception` too) that the `LR` is indeed pointing to the deoptimization handler stub code.

That sounds like a good idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3436002622

From ayang at openjdk.org  Thu Oct 23 11:10:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Oct 2025 11:10:12 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v2]
In-Reply-To: <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
 <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
Message-ID: <K985PNrEcJx874X6w1CrUVixl65x42h8IoYJQwtiK0A=.bfa31ede-c00b-443a-8254-afc49637382e@github.com>

On Thu, 23 Oct 2025 09:04:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
>> 
>> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
>> 
>> Testing:
>> * Oracle's tier1-8
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move MaxRAM to deprecated section in java.md

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27952#pullrequestreview-3369394093

From alanb at openjdk.org  Thu Oct 23 11:29:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Oct 2025 11:29:11 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v5]
In-Reply-To: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
Message-ID: <wVDMkRhswMMdZj8pTn01HWxdYNsYZgKTEhnGjxikL5A=.70eb9e23-59d2-4585-8bdc-4cc7c683f0d9@github.com>

On Wed, 22 Oct 2025 11:28:34 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 271:

> 269: 
> 270:     /**
> 271:      * Returns the CPU time used by garbage collection.

The latest wording is much better. For the first sentence, you might to consider expanding is a bit to something like "Returns the approximate accumulated time, in nanoseconds, spent in garbage collection."

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 285:

> 283:      * workers, VM Operations and string deduplication (if enabled).
> 284:      * The return value can be -1 if called when measurement is
> 285:      * not possible, such as during shutdown.

For the implNote then I think you are looking to say something HotSpot VM specific. That is possible with something like:  The specifics on what constitutes the time spent in garbage collection is highly implementation dependent. In the HotSpot Virtual Machine implementation, ... 

(If you are using the term "driver threads" then you will probably need to say more on what it means).

It is still the intention to use this in conjunction with OperatingSystemMXBean:: getProcessCpuTime ? If so, this could also be included here, or in an API note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454746445
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454797793

From mbaesken at openjdk.org  Thu Oct 23 11:51:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 Oct 2025 11:51:38 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v3]
In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
Message-ID: <mzOT1v_ss75FAhPtGNLRj9HkCH7Rl26FvBnt9U0hITQ=.2c43c113-8d45-4afc-bb09-ad18bc58e089@github.com>

> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
> error output is :
> 
> 
> java.lang.RuntimeException: Expected source information missing from output
> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
> 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:1474)

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Build only whitebox.cpp with new cflag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27899/files
  - new: https://git.openjdk.org/jdk/pull/27899/files/13a1b423..fec2180d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899

PR: https://git.openjdk.org/jdk/pull/27899

From mdoerr at openjdk.org  Thu Oct 23 12:09:04 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Oct 2025 12:09:04 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Thanks for cleaning this up on all platforms! Works on PPC64.
Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3436579205

From stuefe at openjdk.org  Thu Oct 23 13:06:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Oct 2025 13:06:57 GMT
Subject: Integrated: 8368365: ASAN errors should produce hs-err files and core
 dumps
In-Reply-To: <sgyYPIJ087_0IsRvvllZcMypMvJG4gjWPcxXwjfA8hY=.bcd956e2-c3a5-4668-a969-3e12ac45ba5d@github.com>
References: <sgyYPIJ087_0IsRvvllZcMypMvJG4gjWPcxXwjfA8hY=.bcd956e2-c3a5-4668-a969-3e12ac45ba5d@github.com>
Message-ID: <ZOSQepXJpeOt96HGkGJ_JvSJH-K5HAssT2iD1XYj-k0=.6b5da6d2-0f72-41c3-a61f-6ced4e7a196b@github.com>

On Tue, 23 Sep 2025 07:37:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks.
> 
> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply).
> 
> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below.
> 
> ---
> 
> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test.

This pull request has now been integrated.

Changeset: aaa9fbf6
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aaa9fbf6b5a0dda0773a657a986246b407402fa1
Stats:     245 lines in 7 files changed: 243 ins; 0 del; 2 mod

8368365: ASAN errors should produce hs-err files and core dumps

Reviewed-by: mbaesken, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/27446

From stuefe at openjdk.org  Thu Oct 23 13:35:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Oct 2025 13:35:20 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v9]
In-Reply-To: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
References: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
Message-ID: <xUSMa5OoqCqXuID9AEssL_RMCI582Hi39reNzQSwYmw=.57b1285f-2874-4ac7-a60c-69633547a401@github.com>

> This patch will give us use-after-free recognition for Metaspace and Class space. 
> 
> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. 
> 
> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded.
> 
> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided.
> 
> How this works:
> 
> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid.
> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading)
> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area.
> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped.
> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs
> 
> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah.
> 
> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use
 - Merge master
 - Feedback Johan, Axel
 - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use
 - remove stray macro
 - feedback Caspar
 - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use
 - Feedback Johan
 - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use
 - merge master
 - ... and 9 more: https://git.openjdk.org/jdk/compare/aaa9fbf6...110df7c0

-------------

Changes: https://git.openjdk.org/jdk/pull/25891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=08
  Stats: 483 lines in 26 files changed: 399 ins; 27 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/25891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891

PR: https://git.openjdk.org/jdk/pull/25891

From coleenp at openjdk.org  Thu Oct 23 13:54:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Oct 2025 13:54:26 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: <o3hpKGrTsS6w4Szf9ag-bBuHgPPA5NRXPyHVMoXtwvI=.61e6c656-aa9c-4a29-8ae4-0450006f6910@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <o3hpKGrTsS6w4Szf9ag-bBuHgPPA5NRXPyHVMoXtwvI=.61e6c656-aa9c-4a29-8ae4-0450006f6910@github.com>
Message-ID: <pzAYj8PlJPtfTlIjUq3sbK19IDg7gWPx4r3LaL19HqY=.7ea142b5-c866-4698-9c32-bb256d2cf262@github.com>

On Mon, 20 Oct 2025 20:26:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC support

Nice work!  This is a first pass with comments.  I haven't looked at the platform specific code or tests yet.

src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp line 34:

> 32: 
> 33: // Java frames don't have callee saved registers (except for rfp), so we can use a smaller RegisterMap
> 34: template <bool IncludeArgs>

Can we have a follow-on RFE to make SmallRegisterMap and it's new template in shared code.  And only have the platform specific functions here?

src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp line 73:

> 71:   bool update_map()    const { return false; }
> 72:   bool walk_cont()     const { return false; }
> 73:   bool include_argument_oops() const { return IncludeArgs; }

You made this a template rather than having an _include_argument_oops property for performance?

src/hotspot/share/interpreter/interpreterRuntime.cpp line 837:

> 835:         note_trap(current, Deoptimization::Reason_null_check);
> 836:       }
> 837:       CLEAR_PENDING_PREEMPTED_EXCEPTION;

You clear this because we want the preempted exception to cause a return to here, but not return an exception to the interpreter to rethrow?  Can you add a comment why, especially if I've got this wrong.

src/hotspot/share/interpreter/linkResolver.hpp line 192:

> 190: };
> 191: 
> 192: enum class ClassInitMode : uint8_t {

If this is just a parameter, does this need to be uint8_t ?

src/hotspot/share/oops/instanceKlass.cpp line 810:

> 808: void InstanceKlass::initialize_preemptable(TRAPS) {
> 809:   if (this->should_be_initialized()) {
> 810:     PREEMPT_ON_INIT_SUPPORTED_ONLY(PreemptableInitCall pic(THREAD, this);)

Are there any other uses of this macro?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1123:

> 1121:       assert(!call.is_valid() || call.is_invokestatic(), "only invokestatic allowed");
> 1122:       if (call.is_invokestatic() && call.size_of_parameters() > 0) {
> 1123:         assert(top_frame.interpreter_frame_expression_stack_size() > 0, "should have parameters in exp stack");

The "this" pointer will be on the top of the interpreter frame expression stack right?  Are size of parameters ever 0 here then?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1653:

> 1651:   }
> 1652:   inline intptr_t* anchor_mark_set_pd();
> 1653:   inline void anchor_mark_clear_pd();

The code is really confused whether "pd" is the beginning of the method name or the end.  Both are used but mostly in the beginning of the method. The freeze/thaw code uses it at the end so this is okay.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1731:

> 1729:   int bci;
> 1730:   if (preempt_kind == Continuation::monitorenter) {
> 1731:     assert(top.is_interpreted_frame() || top.is_runtime_frame(), "");

So could you use precond() here since it's a precondition and you have no assert message?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2061:

> 2059: 
> 2060:   // Only used for preemption on ObjectLocker
> 2061:   ObjectMonitor* _monitor;

Rather than calling it monitor, you could call it _init_lock so that it makes more sense in the following code.  The other reason to give it the same name as in initialization is so in the future we'll see the connection easily.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2686:

> 2684: 
> 2685:   {
> 2686:     HandleMarkCleaner hmc(current);  // Cleanup so._conth Handle

Why doesn't a plain HandleMark do this?
I think you chose HandleMarkCleaner because this is going to back to the interpreter code, so to be like JRT_ENTRY code.
So add something like before going back to the interpreted Java code.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2696:

> 2694: 
> 2695:     // These InterpreterRuntime entry points use JRT_ENTRY which uses a HandleMarkCleaner.
> 2696:     // Create a HandeMark to avoid destroying so._conth.

I see. The comment is helpful.

src/hotspot/share/runtime/javaThread.hpp line 540:

> 538:     }
> 539:   };
> 540: #endif

Nit: add // ASSERT to the endif.
I always wonder if these big blocks of code added to thread.hpp and javaThread.hpp should be in some new file, and just referenced from this.  Not for this change. Just a general comment.

src/hotspot/share/runtime/javaThread.hpp line 1372:

> 1370: };
> 1371: 
> 1372: class PreemptableInitCall {

If this is only used in instanceKlass.cpp, I think the definition should be there and not in javaThread.hpp.  It's not using private methds in javaThread.hpp as far as I can tell.

src/hotspot/share/runtime/javaThread.hpp line 1421:

> 1419: };
> 1420: 
> 1421: class ThreadWaitingForClassInit : public StackObj {

I think this should be in instanceKlass.cpp also near the single caller (unless there's another caller that I don't see).

src/hotspot/share/runtime/objectMonitor.cpp line 319:

> 317:   check_object_context();
> 318:   if (_object_strong.is_empty()) {
> 319:     if (Thread::TrySpinAcquire(&_object_strong_lock)) {

@toxaart Here's a new use of this SpinAcquire/SpinRelease as a TrySpinAcquire.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3367219722
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454882893
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454888028
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2453118945
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2453122999
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454901203
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455074172
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455083202
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455091984
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455104045
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455123338
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455138736
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455164468
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454898223
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454906094
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2455185797

From coleenp at openjdk.org  Thu Oct 23 13:54:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Oct 2025 13:54:28 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <sw8sGdGhk15nI659oQfosmj4UpsfFAnHJ60Ya7KL1Us=.6174a78b-a5fd-4202-bca5-56f0b2c07cdc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>
 <sw8sGdGhk15nI659oQfosmj4UpsfFAnHJ60Ya7KL1Us=.6174a78b-a5fd-4202-bca5-56f0b2c07cdc@github.com>
Message-ID: <mhE2T_TNXsLA1EwiXQ4Athag4JAarRyRbll9wbEuJlY=.63115d8b-b71c-4e93-99b0-0b82d9896f74@github.com>

On Wed, 22 Oct 2025 06:08:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ok. Just to double check, casting to `InstanceKlass*` where we call `initialize_preemptable` for the `invokestatic` and `getstatic/putstatic` cases should be always safe right? I don?t see how we could get there for an `ArrayKlass`.
>
> Hmmm seems there is an `objArrayKlass::initialize` (and an empty `typeArrayKlass::initialize`) but I don't know when such classes would be initialized. I would not expect them to be the target of invokestatic/getstatic/putstatic, nor for "new" but a "new array" would have to do the initialization of the bottom class (at least that is what `objArrayKlass::initialize` does) - and I don't think the current changes address that case. ??
> 
> Anyway leave the placement as-is.

Would an initialize_preemptable() = 0 be better?  then you can see if it's called by anything other than InstanceKlass.  Klass is always abstract.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2454914030

From eosterlund at openjdk.org  Thu Oct 23 15:50:40 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 15:50:40 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
Message-ID: <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>

On Wed, 22 Oct 2025 13:41:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?

I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3437754817

From eosterlund at openjdk.org  Thu Oct 23 16:07:08 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 16:07:08 GMT
Subject: RFR: 8370500: Change windows x64 implementation of
 os::current_stack_pointer()
Message-ID: <sAmou6kB81IuMTYwzBqZN2Wg1A9mISuCZtRkTIFnObU=.6d559375-4d55-4527-aaa6-499e8ee749d5@github.com>

The current implementation of os::current_stack_pointer() on windows x64 uses a code stub to read the stack pointer. This means that os::current_stack_pointer() may not be called early on in the bootstrapping. This prevents unhandled oops from being enabled early on.

However, there is an MSVC intrinsic that provides the same functionality without the need to use stubs: _AddressOfReturnAddress() from intrin.h
By changing this implementation on windows x64, we should be able to call os::current_stack_pointer() early on as it is seemingly the only implementation with such a bootstrapping dependency.

-------------

Commit messages:
 - 8370500: Change windows x64 implementation of os::current_stack_pointer()

Changes: https://git.openjdk.org/jdk/pull/27956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370500
  Stats: 40 lines in 4 files changed: 3 ins; 35 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27956/head:pull/27956

PR: https://git.openjdk.org/jdk/pull/27956

From phubner at openjdk.org  Thu Oct 23 16:08:13 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 23 Oct 2025 16:08:13 GMT
Subject: RFR: 8366488: JVM_FindClassFromClass should assert that from class is
 never null
Message-ID: <_V9TNnv7nX6xxwRWszWjaMpTePhJIO7LghR5CE4e-Zo=.26d47f26-a7a8-479e-8e51-52b95024c41d@github.com>

Hi all,

The `from_class` nullcheck  in `JVM_FindClassFromClass` is redundant, as the this is the Java mirror which cannot be null during class linking/verification [1]. Therefore, it has been refactored to be an assertion instead.

Testing: tiers 1-4 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64). As part of a separate experiment, I've also run tiers 1-6 on x64 Linux with a non-null assertion before we call `Verifier::inference_verify` (which in turn, eventually, calls this code).

[1] For reasoning, see https://bugs.openjdk.org/browse/JDK-8366488

-------------

Commit messages:
 - Convert conditional to assertion.

Changes: https://git.openjdk.org/jdk/pull/27957/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27957&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366488
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27957/head:pull/27957

PR: https://git.openjdk.org/jdk/pull/27957

From iklam at openjdk.org  Thu Oct 23 16:08:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Oct 2025 16:08:49 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
Message-ID: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>

On Thu, 23 Oct 2025 15:47:55 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
> 
> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.

We have 


#if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
#define INCLUDE_CDS_JAVA_HEAP 1


So we need to make sure it works for 32 bit as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3437850552

From pchilanomate at openjdk.org  Thu Oct 23 17:39:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 23 Oct 2025 17:39:38 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Thanks for doing this cleanup. I only found some instances in comments where `lightweight` referred to the locking mode and not just the fast path, so the word should be removed rather than replaced with `fast`.

src/hotspot/share/oops/markWord.hpp line 215:

> 213:   ObjectMonitor* monitor() const {
> 214:     assert(has_monitor(), "check");
> 215:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");

Suggestion:

    assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

src/hotspot/share/oops/markWord.hpp line 241:

> 239:   }
> 240:   static markWord encode(ObjectMonitor* monitor) {
> 241:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");

Suggestion:

    assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

src/hotspot/share/runtime/objectMonitor.hpp line 164:

> 162:   // Because of frequent access, the metadata field is at offset zero (0).
> 163:   // Enforced by the assert() in metadata_addr().
> 164:   // * Fast locking with UseObjectMonitorTable:

Suggestion:

  // * Locking with UseObjectMonitorTable:

src/hotspot/share/runtime/objectMonitor.hpp line 166:

> 164:   // * Fast locking with UseObjectMonitorTable:
> 165:   //   Contains the _object's hashCode.
> 166:   // * * Fast locking without UseObjectMonitorTable:

Suggestion:

  // * Locking without UseObjectMonitorTable:

src/hotspot/share/runtime/objectMonitor.inline.hpp line 77:

> 75: 
> 76: inline markWord ObjectMonitor::header() const {
> 77:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");

Suggestion:

  assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 82:

> 80: 
> 81: inline void ObjectMonitor::set_header(markWord hdr) {
> 82:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");

Suggestion:

  assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 87:

> 85: 
> 86: inline intptr_t ObjectMonitor::hash() const {
> 87:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");

Suggestion:

  assert(UseObjectMonitorTable, "Only used by locking with OM table");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 92:

> 90: 
> 91: inline void ObjectMonitor::set_hash(intptr_t hash) {
> 92:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");

Suggestion:

  assert(UseObjectMonitorTable, "Only used by locking with OM table");

src/hotspot/share/runtime/synchronizer.cpp line 648:

> 646:       // stability and then install the hash.
> 647:     } else {
> 648:       assert(!mark.is_unlocked() && !mark.is_fast_locked(), "invariant");

Note that `mark.monitor()` below already asserts `mark.has_monitor()` which is stronger.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3371295012
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456141768
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456143321
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456146275
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456190353
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456194705
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456195722
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456201765
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456204642
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456288423

From asmehra at openjdk.org  Thu Oct 23 19:02:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 23 Oct 2025 19:02:56 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump time
Message-ID: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>

This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.

-------------

Commit messages:
 - 8334898: Resolve static field/method references at CDS dump time

Changes: https://git.openjdk.org/jdk/pull/27958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334898
  Stats: 120 lines in 8 files changed: 90 ins; 18 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27958/head:pull/27958

PR: https://git.openjdk.org/jdk/pull/27958

From asmehra at openjdk.org  Thu Oct 23 19:07:44 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 23 Oct 2025 19:07:44 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <pyhfvJZeVtBkFnHCdTKxkVk5XINdcEg4r05EelE_mMs=.e7443f90-e7c8-43e1-82f0-33022b57be1f@github.com>

On Thu, 23 Oct 2025 18:56:44 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.

@iklam can you please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27958#issuecomment-3438677275

From eosterlund at openjdk.org  Thu Oct 23 19:15:29 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 19:15:29 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
 <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
Message-ID: <Crxlv9lOmgJCpSesWre55iAe5sxOykaewK7yVNEi7u4=.8074c95f-c4dc-49d9-acd3-8776d832954d@github.com>

On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
> 
> > 
> 
> > I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
> 
> 
> 
> We have 
> 
> 
> 
> ```
> 
> #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
> 
> #define INCLUDE_CDS_JAVA_HEAP 1
> 
> ```
> 
> 
> 
> So we need to make sure it works for 32 bit as well.

Does 32 bit really need CDS at all? Zero surely doesn't; it's 100x slower. Left we have 32 bit ARM which is seemingly on life support. But yeah either way - not  a decision for this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3438689367

From dlong at openjdk.org  Thu Oct 23 19:32:56 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Oct 2025 19:32:56 GMT
Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute"
 switching [v22]
In-Reply-To: <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com>
 <jQmFrbatvNqwB2gTi0NhLCUii3qIlILrE_jdti5idyc=.96b6e698-105d-42d3-8e33-cc8ad8c9620e@github.com>
Message-ID: <XMhavicDff1gYqcvTPqdbieN47dP-DM7qn-keDb5MGQ=.5fa45e58-0339-4ff1-8009-e0172cda4bcb@github.com>

On Tue, 21 Oct 2025 15:54:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other.
>> 
>> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times.
>> 
>> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all.
>> 
>> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`.
>> 
>> We mark all sites that we know will write to code memory with
>> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these.
>> 
>> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily.
>> 
>> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`.
>> 
>> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - Merge from maaster
>  - Merge from maaster
>  - Merge branch 'master' into JDK-8328306
>  - Cleanup
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - Check for working WX
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/9a88d7f4...42e5505d

There was one crash running applications/ctw/modules/java_base_2.java with the flags "-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -Djava.awt.headless=true":
guarantee(StressWXHealing) failed: We should not reach here unless StressWXHealing
Here:

V  [libjvm.dylib+0xead1c4]  Thread::wx_enable_write()+0x0
V  [libjvm.dylib+0x10093cc]  JVM_handle_bsd_signal+0x244
C  [libsystem_platform.dylib+0x36a4]  _sigtramp+0x38
V  [libjvm.dylib+0xe3f5bc]  nmethod::make_deoptimized()+0x360
V  [libjvm.dylib+0x4e114c]  CodeCache::make_marked_nmethods_deoptimized()+0xd8
V  [libjvm.dylib+0x5d61a8]  Deoptimization::deoptimize_all_marked()+0x58
V  [libjvm.dylib+0x5d5ff4]  DeoptimizationScope::deoptimize_marked()+0x364
V  [libjvm.dylib+0x89a4b8]  InstanceKlass::link_class_impl(JavaThread*)+0x6c8
V  [libjvm.dylib+0x897b30]  InstanceKlass::initialize_impl(JavaThread*)+0x9c
V  [libjvm.dylib+0x897a20]  InstanceKlass::initialize(JavaThread*)+0x30
V  [libjvm.dylib+0x11a4f44]  Unsafe_EnsureClassInitialized0(JNIEnv_*, _jobject*, _jobject*)+0x1c8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3438776677

From duke at openjdk.org  Thu Oct 23 19:40:38 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 23 Oct 2025 19:40:38 GMT
Subject: Integrated: 8326609: New AES implementation with updates specified in
 FIPS 197
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <pnPsOxs9SC5eAXkufc-jBvQTKmjQLAyVTCXU_3oXyOE=.26cff75d-d268-4835-9fa1-b793dc2ae26a@github.com>

On Tue, 14 Oct 2025 19:33:41 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

This pull request has now been integrated.

Changeset: 62f11cd4
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62f11cd4070f21ad82eebbb5319bdbbf4e13f9cf
Stats:     2991 lines in 18 files changed: 1476 ins; 1473 del; 42 mod

8326609: New AES implementation with updates specified in FIPS 197

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.org/jdk/pull/27807

From iklam at openjdk.org  Thu Oct 23 22:21:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Oct 2025 22:21:02 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <O5zXWbX6Ige7xl9nGT4sEgoQR_8P4XRNU7saQdaJb2s=.eca2be55-44c5-4be0-8e91-4f66c1db00e7@github.com>

On Thu, 23 Oct 2025 18:56:44 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
> 
> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
> 
> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
> 
> 
> After this PR:
> 
> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0

LGTM. I am testing this PR in our CI.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27958#pullrequestreview-3373038369

From pchilanomate at openjdk.org  Thu Oct 23 22:25:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 23 Oct 2025 22:25:53 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v7]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <9IlDXdLcZSa3JCBBn9J8JUYWvlfKukDOlP1oqeTJRAQ=.6642ab0e-67ad-4776-b46c-acbee0136138@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - rename _monitor to _init_lock
 - Extra comments from Coleen
 - define methods in resolve_from_cache with TRAPS and use CHECK_AND_CLEAR_PREEMPTED

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/6000edb6..2786b1d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=05-06

  Stats: 95 lines in 7 files changed: 34 ins; 38 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

PR: https://git.openjdk.org/jdk/pull/27802

From pchilanomate at openjdk.org  Thu Oct 23 22:34:14 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 23 Oct 2025 22:34:14 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: <pzAYj8PlJPtfTlIjUq3sbK19IDg7gWPx4r3LaL19HqY=.7ea142b5-c866-4698-9c32-bb256d2cf262@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <o3hpKGrTsS6w4Szf9ag-bBuHgPPA5NRXPyHVMoXtwvI=.61e6c656-aa9c-4a29-8ae4-0450006f6910@github.com>
 <pzAYj8PlJPtfTlIjUq3sbK19IDg7gWPx4r3LaL19HqY=.7ea142b5-c866-4698-9c32-bb256d2cf262@github.com>
Message-ID: <Vbxnh7q4CKHHzUpJHlGsMZdhUbr7032IItyqtx7sxlo=.41e3f7e2-5bb6-4450-8e80-aaf2a53008c0@github.com>

On Thu, 23 Oct 2025 11:59:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PPC support
>
> src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp line 34:
> 
>> 32: 
>> 33: // Java frames don't have callee saved registers (except for rfp), so we can use a smaller RegisterMap
>> 34: template <bool IncludeArgs>
> 
> Can we have a follow-on RFE to make SmallRegisterMap and it's new template in shared code.  And only have the platform specific functions here?

Yes, good idea.

> src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp line 73:
> 
>> 71:   bool update_map()    const { return false; }
>> 72:   bool walk_cont()     const { return false; }
>> 73:   bool include_argument_oops() const { return IncludeArgs; }
> 
> You made this a template rather than having an _include_argument_oops property for performance?

Not really, using a bool member would work too.

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 837:
> 
>> 835:         note_trap(current, Deoptimization::Reason_null_check);
>> 836:       }
>> 837:       CLEAR_PENDING_PREEMPTED_EXCEPTION;
> 
> You clear this because we want the preempted exception to cause a return to here, but not return an exception to the interpreter to rethrow?  Can you add a comment why, especially if I've got this wrong.

You got it right. I realized we can remove this macro which looks odd here, and use `CHECK_AND_CLEAR_PREEMPTED` at the actual VM entry point as we have for the `new` case. We only needed to declare `resolve_invoke` with the `TRAPS` parameter (as it should have been already). I did the same?with `resolve_get_put`, and also fixed the other methods in `resolve_from_cache` for consistency. Let me know if you still want a comment about not wanting to throw this exception to Java (not sure where to place it).

> src/hotspot/share/interpreter/linkResolver.hpp line 192:
> 
>> 190: };
>> 191: 
>> 192: enum class ClassInitMode : uint8_t {
> 
> If this is just a parameter, does this need to be uint8_t ?

Right, removed.

> src/hotspot/share/oops/instanceKlass.cpp line 810:
> 
>> 808: void InstanceKlass::initialize_preemptable(TRAPS) {
>> 809:   if (this->should_be_initialized()) {
>> 810:     PREEMPT_ON_INIT_SUPPORTED_ONLY(PreemptableInitCall pic(THREAD, this);)
> 
> Are there any other uses of this macro?

I missed to remove this when ppc was added. Removed now.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1123:
> 
>> 1121:       assert(!call.is_valid() || call.is_invokestatic(), "only invokestatic allowed");
>> 1122:       if (call.is_invokestatic() && call.size_of_parameters() > 0) {
>> 1123:         assert(top_frame.interpreter_frame_expression_stack_size() > 0, "should have parameters in exp stack");
> 
> The "this" pointer will be on the top of the interpreter frame expression stack right?  Are size of parameters ever 0 here then?

This is only for `invokestatic` so no this pointer.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1653:
> 
>> 1651:   }
>> 1652:   inline intptr_t* anchor_mark_set_pd();
>> 1653:   inline void anchor_mark_clear_pd();
> 
> The code is really confused whether "pd" is the beginning of the method name or the end.  Both are used but mostly in the beginning of the method. The freeze/thaw code uses it at the end so this is okay.

I added `patch_pd_unused` in 8359222 which should have been `patch_unused_pd`. :)

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1731:
> 
>> 1729:   int bci;
>> 1730:   if (preempt_kind == Continuation::monitorenter) {
>> 1731:     assert(top.is_interpreted_frame() || top.is_runtime_frame(), "");
> 
> So could you use precond() here since it's a precondition and you have no assert message?

Yes, but don?t really see the benefit. It?s replacing a null string for `precond` in a crash.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2061:
> 
>> 2059: 
>> 2060:   // Only used for preemption on ObjectLocker
>> 2061:   ObjectMonitor* _monitor;
> 
> Rather than calling it monitor, you could call it _init_lock so that it makes more sense in the following code.  The other reason to give it the same name as in initialization is so in the future we'll see the connection easily.

Done.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2686:
> 
>> 2684: 
>> 2685:   {
>> 2686:     HandleMarkCleaner hmc(current);  // Cleanup so._conth Handle
> 
> Why doesn't a plain HandleMark do this?
> I think you chose HandleMarkCleaner because this is going to back to the interpreter code, so to be like JRT_ENTRY code.
> So add something like before going back to the interpreted Java code.

A full `HandleMark` works too. It?s just that there is already a `HandleMark` in the callstack (from the original upcall to Java from the carrier thread), so we can use a `HandleMarkCleaner` here.

> src/hotspot/share/runtime/javaThread.hpp line 540:
> 
>> 538:     }
>> 539:   };
>> 540: #endif
> 
> Nit: add // ASSERT to the endif.
> I always wonder if these big blocks of code added to thread.hpp and javaThread.hpp should be in some new file, and just referenced from this.  Not for this change. Just a general comment.

Done.

> src/hotspot/share/runtime/javaThread.hpp line 1372:
> 
>> 1370: };
>> 1371: 
>> 1372: class PreemptableInitCall {
> 
> If this is only used in instanceKlass.cpp, I think the definition should be there and not in javaThread.hpp.  It's not using private methds in javaThread.hpp as far as I can tell.

Moved, and also `ThreadWaitingForClassInit`. Should I move pre-existent `ThreadInClassInitializer` too?

> src/hotspot/share/runtime/javaThread.hpp line 1421:
> 
>> 1419: };
>> 1420: 
>> 1421: class ThreadWaitingForClassInit : public StackObj {
> 
> I think this should be in instanceKlass.cpp also near the single caller (unless there's another caller that I don't see).

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457645698
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457646549
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457643620
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457645117
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457648892
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457658418
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457660576
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457662495
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457664724
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457669384
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457670686
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457647838
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457649861

From pchilanomate at openjdk.org  Thu Oct 23 22:34:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 23 Oct 2025 22:34:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <mhE2T_TNXsLA1EwiXQ4Athag4JAarRyRbll9wbEuJlY=.63115d8b-b71c-4e93-99b0-0b82d9896f74@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>
 <sw8sGdGhk15nI659oQfosmj4UpsfFAnHJ60Ya7KL1Us=.6174a78b-a5fd-4202-bca5-56f0b2c07cdc@github.com>
 <mhE2T_TNXsLA1EwiXQ4Athag4JAarRyRbll9wbEuJlY=.63115d8b-b71c-4e93-99b0-0b82d9896f74@github.com>
Message-ID: <hygPsW_MVriCu6FN0nWedpQzfNFkCmJ86KVDnozs5PA=.14c0a785-7da4-4fd7-ab8c-5af687a53a4e@github.com>

On Thu, 23 Oct 2025 12:11:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hmmm seems there is an `objArrayKlass::initialize` (and an empty `typeArrayKlass::initialize`) but I don't know when such classes would be initialized. I would not expect them to be the target of invokestatic/getstatic/putstatic, nor for "new" but a "new array" would have to do the initialization of the bottom class (at least that is what `objArrayKlass::initialize` does) - and I don't think the current changes address that case. ??
>> 
>> Anyway leave the placement as-is.
>
> Would an initialize_preemptable() = 0 be better?  then you can see if it's called by anything other than InstanceKlass.  Klass is always abstract.

We can but we would have to implement it for `ArrayKlass` too which is kind of the same of what we have now. We have a `ShouldNotReachHere()` in `Klass::initialize_preemptable` (following the same pattern as `Klass::initialize`), so we will catch anything other than `InstanceKlass`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2457655990

From fyang at openjdk.org  Fri Oct 24 01:20:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Oct 2025 01:20:02 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
Message-ID: <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>

On Thu, 23 Oct 2025 08:38:05 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> @bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar Hi guys! This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code. So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hello, A simple tier1 test is good on linux-riscv64. I checked the riscv part and I only see in indentation issues as pointed out by @TheRealMDoerr.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3440216009

From dholmes at openjdk.org  Fri Oct 24 05:16:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Oct 2025 05:16:01 GMT
Subject: RFR: 8366488: JVM_FindClassFromClass should assert that from class
 is never null
In-Reply-To: <_V9TNnv7nX6xxwRWszWjaMpTePhJIO7LghR5CE4e-Zo=.26d47f26-a7a8-479e-8e51-52b95024c41d@github.com>
References: <_V9TNnv7nX6xxwRWszWjaMpTePhJIO7LghR5CE4e-Zo=.26d47f26-a7a8-479e-8e51-52b95024c41d@github.com>
Message-ID: <UtmilCUFWV-ZuosQXMSGg0b7RlVlhApI1l66kIHTREk=.f75a6763-1a17-4e46-a539-e09e245aceeb@github.com>

On Thu, 23 Oct 2025 15:55:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `from_class` nullcheck  in `JVM_FindClassFromClass` is redundant, as the this is the Java mirror which cannot be null during class linking/verification [1]. Therefore, it has been refactored to be an assertion instead.
> 
> Testing: tiers 1-4 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64). As part of a separate experiment, I've also run tiers 1-6 on x64 Linux with a non-null assertion before we call `Verifier::inference_verify` (which in turn, eventually, calls this code).
> 
> [1] For reasoning, see https://bugs.openjdk.org/browse/JDK-8366488

I agree with the analysis - the value can never be null based on the current code paths.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27957#pullrequestreview-3374595739

From iklam at openjdk.org  Fri Oct 24 05:40:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Oct 2025 05:40:01 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <K5Ediuc564GEIDEtGKDGkIsqdjAma4vCCesae2HaHAE=.3406fb9f-e100-4918-8a4f-5be49ee28245@github.com>

On Thu, 23 Oct 2025 18:56:44 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
> 
> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
> 
> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
> 
> 
> After this PR:
> 
> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0

The zero builds fail with the following:


Creating jdk-26-internal_linux-x64_bin-tests-debug.tar.gz
Creating interim jimage
Compiling up to 2 files for CLASSLIST_JAR
Creating support/classlist.jar
ERROR: Failed to generate link optimization data. This is likely a problem with the newly built JVM/JDK.
Error occurred during initialization of VM
java.lang.InternalError: platform encoding not initialized
	at jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method)
	at jdk.internal.util.SystemProps$Raw.<init>(java.base/SystemProps.java:266)
	at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:67)
	at java.lang.System.initPhase1(java.base/System.java:1784)

GenerateLinkOptData.gmk:74: recipe for target '/workspace/build/linux-x64-zero-debug/support/link_opt/classlist' failed
make[3]: *** [/workspace/build/linux-x64-zero-debug/support/link_opt/classlist] Error 1
make/Main.gmk:657: recipe for target 'generate-link-opt-data' failed
make[2]: *** [generate-link-opt-data] Error 2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27958#issuecomment-3441133131

From dholmes at openjdk.org  Fri Oct 24 06:16:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Oct 2025 06:16:04 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <INNocSY8muwF1hpn9g3P2VqHG_eXh1FQr5FO_-kdrnQ=.6192f1a0-da56-47f2-8bb1-b446be1b5302@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

This discussion is running off the rails I think - my fault, so let me try and drag it back on. I earlier made a fairly simple statement:

> It might be clearer to just define specific methods for the things that are currently missing that you need to query, rather than trying to generalize the existing poorly-defined API. If you insist that three API's is better then I would like to see clear specifications for what each of the method variants actually returns.

Looking again, and ignoring some earlier comments by others that might have mislead me, what is being proposed is much closer to that than what I initially thought. What I wanted to avoid was having 3 variants of a given method when the original os:: form of that method isn't even well-defined today. But I am okay with a set of "machine/system" methods to ask queries that make sense for the "machine"; and a set of container ones that make sense for containers. (And the implementation of the os:: method can delegate to whichever provides the "right" answer.)

But to clarify my issue with the container notion of available processors ... you state:

>  It exposes what number of processors, on average, the container is limited to run on. 

Yes - but if I am asking how many processors are available I am doing so because I want to know how many threads it makes sense creating, so I know how many threads could potentially be executing in parallel at the same time. Using my example above that could be 50% of the physical cores or 100% depending on how the container decides to implement quotas. That fits in, I think, with the example Casper gave above:

> In latency-sensitive workloads we might burst onto all 16 cores for a short interval and still stay within the 2-cpu quota. At the moment, the JVM has no way to know that those extra 14 cores even exist, so it cannot make that optimization.

Indeed - but if you create 16 threads to take advantage of that and the container only actually gives you 2 cores for 100% of the time, then you have totally messed up. This notion of "average processors" does not help you size accordingly, nor does knowing the number of "machine" processors, if you don't know how the container operates. That is one assumption about the container implementation I was referring to. The other is that the container never defines cpusets, otherwise you have no way that I am aware of to actually determine there are 16 cores on the machine**. Maybe these are safe assumptions to make, but it would be nice if the underlying container subsystem could give you those answers directly based on how it does things (then you wouldn't need to query the "machine".)

** If you assume no hot-swapping of CPUs then `sysconf(_SC_NPROCESSORS_ONLN)` could give you that answer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3441241899

From aboldtch at openjdk.org  Fri Oct 24 06:36:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 24 Oct 2025 06:36:16 GMT
Subject: RFR: 8370500: Change windows x64 implementation of
 os::current_stack_pointer()
In-Reply-To: <sAmou6kB81IuMTYwzBqZN2Wg1A9mISuCZtRkTIFnObU=.6d559375-4d55-4527-aaa6-499e8ee749d5@github.com>
References: <sAmou6kB81IuMTYwzBqZN2Wg1A9mISuCZtRkTIFnObU=.6d559375-4d55-4527-aaa6-499e8ee749d5@github.com>
Message-ID: <6fIAHK-L9e0OBYPld6iR1lgn3POICveaHHgv3RzYuHQ=.9979dd97-8dd3-4aa5-9d16-bfcb5bba6aab@github.com>

On Thu, 23 Oct 2025 15:44:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The current implementation of os::current_stack_pointer() on windows x64 uses a code stub to read the stack pointer. This means that os::current_stack_pointer() may not be called early on in the bootstrapping. This prevents unhandled oops from being enabled early on.
> 
> However, there is an MSVC intrinsic that provides the same functionality without the need to use stubs: _AddressOfReturnAddress() from intrin.h
> By changing this implementation on windows x64, we should be able to call os::current_stack_pointer() early on as it is seemingly the only implementation with such a bootstrapping dependency.

Sounds resonable.

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27956#pullrequestreview-3374738933

From stuefe at openjdk.org  Fri Oct 24 06:37:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Oct 2025 06:37:43 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v10]
In-Reply-To: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
References: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@github.com>
Message-ID: <ckYAP8HHGv4OhEIpJM_Rrg-H9RPBAzyC4AS5iYBTVZo=.a51b849a-c917-4a03-9bae-853a39e97f8a@github.com>

> This patch will give us use-after-free recognition for Metaspace and Class space. 
> 
> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. 
> 
> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded.
> 
> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided.
> 
> How this works:
> 
> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid.
> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading)
> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area.
> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped.
> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs
> 
> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah.
> 
> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  includes sorted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25891/files
  - new: https://git.openjdk.org/jdk/pull/25891/files/110df7c0..86c282b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891

PR: https://git.openjdk.org/jdk/pull/25891

From dholmes at openjdk.org  Fri Oct 24 07:02:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Oct 2025 07:02:08 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v3]
In-Reply-To: <mzOT1v_ss75FAhPtGNLRj9HkCH7Rl26FvBnt9U0hITQ=.2c43c113-8d45-4afc-bb09-ad18bc58e089@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <mzOT1v_ss75FAhPtGNLRj9HkCH7Rl26FvBnt9U0hITQ=.2c43c113-8d45-4afc-bb09-ad18bc58e089@github.com>
Message-ID: <CTvixvlG3BHKara3fkWqJsVZR_od0vuq7Q0xvFPlyWI=.9d4d629c-88ac-4227-ab4f-70b023305c1d@github.com>

On Thu, 23 Oct 2025 11:51:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build only whitebox.cpp with new cflag

One style nit.

This still needs build team approval.

Thanks

test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java line 149:

> 147: 
> 148:         if (wb.hasExternalSymbolsStripped()) { expectSourceInformation = false; }
> 149: 

Suggestion:

        if (wb.hasExternalSymbolsStripped()) { 
            expectSourceInformation = false; 
        }

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27899#pullrequestreview-3374797603
PR Review Comment: https://git.openjdk.org/jdk/pull/27899#discussion_r2459086347

From mbaesken at openjdk.org  Fri Oct 24 07:22:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 Oct 2025 07:22:40 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v4]
In-Reply-To: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
Message-ID: <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>

> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
> error output is :
> 
> 
> java.lang.RuntimeException: Expected source information missing from output
> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
> 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:1474)

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust style nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27899/files
  - new: https://git.openjdk.org/jdk/pull/27899/files/fec2180d..6390e48b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27899&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27899/head:pull/27899

PR: https://git.openjdk.org/jdk/pull/27899

From mbaesken at openjdk.org  Fri Oct 24 07:22:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 Oct 2025 07:22:41 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v3]
In-Reply-To: <CTvixvlG3BHKara3fkWqJsVZR_od0vuq7Q0xvFPlyWI=.9d4d629c-88ac-4227-ab4f-70b023305c1d@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <mzOT1v_ss75FAhPtGNLRj9HkCH7Rl26FvBnt9U0hITQ=.2c43c113-8d45-4afc-bb09-ad18bc58e089@github.com>
 <CTvixvlG3BHKara3fkWqJsVZR_od0vuq7Q0xvFPlyWI=.9d4d629c-88ac-4227-ab4f-70b023305c1d@github.com>
Message-ID: <Zm6REY2ATnjUSGnAo_wRPzfW7D2NJQaQWi9_C_w5yH4=.3f1f89b4-3d85-4567-8b30-320875322367@github.com>

On Fri, 24 Oct 2025 06:59:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This still needs build team approval.

Christoph is from the build group / team too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3441476420

From amitkumar at openjdk.org  Fri Oct 24 07:43:08 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 24 Oct 2025 07:43:08 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
 <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
Message-ID: <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>

On Fri, 24 Oct 2025 01:16:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

> @bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar Hi guys! This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code. So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hi, I ran tier1 and seems like on s390 everything is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3441568007

From sgehwolf at openjdk.org  Fri Oct 24 08:23:04 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 24 Oct 2025 08:23:04 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <8RgpPnr9F8ltCUSxU81hfH-u7KgK7FQRIiKufU_Lg5o=.3aeb406d-c9c2-44fa-a707-8e59d7ce6652@github.com>

On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

Could anybody please help review this! Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3441752392

From eosterlund at openjdk.org  Fri Oct 24 08:31:04 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 24 Oct 2025 08:31:04 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <INNocSY8muwF1hpn9g3P2VqHG_eXh1FQr5FO_-kdrnQ=.6192f1a0-da56-47f2-8bb1-b446be1b5302@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
 <INNocSY8muwF1hpn9g3P2VqHG_eXh1FQr5FO_-kdrnQ=.6192f1a0-da56-47f2-8bb1-b446be1b5302@github.com>
Message-ID: <afMVy5NIZSFVFy-tGfJI41K80VgbkU1UYtfrIoyjjlc=.9e9f3808-984d-459e-be5a-5f682be35a12@github.com>

On Fri, 24 Oct 2025 06:13:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looking again, and ignoring some earlier comments by others that might have mislead me, what is being proposed is much closer to that than what I initially thought. What I wanted to avoid was having 3 variants of a given method when the original os:: form of that method isn't even well-defined today. But I am okay with a set of "machine/system" methods to ask queries that make sense for the "machine"; and a set of container ones that make sense for containers. (And the implementation of the os:: method can delegate to whichever provides the "right" answer.)

Yeah that sounds good.

> But to clarify my issue with the container notion of available processors ... you state:
> 
> > It exposes what number of processors, on average, the container is limited to run on.
> 
> Yes - but if I am asking how many processors are available I am doing so because I want to know how many threads it makes sense creating, so I know how many threads could potentially be executing in parallel at the same time. Using my example above that could be 50% of the physical cores or 100% depending on how the container decides to implement quotas. That fits in, I think, with the example Casper gave above:
> 
> > In latency-sensitive workloads we might burst onto all 16 cores for a short interval and still stay within the 2-cpu quota. At the moment, the JVM has no way to know that those extra 14 cores even exist, so it cannot make that optimization.
> 
> Indeed - but if you create 16 threads to take advantage of that and the container only actually gives you 2 cores for 100% of the time, then you have totally messed up. This notion of "average processors" does not help you size accordingly, nor does knowing the number of "machine" processors, if you don't know how the container operates. That is one assumption about the container implementation I was referring to. 

Right - the number of threads you want to use is different if you have a concurrent system, compared to a parallel system, when the container implementation shares cores across containers. With a long running parallel workload, you want to size your threads according to the container average, as you say, because you won't get more CPU than that anyway and you will only run into trouble blowing the limits. Conversely, with a concurrent workload such as a server, where the unit of work takes, say, 1 ms to execute, you are more likely to want to size the threads of your thread pool according to the machine limits. Any time a request comes in to a server and there are idle CPUs on the machine, you are better off making sure the cores are working to reduce latency, compared to just waiting around. Then other means (such as load balancing, provisioning more containers, etc) need to be used to control that the average CPU utilization does not get close to the container limits (or indeed mac
 hine limits), because that will send latencies into a roller coaster.

In other words, with a parallel workload you want to size the threads according to the container limits. With a concurrent workload you want to size according to the machine limits, but monitor that average CPU utilization both on the container and machine levels, do not get too close to their corresponding limits. And that is why we want to be able to be able to access both of them.

I guess your concern is about an alternative container implementation where the limits are strict and you get a single exclusive core that none of the other containers is allowed to use, not one core on average. Then you would not need to worry about the machine layer, due to the lack of sharing of hardware resources across containers. I think there is a philosophical question there: is that alternative container implementation really implementing a container, or a virtual machine? For all practical purposes, it seems to me like that would be running in a virtual machine with dedicated hardware that we happen to call a container. I suspect that should a container environment like that pop up, we might want to model it like a virtual machine and not like a container.

If we did model it like a container, then yes, I wouldn't want to look around at the completely orthogonal "machine" layer any longer, as I don't share hardware with any of the other "containers", and they don't share any of my hardware either. It would be a rather different situation.

> The other is that the container never defines cpusets, otherwise you have no way that I am aware of to actually determine there are 16 cores on the machine**. Maybe these are safe assumptions to make, but it would be nice if the underlying container subsystem could give you those answers directly based on how it does things (then you wouldn't need to query the "machine".)
> 
> ** If you assume no hot-swapping of CPUs then `sysconf(_SC_NPROCESSORS_ONLN)` could give you that answer.

I agree. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3441797254

From kfarrell at openjdk.org  Fri Oct 24 08:32:34 2025
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 24 Oct 2025 08:32:34 GMT
Subject: RFR: 8359706: Add file descriptor count and maximum limit to VM.info
Message-ID: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>

Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.

This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

-------------

Commit messages:
 - clean up
 - clean up
 - undo commit to linux.cpp
 - rm max count and malloc
 - bsd.cpp
 - update
 - change to print outs
 - replace NULL
 - rm classloader
 - rm files
 - ... and 8 more: https://git.openjdk.org/jdk/compare/62f11cd4...2d2acfe4

Changes: https://git.openjdk.org/jdk/pull/27971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359706
  Stats: 92 lines in 6 files changed: 92 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971

PR: https://git.openjdk.org/jdk/pull/27971

From aph at openjdk.org  Fri Oct 24 09:39:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Oct 2025 09:39:02 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <zVCgRPNBltISFU28LJPlekli1Q0fMUDUlydZTpkt7Oo=.1e51cf89-8f12-438b-981f-c4959fab8a52@github.com>

On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

I'm not surprised about the lack of reviews because it's long and the result is rather ugly. (Sorry, but I had to say it.)

This is less jarring to read:


struct Result {
  const int _value; const bool _ok;
  Result(int value, bool ok) : _value(value), _ok(ok) {}
};


...


Result CgroupSubsystem::active_processor_count() {
  ...
  cpu_count = os::Linux::active_processor_count();
  if (!CgroupUtil::processor_count(contrl->controller(), cpu_count, value)) {
    return Result(value, false);
  }
  assert(value > 0 && value <= cpu_count, "must be");
  // Update cached metric to avoid re-reading container settings too often
  cpu_limit->set_value(value, OSCONTAINER_CACHE_TIMEOUT);

  return Result(value, true);
}


called as:


  auto [result, ok] = cgroup_subsystem->active_processor_count();
  if (ok) ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442136772

From sgehwolf at openjdk.org  Fri Oct 24 09:45:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 24 Oct 2025 09:45:25 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
Message-ID: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>

> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

Severin Gehwolf 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 six additional commits since the last revision:

 - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
 - Fix print_container_info output
 - whitespace clean-ups and other small fixes
 - Fix log format in container macro and scanf format
 - Fix duplicate include in osContainer_linux
 - 8365606: Container code should not be using jlong/julong

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27743/files
  - new: https://git.openjdk.org/jdk/pull/27743/files/e906490e..917a51c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=00-01

  Stats: 39117 lines in 885 files changed: 23412 ins; 10970 del; 4735 mod
  Patch: https://git.openjdk.org/jdk/pull/27743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27743/head:pull/27743

PR: https://git.openjdk.org/jdk/pull/27743

From aph at redhat.com  Fri Oct 24 10:23:46 2025
From: aph at redhat.com (Andrew Haley)
Date: Fri, 24 Oct 2025 11:23:46 +0100
Subject: virtual/stress/PingPon fails on win-arm64
In-Reply-To: <20867C7A-417A-446C-8AAA-CFCAC75A467A@azul.com>
References: <20867C7A-417A-446C-8AAA-CFCAC75A467A@azul.com>
Message-ID: <be471a0f-1c59-46a0-9e7d-087ff754ed6b@redhat.com>

On 10/10/2025 11:14, Sergey Nazarkin wrote:
> We have encountered an issue with the PingPong [1] stress test with JDK21 (and JDK 25) run on Win-ARM64, other platforms seem unaffected. I haven't found any record of this issue (except valhalla related [2]), so I'd like to check if it's a known problem.

It wasn't known to me, and it doesn't look Valhalla related.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From eosterlund at openjdk.org  Fri Oct 24 10:44:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 24 Oct 2025 10:44:53 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v9]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <3oUWkJvh73VUnHcycK-2MahguUU_zwxv-xvfztvZg9M=.1edcb4ef-dd2d-41da-b33f-77cfbd55f1cb@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Missing unlock diagnostic VM options, and remove unintended comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/99726c72..b355e036

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=07-08

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From cnorrbin at openjdk.org  Fri Oct 24 10:50:03 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 24 Oct 2025 10:50:03 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
Message-ID: <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>

On Fri, 24 Oct 2025 09:45:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
>> 
>> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
>> 
>> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
>> 
>> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
>> 
>> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
>> 
>> Testing (looking good):
>> - [x] GHA
>> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
>> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
>> 
>> Thoughts? Opinions?
>
> Severin Gehwolf 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
>  - Fix print_container_info output
>  - whitespace clean-ups and other small fixes
>  - Fix log format in container macro and scanf format
>  - Fix duplicate include in osContainer_linux
>  - 8365606: Container code should not be using jlong/julong

I'm currently looking at this, just as a quick FYI.

I'm fine with the proposed interface as it is (boolean return + passed reference). Since the adjacent `os` functions recently changed to use this interface, and the disproportionate (to me) amount of bikeshedding it took to reach a consensus on that, introducing yet another interface here, for what's essentially a subcomponent, doesn't make much sense. It's clearer if the whole `os` stack sticks to the same interface.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442470839

From coleenp at openjdk.org  Fri Oct 24 11:19:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 11:19:04 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Never say "last" cleanup.  The renaming to remove "lightweight" looks good.  I wasn't sure if we wanted to keep that name or not.  There's a lightweight NMT coming so this won't be confused with that anymore.  I guess that's good.

src/hotspot/share/runtime/synchronizer.cpp line 1454:

> 1452: // -----------------------------------------------------------------------------
> 1453: // ConcurrentHashTable storing links from objects to ObjectMonitors
> 1454: class ObjectMonitorTable : AllStatic {

I guess after looking at this, it made sense to combine the lightweightSynchronizer code into synchronizer.cpp (should be ObjectSynchronizer.hpp/cpp).  I wonder if the OM table code could be split out into its own file objectMontitorTable.hpp/cpp.  I feel like synchronzer.hpp/cpp again does too many different things.

src/hotspot/share/runtime/synchronizer.inline.hpp line 40:

> 38:     return read_monitor(mark);
> 39:   } else {
> 40:     return ObjectSynchronizer::get_monitor_from_table(current, obj);

I don't think there's a need for this file anymore.  read_monitor is mostly called inside synchronizer.cpp, so it can be inlined there.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3375815186
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2459848893
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2459863994

From stuefe at openjdk.org  Fri Oct 24 11:27:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Oct 2025 11:27:04 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
 <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>
Message-ID: <DkPhrXwWHHptnQ50THfxKiJatf5-c7WOa67JW1IbXt8=.57054308-bfb9-4161-b476-cb2fd700d0e4@github.com>

On Fri, 24 Oct 2025 10:46:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> I'm currently looking at this, just as a quick FYI.
> 
> I'm fine with the proposed interface as it is (boolean return + passed reference). Since the adjacent `os` functions recently changed to use this interface, and the disproportionate (to me) amount of bikeshedding it took to reach a consensus on that, introducing yet another interface here, for what's essentially a subcomponent, doesn't make much sense. It's clearer if the whole `os` stack sticks to the same interface.

I agree. Its not pretty, but consistent with what we did elsewhere. Nobody wants to do that discussion again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442620964

From stuefe at openjdk.org  Fri Oct 24 11:31:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Oct 2025 11:31:07 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
Message-ID: <IH03ciVM6ggRh1YuaKkqRLAs-M4hE6BoTaEnEJMnHc4=.eadabf15-9df9-4633-b7ac-81a2b71e31f1@github.com>

On Fri, 24 Oct 2025 09:45:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
>> 
>> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
>> 
>> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
>> 
>> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
>> 
>> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
>> 
>> Testing (looking good):
>> - [x] GHA
>> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
>> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
>> 
>> Thoughts? Opinions?
>
> Severin Gehwolf 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
>  - Fix print_container_info output
>  - whitespace clean-ups and other small fixes
>  - Fix log format in container macro and scanf format
>  - Fix duplicate include in osContainer_linux
>  - 8365606: Container code should not be using jlong/julong

Mostly looks good to me. Some remnants of raw UINT64_FORMAT are left. I did not see any type clashes.

I hold off the final review until it is clear that the interfaces are agreed upon.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 638:

> 636: bool CgroupSubsystem::active_processor_count(int& value) {
> 637:   int cpu_count;
> 638:   int result = -1;

Why not get rid of result and use `value` throughout like you did in the cached case?

src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 80:

> 78:     return false;                                                                     \
> 79:   }                                                                                   \
> 80:   log_trace(os, container)(log_string " is: " UINT64_FORMAT, retval);                 \

Here and in other places: don't use raw UINT64_FORMAT; use `PHYS_MEM_TYPE_FORMAT` instead.

src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 105:

> 103:   is_ok = controller->read_string(filename, retval, buf_size);                            \
> 104:   if (!is_ok) {                                                                           \
> 105:     log_trace(os, container)(log_string " failed: -2");                                   \

Why this change? Did the constant value change?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27743#pullrequestreview-3375466876
PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459590069
PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459894453
PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459898806

From clanger at openjdk.org  Fri Oct 24 11:46:06 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 24 Oct 2025 11:46:06 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v4]
In-Reply-To: <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
Message-ID: <-6l0di2HLMzXvb0keU3RQNanYonVvG5-tdWQw2VHLLk=.cdf57ee7-9663-492b-8133-d713b4163fec@github.com>

On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust style nit

I think the change is good, however, we should wait for resolution of the PR #24012. Maybe even inline these changes into that. Because without #24012, this here will not be necessary...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3442706212

From mbaesken at openjdk.org  Fri Oct 24 11:55:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 Oct 2025 11:55:03 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v4]
In-Reply-To: <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
Message-ID: <6FfKIqRf68GxCYMLfJQbRq-wb8RyC9TvVxB_uW-mzwI=.a605ad7b-2578-4837-ab23-9e741416ef4c@github.com>

On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust style nit

If you build OpenJDK on Windows with stripped debug symbols, you will most likely need it.
Assuming you always have the source info in is not valid; I think the change is a good compromise. Instead of using the wrong assumption, or of  doing complicated things e.g. with the DIA SDK to analyze the debug info.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3442736592

From duke at openjdk.org  Fri Oct 24 12:19:52 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:19:52 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v6]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zPwIZTo2vL1vSn_JuUqmxRCcC0KqvRpnwQdbz0JweDQ=.b98781e8-de09-4d2b-b81b-5fc36a8d4949@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Add default implementation and elaborate API docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/a188df0b..f8a9f7a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=04-05

  Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From aph at openjdk.org  Fri Oct 24 12:28:16 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Oct 2025 12:28:16 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <DkPhrXwWHHptnQ50THfxKiJatf5-c7WOa67JW1IbXt8=.57054308-bfb9-4161-b476-cb2fd700d0e4@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
 <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>
 <DkPhrXwWHHptnQ50THfxKiJatf5-c7WOa67JW1IbXt8=.57054308-bfb9-4161-b476-cb2fd700d0e4@github.com>
Message-ID: <InCQThI0WDqMUyk9_be7xVI4b_01G-fqVF1kmL87fFQ=.da75341f-01b4-4330-bcf3-2f2ead79fe29@github.com>

On Fri, 24 Oct 2025 11:24:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 
> I agree. Its not pretty, but consistent with what we did elsewhere. Nobody wants to do that discussion again.

Sorry, I was unaware of any previous discussion. I was suggesting a less impactful way to make the change, taking advantage of the recent adoption of C++17, which allows for cleaner code. But I won't stand in the way of consensus.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442865789

From duke at openjdk.org  Fri Oct 24 12:37:02 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:37:02 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix link for getProcessCpuTime

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/f8a9f7a3..08af7b51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From dzhang at openjdk.org  Fri Oct 24 12:46:22 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 24 Oct 2025 12:46:22 GMT
Subject: RFR: 8368722: Vector API intrinsics enabled wrongly on platforms
 without support for misaligned vector access [v10]
In-Reply-To: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
References: <fi2SqsdPFoxDgBYKtul7N03Y95w3ScIJQQQAGJ7o7N0=.081b8b23-74c7-43e2-9f27-e1ffd74d47bc@github.com>
Message-ID: <muESxgBjrp6Src1eotscbQV_RedAT6fBiw0YwC6eZYM=.c1da3a77-10a4-4127-add1-7a58e428823a@github.com>

> Hi,
> Can you help to review this patch? Thanks!
> 
> In `*VectorLoadStoreTests.java`,  `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses.
> 
> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations.
> 
> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization.
> 
> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests.
> 
> We can check the status of EnableVectorSupport as follows:
> 
> On k1
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [0.737s][info][compilation] EnableVectorSupport=false
> [0.738s][info][compilation] EnableVectorReboxing=false
> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false
> 
> On qemu
> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version
> [3.048s][info][compilation] EnableVectorSupport=true
> [3.050s][info][compilation] EnableVectorReboxing=true
> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true
> 
> 
> ### Test (fastdebug)
> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Overload detect_misaligned_vector_support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27506/files
  - new: https://git.openjdk.org/jdk/pull/27506/files/e1d857c5..05176092

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=08-09

  Stats: 28 lines in 2 files changed: 11 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506

PR: https://git.openjdk.org/jdk/pull/27506

From mbaesken at openjdk.org  Fri Oct 24 13:04:31 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 Oct 2025 13:04:31 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <ANy6Q1n6Ikl1tQe0nk2GnwcOejxGiilzGucj4Rm11Qc=.719d437d-028c-4f69-9b47-160624a83456@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
 <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>
 <PBoEGxOPlNQQIrRAlOU431MpwxPVlELp6yO9w3NVaj4=.c29168ff-870f-4b3d-a6f5-bec0bab955c4@github.com>
 <8w70YHXPApfQ_Hp1DJAQsijiUU0AXkm6ZgziOn3zj0I=.71b5defe-02e5-4d2b-930f-8d7615aacf88@github.com>
 <ANy6Q1n6Ikl1tQe0nk2GnwcOejxGiilzGucj4Rm11Qc=.719d437d-028c-4f69-9b47-160624a83456@github.com>
Message-ID: <ZhEytxzI5Iwf3HypzT7POkbmPsUSC8tV2JwXrefyVOw=.0eb36794-69ab-41a3-a052-6277416fd1fe@github.com>

On Wed, 22 Oct 2025 14:06:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?
> 
> Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

I created a draft PR  https://github.com/openjdk/jdk/pull/27976  to support enabling LTO on library level.
(and for testing enabled it for 2 libs)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3443050728

From mbaesken at openjdk.org  Fri Oct 24 13:10:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 Oct 2025 13:10:13 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <Em9_iP4mRlJUfxhV5tUOcWFTvmtb_OdAkJDyq3OIxdY=.f864f72c-ba5e-4a0d-80b0-9ba5a3521ed2@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters 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 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86057873...9d05cb8e

For Linux x86_64 / gcc 13 here are the sizes of the libs and debuginfos before (without) and WITH lto enabled on LIB level 

libfontmanager.debuginfo   54155720  =>  38059440
libfontmanager.so          1874776   =>  1194264
libfreetype.debuginfo      4143416   =>  3761080
libfreetype.so             742472    =>  778024


For the debug info one can see a good effect ;  but not always the lib size decreases, for libfreetype.so  it increases slightly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3443073093

From bulasevich at openjdk.org  Fri Oct 24 13:26:06 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 24 Oct 2025 13:26:06 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
 <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
 <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>
Message-ID: <LAaJOKIUZfH6pVF5J-g4M-8YHydNcOabkra7ScVE1Rk=.fbd1fa1e-dfc3-40bf-a5f9-f9f5c90cde36@github.com>

On Fri, 24 Oct 2025 07:39:56 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hi, tier1 runs clean on ARM32. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3443145056

From krk at openjdk.org  Fri Oct 24 13:28:06 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 13:28:06 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
Message-ID: <3TBGMF_qfIR57_Bl1fGxR7QqDBsJsyBnrSlE-umj82M=.773af9d2-1c94-4ac9-9b1c-720c4c012acb@github.com>

On Tue, 21 Oct 2025 16:31:48 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

Benchmark of `PrintAssembly` before/after PR, on a noisy intel laptop:


Benchmark 1: /ws/jdk/build/linux-x86_64-server-release/jdk-nocache/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
  Time (mean ? ?):     907.2 ms ? 118.1 ms    [User: 640.1 ms, System: 479.6 ms]
  Range (min ? max):   561.6 ms ? 1232.0 ms    100 runs


Warning: Ignoring non-zero exit code.
Benchmark 2: /ws/jdk/build/linux-x86_64-server-release/jdk-cache/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
  Time (mean ? ?):     820.5 ms ?  51.7 ms    [User: 571.2 ms, System: 433.6 ms]
  Range (min ? max):   615.9 ms ? 1003.5 ms    100 runs


With the new cache, PrintAssembly of just `java` command is ~80ms (~%11) faster, over 100 runs each.

Looking into the `TestDwarf` for benchmarking next.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27337#issuecomment-3443150589

From erikj at openjdk.org  Fri Oct 24 13:48:06 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Oct 2025 13:48:06 GMT
Subject: RFR: 8370064: Test runtime/NMT/CheckForProperDetailStackTrace.java
 fails on Windows when using stripped pdb files [v4]
In-Reply-To: <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
References: <2YWvx8tOSKAxGeVc__RPJF6_rTgdlhc0DGXI8cBgUs0=.bff71d67-4030-4880-ab2b-fa116f76a969@github.com>
 <ep-0zIlbZ3QKKeflTvgdIFe4g41LT13cMmxlrI-XoDg=.16da726b-02cc-4a1d-ba18-9d27ef3db493@github.com>
Message-ID: <CMLTg2Wy_wBZWMNpbYYb_l7cGwaLobx3cOYpTlTTVPE=.eb3c788d-1fdd-42be-bfd2-a42b9ae0548b@github.com>

On Fri, 24 Oct 2025 07:22:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using stripped and not full pdb files on WIndows, the test CheckForProperDetailStackTrace.java misses source information (but this is not surprise with those much smaller pdb files; so probably we should not rely on having the source info available).
>> error output is :
>> 
>> 
>> java.lang.RuntimeException: Expected source information missing from output
>> at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:145)
>> 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:1474)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust style nit

This test is only run on debug builds. In the discussion in https://github.com/openjdk/jdk/pull/24012 it was pointed out that `--with-external-symbols-in-bundles=public` was an option meant for distribution builds and developers would opt out of it for a reasonable developer experience. Given that, I think this would be quite a rare combination. Especially without https://github.com/openjdk/jdk/pull/24012 since we are currently replacing the stripped PDB files in the image with the full ones anyway, for a local build-test, this test would work anyway. That said, I don't think this change hurts much either, given the rarity of the combination.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27899#issuecomment-3443241940

From fbredberg at openjdk.org  Fri Oct 24 13:49:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 13:49:09 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
Message-ID: <vDEwDKY6qM4s4TsjY_0xXTxqDgDvbrukiQelBuH1QdA=.43cb268a-e867-4cf4-a592-c9b671e4423a@github.com>

On Thu, 23 Oct 2025 17:29:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.cpp line 648:
> 
>> 646:       // stability and then install the hash.
>> 647:     } else {
>> 648:       assert(!mark.is_unlocked() && !mark.is_fast_locked(), "invariant");
> 
> Note that `mark.monitor()` below already asserts `mark.has_monitor()` which is stronger.

Good point, but I still like to keep the `assert()` on 648 for clarity. Would you rather see it removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460563344

From shade at openjdk.org  Fri Oct 24 13:49:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Oct 2025 13:49:11 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v6]
In-Reply-To: <NRaTDA6_nwxuMP-swgW-9j71c_rUYS4iqy1aj3-Qqjw=.a5997a99-a5db-4174-b73e-d31c8f8a2966@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <NRaTDA6_nwxuMP-swgW-9j71c_rUYS4iqy1aj3-Qqjw=.a5997a99-a5db-4174-b73e-d31c8f8a2966@github.com>
Message-ID: <B-EJHQAw9k-kXmlSa14jJU54IS-hFgVdg6TEjyo71BI=.db6cca39-408b-4d86-98a1-295275440951@github.com>

On Thu, 23 Oct 2025 08:44:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 15 additional commits since the last revision:
> 
>  - cc
>  - Merge branch 'master' into JDK-8369219
>  - nn
>  - update foundOne
>  - fix summary
>  - nn
>  - Merge branch 'master' into JDK-8369219
>  - trigger
>  - nn
>  - othervm
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8965993a...b6d94cf8

Looks reasonable, but the test needs a bit more work.

test/hotspot/jtreg/gc/NativeWrapperCollection/NativeWrapperCollection.java line 62:

> 60:         WB.enqueueMethodForCompilation(method, 1 /* compLevel */);
> 61:         while (WB.isMethodQueuedForCompilation(method)) {
> 62:             Thread.onSpinWait();

We are just waiting for compilation here. It is counter-productive to wait with a busy-loop. Insert a sleep for ~10...100ms instead. Same thing for the loop below.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27742#pullrequestreview-3376819734
PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2460528080

From fbredberg at openjdk.org  Fri Oct 24 13:55:03 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 13:55:03 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
Message-ID: <00xzxB3fxjSbmCZCQCu_ZEClnyxq2yfPfF-9SKJXoIc=.b45bec0f-164d-4604-87e2-d69ce072533b@github.com>

On Fri, 24 Oct 2025 11:10:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.cpp line 1454:
> 
>> 1452: // -----------------------------------------------------------------------------
>> 1453: // ConcurrentHashTable storing links from objects to ObjectMonitors
>> 1454: class ObjectMonitorTable : AllStatic {
> 
> I guess after looking at this, it made sense to combine the lightweightSynchronizer code into synchronizer.cpp (should be ObjectSynchronizer.hpp/cpp).  I wonder if the OM table code could be split out into its own file objectMontitorTable.hpp/cpp.  I feel like synchronzer.hpp/cpp again does too many different things.

Since we are currently investigating the OM table elseware (see: [JDK-8365493](https://bugs.openjdk.org/browse/JDK-8365493)) I wore for not doing any OM table refactoring in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460595360

From fbredberg at openjdk.org  Fri Oct 24 14:01:29 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:01:29 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
Message-ID: <Fwfv1pejLzs-l_qn0qS3yyqJUyxOwcLroA9ckX0iP-A=.0b224d30-a1d4-4ad0-82aa-edf453cf6e96@github.com>

On Fri, 24 Oct 2025 11:14:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.inline.hpp line 40:
> 
>> 38:     return read_monitor(mark);
>> 39:   } else {
>> 40:     return ObjectSynchronizer::get_monitor_from_table(current, obj);
> 
> I don't think there's a need for this file anymore.  read_monitor is mostly called inside synchronizer.cpp, so it can be inlined there.

Would you want me to do that in this PR? Or should I create a new RFE for that, just to acknowledge the fact that one should never say "last" cleanup. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460616703

From fandreuzzi at openjdk.org  Fri Oct 24 14:05:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 24 Oct 2025 14:05:04 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v7]
In-Reply-To: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
Message-ID: <dFhaeW-5xCHlEjeoQr1ICxjda0mD-xidbq7kCUKNZJM=.d28c84f5-85d1-412e-85e1-6249538667cc@github.com>

> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  sleep

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27742/files
  - new: https://git.openjdk.org/jdk/pull/27742/files/b6d94cf8..5d0c7056

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27742&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27742/head:pull/27742

PR: https://git.openjdk.org/jdk/pull/27742

From fandreuzzi at openjdk.org  Fri Oct 24 14:05:09 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 24 Oct 2025 14:05:09 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v6]
In-Reply-To: <B-EJHQAw9k-kXmlSa14jJU54IS-hFgVdg6TEjyo71BI=.db6cca39-408b-4d86-98a1-295275440951@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <NRaTDA6_nwxuMP-swgW-9j71c_rUYS4iqy1aj3-Qqjw=.a5997a99-a5db-4174-b73e-d31c8f8a2966@github.com>
 <B-EJHQAw9k-kXmlSa14jJU54IS-hFgVdg6TEjyo71BI=.db6cca39-408b-4d86-98a1-295275440951@github.com>
Message-ID: <ms0HiXwjvK9YHsCZ-4H2Tg6DGj69hdM0-flkrG1AhHY=.094b461d-2a84-4b1e-a1c9-f8e226f384a7@github.com>

On Fri, 24 Oct 2025 13:39:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi 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 15 additional commits since the last revision:
>> 
>>  - cc
>>  - Merge branch 'master' into JDK-8369219
>>  - nn
>>  - update foundOne
>>  - fix summary
>>  - nn
>>  - Merge branch 'master' into JDK-8369219
>>  - trigger
>>  - nn
>>  - othervm
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/4e995ea0...b6d94cf8
>
> test/hotspot/jtreg/gc/NativeWrapperCollection/NativeWrapperCollection.java line 62:
> 
>> 60:         WB.enqueueMethodForCompilation(method, 1 /* compLevel */);
>> 61:         while (WB.isMethodQueuedForCompilation(method)) {
>> 62:             Thread.onSpinWait();
> 
> We are just waiting for compilation here. It is counter-productive to wait with a busy-loop. Insert a sleep for ~10...100ms instead. Same thing for the loop below.

Thanks, that sounds reasonable. I got this pattern from another test, but it looks counterproductive here indeed.

5d0c70562614c5a3cd3391f5191bf60c5b51e82c

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2460634429

From fbredberg at openjdk.org  Fri Oct 24 14:20:36 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:20:36 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27915/files
  - new: https://git.openjdk.org/jdk/pull/27915/files/993d6137..6e331721

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=00-01

  Stats: 43 lines in 22 files changed: 4 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

PR: https://git.openjdk.org/jdk/pull/27915

From fbredberg at openjdk.org  Fri Oct 24 14:20:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:20:43 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
Message-ID: <613im2U7u_eH4USMM73aU46Gbm9-OxTe8EQmF43HOiE=.6930771f-c863-4036-8b2b-fe4eb352051f@github.com>

On Thu, 23 Oct 2025 17:07:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/oops/markWord.hpp line 215:
> 
>> 213:   ObjectMonitor* monitor() const {
>> 214:     assert(has_monitor(), "check");
>> 215:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");
> 
> Suggestion:
> 
>     assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

Fixed

> src/hotspot/share/oops/markWord.hpp line 241:
> 
>> 239:   }
>> 240:   static markWord encode(ObjectMonitor* monitor) {
>> 241:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");
> 
> Suggestion:
> 
>     assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 164:
> 
>> 162:   // Because of frequent access, the metadata field is at offset zero (0).
>> 163:   // Enforced by the assert() in metadata_addr().
>> 164:   // * Fast locking with UseObjectMonitorTable:
> 
> Suggestion:
> 
>   // * Locking with UseObjectMonitorTable:

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 166:
> 
>> 164:   // * Fast locking with UseObjectMonitorTable:
>> 165:   //   Contains the _object's hashCode.
>> 166:   // * * Fast locking without UseObjectMonitorTable:
> 
> Suggestion:
> 
>   // * Locking without UseObjectMonitorTable:

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 77:
> 
>> 75: 
>> 76: inline markWord ObjectMonitor::header() const {
>> 77:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");
> 
> Suggestion:
> 
>   assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 82:
> 
>> 80: 
>> 81: inline void ObjectMonitor::set_header(markWord hdr) {
>> 82:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");
> 
> Suggestion:
> 
>   assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 87:
> 
>> 85: 
>> 86: inline intptr_t ObjectMonitor::hash() const {
>> 87:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");
> 
> Suggestion:
> 
>   assert(UseObjectMonitorTable, "Only used by locking with OM table");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 92:
> 
>> 90: 
>> 91: inline void ObjectMonitor::set_hash(intptr_t hash) {
>> 92:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");
> 
> Suggestion:
> 
>   assert(UseObjectMonitorTable, "Only used by locking with OM table");

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460715777
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460716434
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460717622
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460718167
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460718815
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460719494
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460722858
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460721685

From coleenp at openjdk.org  Fri Oct 24 14:26:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 14:26:39 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v7]
In-Reply-To: <9IlDXdLcZSa3JCBBn9J8JUYWvlfKukDOlP1oqeTJRAQ=.6642ab0e-67ad-4776-b46c-acbee0136138@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <9IlDXdLcZSa3JCBBn9J8JUYWvlfKukDOlP1oqeTJRAQ=.6642ab0e-67ad-4776-b46c-acbee0136138@github.com>
Message-ID: <UlrXGXwXJ6a-Km8KCyxvevL1dwWslQUWjpJ9aCWFiEw=.1a014cde-93c0-4c2c-833a-f90f85bc9345@github.com>

On Thu, 23 Oct 2025 22:25:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - rename _monitor to _init_lock
>  - Extra comments from Coleen
>  - define methods in resolve_from_cache with TRAPS and use CHECK_AND_CLEAR_PREEMPTED

Almost done. Thank you for making suggested changes.

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 347:

> 345:   intptr_t* sp = enterSpecial.sp();
> 346: 
> 347:   sp[-1] = (intptr_t)StubRoutines::cont_preempt_stub();

push_cleanup_continuation sets sp[-2].  This doesn't have to set that?

src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 116:

> 114:   InterpreterOopMap mask;
> 115:   frame f = to_frame();
> 116:   f.interpreted_frame_oop_map(&mask);

There are two uses of this function left in continuationHelper.inline.hpp and continuationFreezeThaw.cpp under verification code.  Maybe they can be removed?  Do the places that call this in verification code still valid for preempted class initialization?  Do they need to count arguments now?

src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 220:

> 218:     intptr_t* sp = _top_frame.sp();
> 219:     if (sp != _last_sp_from_frame) {
> 220:       sp[-1] = (intptr_t)_top_frame.pc();

Same coment as aarch64, does this need to set sp[-2] to fp like above?  Or should it preserve the value?  Can you add a comment for each telling why?

src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 334:

> 332:   intptr_t* sp = enterSpecial.sp();
> 333: 
> 334:   sp[-1] = (intptr_t)StubRoutines::cont_preempt_stub();

Same here sp-2 ?

src/hotspot/share/runtime/frame.cpp line 951:

> 949:       //       code in the interpreter calls a blocking runtime
> 950:       //       routine which can cause this code to be executed).
> 951:       //       (was bug gri 7/27/98)

I like the refactoring of this condition.  It may be finally time to remove this line from 1998.  I, for one, will miss it but it doesn't really help anyone with anything.

test/jdk/java/lang/Thread/virtual/KlassInit.java line 63:

> 61:  * @library /test/lib
> 62:  * @requires vm.debug == true & vm.continuations
> 63:  * @run junit/othervm/timeout=480 -XX:+UnlockDiagnosticVMOptions -XX:+FullGCALot -XX:FullGCALotInterval=1000 -XX:CompileCommand=exclude,KlassInit::lambda$testReleaseAtKlassInit* -XX:CompileCommand=exclude,KlassInit$$Lambda*::run -XX:CompileCommand=exclude,KlassInit$1Driver::foo KlassInit

I think you can use multiple lines for the run command and not have to wrap like this.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3376098254
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460039130
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460624836
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460575662
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460577616
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460697549
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460721081

From coleenp at openjdk.org  Fri Oct 24 14:26:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 14:26:45 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v6]
In-Reply-To: <Vbxnh7q4CKHHzUpJHlGsMZdhUbr7032IItyqtx7sxlo=.41e3f7e2-5bb6-4450-8e80-aaf2a53008c0@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <o3hpKGrTsS6w4Szf9ag-bBuHgPPA5NRXPyHVMoXtwvI=.61e6c656-aa9c-4a29-8ae4-0450006f6910@github.com>
 <pzAYj8PlJPtfTlIjUq3sbK19IDg7gWPx4r3LaL19HqY=.7ea142b5-c866-4698-9c32-bb256d2cf262@github.com>
 <Vbxnh7q4CKHHzUpJHlGsMZdhUbr7032IItyqtx7sxlo=.41e3f7e2-5bb6-4450-8e80-aaf2a53008c0@github.com>
Message-ID: <vkatfEhymqjIr-DgYgTAbQv2Ql2rs7frv3ckk8CGeHU=.f2a40275-03ff-4e1f-ab55-37fa851dcdaa@github.com>

On Thu, 23 Oct 2025 22:26:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp line 73:
>> 
>>> 71:   bool update_map()    const { return false; }
>>> 72:   bool walk_cont()     const { return false; }
>>> 73:   bool include_argument_oops() const { return IncludeArgs; }
>> 
>> You made this a template rather than having an _include_argument_oops property for performance?
>
> Not really, using a bool member would work too.

ok, good to know.  We could or might not change it in the follow-up issue to move SmallRegisterMap to common code.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1123:
>> 
>>> 1121:       assert(!call.is_valid() || call.is_invokestatic(), "only invokestatic allowed");
>>> 1122:       if (call.is_invokestatic() && call.size_of_parameters() > 0) {
>>> 1123:         assert(top_frame.interpreter_frame_expression_stack_size() > 0, "should have parameters in exp stack");
>> 
>> The "this" pointer will be on the top of the interpreter frame expression stack right?  Are size of parameters ever 0 here then?
>
> This is only for `invokestatic` so no this pointer.

I see, this just verifies if size_of_parameters > 0, there must be something on the expression stack.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1653:
>> 
>>> 1651:   }
>>> 1652:   inline intptr_t* anchor_mark_set_pd();
>>> 1653:   inline void anchor_mark_clear_pd();
>> 
>> The code is really confused whether "pd" is the beginning of the method name or the end.  Both are used but mostly in the beginning of the method. The freeze/thaw code uses it at the end so this is okay.
>
> I added `patch_pd_unused` in 8359222 which should have been `patch_unused_pd`. :)

I like AnchorMark.  There are other places that clear_anchor in this code.  Can they use AnchorMark?

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1731:
>> 
>>> 1729:   int bci;
>>> 1730:   if (preempt_kind == Continuation::monitorenter) {
>>> 1731:     assert(top.is_interpreted_frame() || top.is_runtime_frame(), "");
>> 
>> So could you use precond() here since it's a precondition and you have no assert message?
>
> Yes, but don?t really see the benefit. It?s replacing a null string for `precond` in a crash.

These null strings make me wish we had an assert with no strings if one isn't provided.  I suppose the "precond" string isn't much better. I don't like null strings - it seems like you want to say why you're asserting this condition or what it means, ie take the opportunity to provide a bit more documentation.  Like here you could say that monitorenter is only preempted when the top frame is interpreted or runtime (which is coming from the compiler right?), which I suppose is redundant with the condition.  I suppose nothing is better than "sanity" or "should be".  I retract my suggestion to use precond though.  Others might believe it's better but I'm agnostic.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2686:
>> 
>>> 2684: 
>>> 2685:   {
>>> 2686:     HandleMarkCleaner hmc(current);  // Cleanup so._conth Handle
>> 
>> Why doesn't a plain HandleMark do this?
>> I think you chose HandleMarkCleaner because this is going to back to the interpreter code, so to be like JRT_ENTRY code.
>> So add something like before going back to the interpreted Java code.
>
> A full `HandleMark` works too. It?s just that there is already a `HandleMark` in the callstack (from the original upcall to Java from the carrier thread), so we can use a `HandleMarkCleaner` here.

The main place we have HandleMarkCleaners are in the JRT_ENTRY.  Can you change the comment to:
// Returning to java so cleanup all handles including so._conth Handle

or something like that.

>> src/hotspot/share/runtime/javaThread.hpp line 1372:
>> 
>>> 1370: };
>>> 1371: 
>>> 1372: class PreemptableInitCall {
>> 
>> If this is only used in instanceKlass.cpp, I think the definition should be there and not in javaThread.hpp.  It's not using private methds in javaThread.hpp as far as I can tell.
>
> Moved, and also `ThreadWaitingForClassInit`. Should I move pre-existent `ThreadInClassInitializer` too?

It's preexisting so I don't think so.  Leave it for a trivial change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460563120
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460632055
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460637514
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460668197
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460687828
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460751847

From coleenp at openjdk.org  Fri Oct 24 14:26:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 14:26:46 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <hygPsW_MVriCu6FN0nWedpQzfNFkCmJ86KVDnozs5PA=.14c0a785-7da4-4fd7-ab8c-5af687a53a4e@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
 <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com>
 <sw8sGdGhk15nI659oQfosmj4UpsfFAnHJ60Ya7KL1Us=.6174a78b-a5fd-4202-bca5-56f0b2c07cdc@github.com>
 <mhE2T_TNXsLA1EwiXQ4Athag4JAarRyRbll9wbEuJlY=.63115d8b-b71c-4e93-99b0-0b82d9896f74@github.com>
 <hygPsW_MVriCu6FN0nWedpQzfNFkCmJ86KVDnozs5PA=.14c0a785-7da4-4fd7-ab8c-5af687a53a4e@github.com>
Message-ID: <dRqrCEM9Qgbt3JWqL6gxF8HWvg3o3xvImQZ___TUUzE=.139bc83d-ce63-43f7-8c72-14ea212e992e@github.com>

On Thu, 23 Oct 2025 22:29:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Would an initialize_preemptable() = 0 be better?  then you can see if it's called by anything other than InstanceKlass.  Klass is always abstract.
>
> We can but we would have to implement it for `ArrayKlass` too which is kind of the same of what we have now. We have a `ShouldNotReachHere()` in `Klass::initialize_preemptable` (following the same pattern as `Klass::initialize`), so we will catch anything other than `InstanceKlass`.

I guess following the pattern is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460745900

From coleenp at openjdk.org  Fri Oct 24 14:26:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 14:26:49 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v3]
In-Reply-To: <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <pBLJ5k0XCoCf-frMIvBdU3uvHg076vZ8L9HUB9cG5IE=.c9644b05-95cd-401e-8476-9cbd7626facb@github.com>
 <gRzB-F3TSMop95ucCEfCvJMgKmXxLwx-YL-YdXnB72E=.65c421ca-3462-49a2-a9ea-db66fbf70c46@github.com>
Message-ID: <GFx25bWUPjy2k0UAb1R1wPiBGg9jc7arvDjVapdqhuE=.9ceb087f-e37d-432b-9c74-d703ae8e252b@github.com>

On Fri, 17 Oct 2025 06:33:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix verify_frame_kind
>
> src/hotspot/share/runtime/synchronizer.hpp line 230:
> 
>> 228:   bool    _skip_exit;
>> 229:  public:
>> 230:   ObjectLocker(Handle obj, TRAPS);
> 
> I wonder if we should declare `PREEMPTABLE_TRAPS` as an indicator that the only exception expected to come out of a call is the preempted-exception?

Not sure if I like that idea because then we might have to change other callers along the way for this new convention and everybody's already confused by TRAPS so then they'd be confused by a new TRAPS too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2460734436

From fbredberg at openjdk.org  Fri Oct 24 14:28:39 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:28:39 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>
Message-ID: <0fBkUHRtlrowvXXkSzerYvd5KrlwF-acFyH0af9mbXU=.0d75de36-208e-4582-80d4-c47537f6e385@github.com>

On Thu, 23 Oct 2025 12:06:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Thanks for cleaning this up on all platforms! Works on PPC64.
> Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

@TheRealMDoerr, @RealFYang 
> Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

Oops, my bad. Guess this what you end up with when you use `bash`, `grep -r` and `sed` to seek out and remove "lightweight" from a source tree, and then check the result using old Un*x style `diff -w`. I think all the faulty indentation stuff is fixed now, and yes I did check with "new" style `git diff` to see the surrounding lines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3443454592

From krk at openjdk.org  Fri Oct 24 14:30:58 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 14:30:58 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <tuFtvO3dhIln9LORocYeYdRiPNqm2m9a-A2hr08twEo=.3d6707bf-f4e6-49fa-a4fb-ab471f8628e3@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
 <tuFtvO3dhIln9LORocYeYdRiPNqm2m9a-A2hr08twEo=.3d6707bf-f4e6-49fa-a4fb-ab471f8628e3@github.com>
Message-ID: <tH8MOdCx6WQhWQ-f94eGnx6rOI84BxUzWS5D-OwXiag=.41291fc2-e8dd-4c21-98b0-cd981c3e435b@github.com>

On Wed, 22 Oct 2025 13:04:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Kerem Kat 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 elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - 8334866: Cache debug_aranges for faster address lookups
>
> src/hotspot/share/utilities/elfFile.hpp line 551:
> 
>> 549:     void sort() {
>> 550:       qsort(_entries, _count, sizeof(ArangesEntry), DwarfFile::ArangesCache::compare_aranges_entries);
>> 551:     }
> 
> [drive-by comment] Use of qsort is questionable.  See https://bugs.openjdk.org/browse/JDK-8248137

Using `QuickSort::sort` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2460772290

From krk at openjdk.org  Fri Oct 24 14:30:55 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 14:30:55 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <kEfiOlOm76_pzyA4H7WnGkfMED9MokXLMF7BCbbmGpI=.845b5f8e-2847-46d3-9f42-63a27ae0014e@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
 <kEfiOlOm76_pzyA4H7WnGkfMED9MokXLMF7BCbbmGpI=.845b5f8e-2847-46d3-9f42-63a27ae0014e@github.com>
Message-ID: <s_xTVwjRHWuPI7dtt5nyPI-5EUVX7zFFOBSh19gsBvI=.5918ff5a-ddd4-4e66-8189-32317ce3bd83@github.com>

On Wed, 22 Oct 2025 11:34:36 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Kerem Kat 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 elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>>  - 8334866: Cache debug_aranges for faster address lookups
>
> src/hotspot/share/utilities/elfFile.hpp line 533:
> 
>> 531: 
>> 532:     ArangesCache() : _entries(nullptr), _count(0), _capacity(0), _initialized(false), _failed(false) {}
>> 533:     ArangesCache(ArangesCache&& other) : _entries(other._entries), _count(other._count), _capacity(other._capacity),
> 
> According to the style guide, move constructors/semantics is a feature we are undecided about and we should currently refrain from using them until a consensus is reached: [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#additional-undecided-features).

Removed move ctor, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2460771182

From krk at openjdk.org  Fri Oct 24 14:30:50 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 14:30:50 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <2IkRmoeJcGaNyBHHp-6EOyJ_4BKYcWvNJz2yMK5VNNY=.853df936-aa0c-463a-9ae8-dd760bd1213f@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
 <Nex6TqrMadaKDC4paS-S55uE-wQqy01Mo9NbYa0h1_k=.b252a623-f1c8-472d-985b-7838f842de79@github.com>
 <2IkRmoeJcGaNyBHHp-6EOyJ_4BKYcWvNJz2yMK5VNNY=.853df936-aa0c-463a-9ae8-dd760bd1213f@github.com>
Message-ID: <c2kqvY0waCyuiagBGoXDy9eyDiEcMsZvZS53Yn4GeW8=.ad5799ff-9936-472c-bf3f-e5d3994612d0@github.com>

On Wed, 22 Oct 2025 11:26:05 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> src/hotspot/share/utilities/elfFile.cpp line 695:
>> 
>>> 693:   } else {
>>> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());
>>> 695:     DebugAranges debug_aranges(this);
>> 
>> This honestly looks like we want to pull `DebugAranges` up to be a permanent member of `DwarfFIle`, and put the cache there? This would also resolve fairly awkward passing `ArangeCache&` around, since `DebugAranges` itself would do most of the heavy-lifting, including managing its own (internal) cache. Is there anything in the way of doing so?
>
> I was about to ask the same. Since we have an easy caching mechanism and `.debug_aranges` does not change, we could hide the cache inside `DebugAranges`. Then from the `DwarfFile` point of view, it does not need to care about how the queries to `DebugAranges` are actually answered and we have a better separation of concerns.

Thanks, makes it simpler. I am moving them around.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2460767815

From shade at openjdk.org  Fri Oct 24 14:31:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Oct 2025 14:31:50 GMT
Subject: RFR: 8369219: JNI::RegisterNatives causes a memory leak in
 CodeCache [v7]
In-Reply-To: <dFhaeW-5xCHlEjeoQr1ICxjda0mD-xidbq7kCUKNZJM=.d28c84f5-85d1-412e-85e1-6249538667cc@github.com>
References: <QvRxMyRJyewBI4267I-9hXS9q5Qq652moUcbwOGr72k=.8bce6a28-1d00-4b5e-8969-e8240896c73f@github.com>
 <dFhaeW-5xCHlEjeoQr1ICxjda0mD-xidbq7kCUKNZJM=.d28c84f5-85d1-412e-85e1-6249538667cc@github.com>
Message-ID: <xV1pBmwDuEggehZz_4GZ1wEMXFArld42Xq91MUfbTAU=.27a8a618-c17a-45b5-b97d-66a5c839b798@github.com>

On Fri, 24 Oct 2025 14:05:04 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I propose to amend `nmethod::is_cold` to let GC collect not-entrant native `nmethod` instances.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sleep

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27742#pullrequestreview-3377171194

From kbarrett at openjdk.org  Fri Oct 24 15:00:36 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 24 Oct 2025 15:00:36 GMT
Subject: RFR: 8367013: Add Atomic<T> to package/replace idiom of volatile
 var plus AtomicAccess:: operations [v5]
In-Reply-To: <J-PHiQjLtis-QsjY6YmB_VAmjcUOhR6KUu9v4ctPv4U=.3dfe6830-0842-4f9a-8e8f-260cb98e6c95@github.com>
References: <zJnEkRh0wbDPCKm3TIutdn76UZuTdnXZTCJDKiWLS8k=.a5842a39-7c44-4305-beee-3ad00bcc320c@github.com>
 <SKYGVmwaS3VsML1ZFu873I_Fx-OnTqWAO7CHvW83tNQ=.03e17b94-e77e-4853-8c0f-cb6125c9a905@github.com>
 <a2OcqwMlma2xPQ2AnnDvgMZna4wwbLr3cegus0c-a9g=.bebf79dc-674b-492c-8119-eeac4fd0f51e@github.com>
 <cEQjUolOt1oAoqDES9lhH6z7lYar9kdUr1fLsDxxzwE=.fb849e0d-ffde-47ed-a6aa-492f602e59a8@github.com>
 <J-PHiQjLtis-QsjY6YmB_VAmjcUOhR6KUu9v4ctPv4U=.3dfe6830-0842-4f9a-8e8f-260cb98e6c95@github.com>
Message-ID: <aaA9eR_2EiqqzYeYrFBcBrMVdzQ5cvine0hr_DPgdrg=.9e4af6be-b75f-4021-b5bf-e5701051a515@github.com>

On Wed, 22 Oct 2025 14:22:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > So in the following code snippet neither `Atomic<EnumClass16>` nor `Atomic<uint16_t>` can be compiled.
> > 
> > 
> > It seems like this is expected by the implementation (only allow Integer 32/64, or Byte 8). But it is unexpected for me that `Atomic<T>` does not support these types while AtomicAccess does. At least for loads and stores. (Or is that not true on all platforms)
> 
> I don't think `AtomicAccess` supports 16bit accesses on any platform. 

I intended to say that `AtomicAccess` doesn't support 16 bit RMW operations on any platform.
It does support load/store on at least some platforms, but that may be because it would take effort to not do so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3443605135

From iklam at openjdk.org  Fri Oct 24 15:26:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Oct 2025 15:26:05 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <aLTAdjn02kZOB7Ft87RfqHhXW7niPmc128m3GvtuIWw=.702cec0c-9aeb-401a-92ca-26625857321d@github.com>

On Thu, 23 Oct 2025 18:56:44 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
> 
> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
> 
> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
> 
> 
> After this PR:
> 
> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0

Other than the zero build failures, all other tests passed in our CI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27958#issuecomment-3443706436

From alanb at openjdk.org  Fri Oct 24 15:32:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Oct 2025 15:32:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <ZMiU3uHab3Jhk8YAuMkt2ukJpDzyo4xpkvfFUtduKEA=.45ea1821-d663-4dae-8139-682960aeb4a7@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 274:

> 272:      * spent in garbage collection.
> 273:      *
> 274:      * <p> This is the CPU time used by all garbage collection

Starting this paragraph with "This is the CPU time ..." is a bit awkward. Can you try "The time spent in spent in garbage collection (GC) is the CPU time ...".

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 289:

> 287:      * in garbage collection is highly implementation dependent.
> 288:      * In the HotSpot Virtual Machine implementation reported
> 289:      * time will include relevant implementation-specific details such

"In the HotSpot Virtual Machine implementation reported time will include".  A suggestion to improve this is to change it to "In the HotSpot Virtual Machine, this time includes.."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461014442
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461027518

From krk at openjdk.org  Fri Oct 24 17:17:07 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 17:17:07 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v4]
In-Reply-To: <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <es7n-uCE1nb3H8wq-6PFQW0wgbJ65UeUFWoXMI9hfww=.948775d0-cf5b-479d-8ed5-cc5cfc435215@github.com>
Message-ID: <mI2MotMoYQ-OjIDJ57HGZk8UeVkRh-GT8nOyq87jsGw=.70770536-6349-4795-a85c-ed951958995a@github.com>

On Tue, 21 Oct 2025 16:31:48 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

Benchmarking an arbitrary test from `TestDwarf.java`, on a noisy laptop:


hyperfine -i -N --warmup=1 -r 10 -L JDK build/fastdebug-no-cache/jdk,build/fastdebug-cache/jdk '{JDK}/bin/java -cp /ws/jdk/JTwork/classes/0/runtime/ErrorHandling/TestDwarf.d:/ws/jdk/test/hotspot/jtreg/runtime/ErrorHandling:/ws/jdk/test/hotspot/jtreg:/ws/jdk/JTwork/classes/0/runtime/ErrorHandling/TestDwarf.d/test/lib:/ws/jdk/test/lib:/ws/jtreg/jtreg/build/images/jtreg/lib/javatest.jar:/ws/jtreg/jtreg/build/images/jtreg/lib/jtreg.jar -XX:TraceDwarfLevel=2 -XX:+CrashGCForDumpingJavaThread --version'
Benchmark 1: <fastdebug-no-cache>
  Time (mean ? ?):      2.232 s ?  0.051 s    [User: 2.652 s, System: 0.208 s]
  Range (min ? max):    2.184 s ?  2.345 s    10 runs

  Warning: Ignoring non-zero exit code.

Benchmark 2: <fastdebug-cache>
  Time (mean ? ?):      2.196 s ?  0.021 s    [User: 2.650 s, System: 0.201 s]
  Range (min ? max):    2.160 s ?  2.236 s    10 runs

  Warning: Ignoring non-zero exit code.

Summary
  <fastdebug-cache> ran
    1.02 ? 0.03 times faster than <fastdebug-no-cache>


The test finishes ~35 ms faster with cache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27337#issuecomment-3444146503

From krk at openjdk.org  Fri Oct 24 17:30:40 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 17:30:40 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v5]
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <V93aFFbFdV_BBUthtt6S-NRttu_Rk6JZFRYotuf5PMg=.5acae4b3-dd60-4527-bb22-f5c7ed9e4ac8@github.com>

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat 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 15 additional commits since the last revision:

 - Merge branch 'master' into elfdecoder-JDK-8334866
 - fix DWARF_LOG_INFO
 - Comment on ArangesCache
 - Fix secondary sort order and comment
 - Remove move ctor of ArangesCache
 - Clarify when we can fallback to linear scan, which doesn't seem to allocate on the heap
 - Move ArangesCache into DebugAranges, and DebugAranges into DwarfFile
 - inline sort
 - goto considered harmful
 - Use QuickSort::sort instead of qsort
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9c486911...ae72cae8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/623870ee..ae72cae8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=03-04

  Stats: 12293 lines in 221 files changed: 7778 ins; 3047 del; 1468 mod
  Patch: https://git.openjdk.org/jdk/pull/27337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337

PR: https://git.openjdk.org/jdk/pull/27337

From krk at openjdk.org  Fri Oct 24 17:30:41 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 17:30:41 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v5]
In-Reply-To: <V93aFFbFdV_BBUthtt6S-NRttu_Rk6JZFRYotuf5PMg=.5acae4b3-dd60-4527-bb22-f5c7ed9e4ac8@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <V93aFFbFdV_BBUthtt6S-NRttu_Rk6JZFRYotuf5PMg=.5acae4b3-dd60-4527-bb22-f5c7ed9e4ac8@github.com>
Message-ID: <bfOj9zoP3uZ8IYn0-WyyMH8khA_7-1SK9nLaG3rMoWg=.6fdea7c6-de63-48bd-a1be-04b4035a2dec@github.com>

On Fri, 24 Oct 2025 17:27:45 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into elfdecoder-JDK-8334866
>  - fix DWARF_LOG_INFO
>  - Comment on ArangesCache
>  - Fix secondary sort order and comment
>  - Remove move ctor of ArangesCache
>  - Clarify when we can fallback to linear scan, which doesn't seem to allocate on the heap
>  - Move ArangesCache into DebugAranges, and DebugAranges into DwarfFile
>  - inline sort
>  - goto considered harmful
>  - Use QuickSort::sort instead of qsort
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/9c486911...ae72cae8

src/hotspot/share/utilities/elfFile.cpp line 818:

> 816:     case CacheHint::VALID:
> 817:       return _cache.find_compilation_unit_offset(offset_in_library, compilation_unit_offset);
> 818:     case CacheHint::TRY_LINEAR_SCAN:

Should we eliminate the fallback?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2461372847

From krk at openjdk.org  Fri Oct 24 17:38:35 2025
From: krk at openjdk.org (Kerem Kat)
Date: Fri, 24 Oct 2025 17:38:35 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v6]
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <S4v3QZ_RWkRh8HAGmaZWmfJYYGhqJ33PjyGKFyFaoVI=.74365ec6-8788-4dd9-95a6-676d13e5aece@github.com>

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments, delete copy ctor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/ae72cae8..316f6316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=04-05

  Stats: 7 lines in 2 files changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337

PR: https://git.openjdk.org/jdk/pull/27337

From asmehra at openjdk.org  Fri Oct 24 18:18:20 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 24 Oct 2025 18:18:20 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <aLTAdjn02kZOB7Ft87RfqHhXW7niPmc128m3GvtuIWw=.702cec0c-9aeb-401a-92ca-26625857321d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
 <aLTAdjn02kZOB7Ft87RfqHhXW7niPmc128m3GvtuIWw=.702cec0c-9aeb-401a-92ca-26625857321d@github.com>
Message-ID: <LVfvXr2zIP5dPGGU2rQZzwT0uRW-7mHi6o7reHDsbW8=.c9d6a4c5-a801-4158-8f6d-4e153b3e695b@github.com>

On Fri, 24 Oct 2025 15:22:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
>> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
>> 
>> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
>> 
>> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
>> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
>> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
>> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
>> 
>> 
>> After this PR:
>> 
>> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
>> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
>> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
>> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0
>
> Other than the zero build failures, all other tests passed in our CI.

@iklam Zero does not support fast class init checks, so the CP entries for static bytecodes should not be resolved. I have pushed changes to do that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27958#issuecomment-3444341472

From asmehra at openjdk.org  Fri Oct 24 18:18:18 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 24 Oct 2025 18:18:18 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time [v2]
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <k3b1zVOp6Jl-g6srtdQ_n_s_GJ32tZb2EuhCFdU7c-A=.628d9c40-26e3-4322-9454-ba7ceee0d33d@github.com>

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
> 
> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
> 
> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
> 
> 
> After this PR:
> 
> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0

Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:

 - Do not resolve getstatic/putstatic CP entry if VM_Version::supports_fast_class_init_checks() is false
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Do not resolve invokestatic CP entry if
   VM_Version::supports_fast_class_init_checks() is false
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27958/files
  - new: https://git.openjdk.org/jdk/pull/27958/files/cb581318..5994ead4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27958&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27958&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27958/head:pull/27958

PR: https://git.openjdk.org/jdk/pull/27958

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v8]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/08af7b51..5d360f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06-07

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <tmLI6jE_Wa1z0p5h5CYHSoOA1So-SR0Q4A6vD2n3Tvk=.e3d1e614-9d7f-42d7-9f89-9c55d3cc016f@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

Thanks for the feedback. I addressed the above and ensured consistent usage of GC throughout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3444369903

From duke at openjdk.org  Fri Oct 24 18:34:34 2025
From: duke at openjdk.org (Harshit470250)
Date: Fri, 24 Oct 2025 18:34:34 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations
Message-ID: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>

This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.

-------------

Commit messages:
 - update make_barrier_type
 - Merge branch 'openjdk:master' into new_pr
 - Merge branch 'openjdk:master' into new_pr
 - My chages

Changes: https://git.openjdk.org/jdk/pull/27279/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347396
  Stats: 146 lines in 4 files changed: 100 ins; 42 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27279/head:pull/27279

PR: https://git.openjdk.org/jdk/pull/27279

From asmehra at openjdk.org  Fri Oct 24 18:39:19 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 24 Oct 2025 18:39:19 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time [v3]
In-Reply-To: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
Message-ID: <Go7anF5AdVzbX0NMdehvV4e81FCMOX2QcVbhlvaVX0I=.e27e7d01-a3ab-4aff-a3e7-da8a19a91774@github.com>

> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
> 
> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
> 
> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
> 
> 
> After this PR:
> 
> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Move check for VM_Version::supports_fast_class_init_checks() to
  remove_resolved_method_entries_if_non_deterministic()
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27958/files
  - new: https://git.openjdk.org/jdk/pull/27958/files/5994ead4..61e5653d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27958&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27958&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27958/head:pull/27958

PR: https://git.openjdk.org/jdk/pull/27958

From asmehra at openjdk.org  Fri Oct 24 18:39:20 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 24 Oct 2025 18:39:20 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time
In-Reply-To: <aLTAdjn02kZOB7Ft87RfqHhXW7niPmc128m3GvtuIWw=.702cec0c-9aeb-401a-92ca-26625857321d@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
 <aLTAdjn02kZOB7Ft87RfqHhXW7niPmc128m3GvtuIWw=.702cec0c-9aeb-401a-92ca-26625857321d@github.com>
Message-ID: <XrJhOaKKLoColYll4pqav-MnMHwflbX-LgPMnahLpes=.aa0aca9b-d081-46a1-81b2-81d5ee89e9c4@github.com>

On Fri, 24 Oct 2025 15:22:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
>> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
>> 
>> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
>> 
>> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
>> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
>> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
>> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
>> 
>> 
>> After this PR:
>> 
>> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
>> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
>> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
>> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0
>
> Other than the zero build failures, all other tests passed in our CI.

@iklam can you please review the new changes. With this update zero config builds fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27958#issuecomment-3444412845

From eosterlund at openjdk.org  Fri Oct 24 20:11:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 24 Oct 2025 20:11:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v10]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Missing unlock diagnostic VM options, and remove unintended comment
 - Fix for minimal
 - Change streaming/mapping states to be binary instead of tri states
 - Clean up VMProps
 - Make AOTStreamableObjects diagnostic
 - Test polishing
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Test fix
 - move exception marks outside locks
 - ... and 12 more: https://git.openjdk.org/jdk/compare/97e5ac6e...3d771ca2

-------------

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=09
  Stats: 8737 lines in 111 files changed: 5928 ins; 2349 del; 460 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From dlong at openjdk.org  Sat Oct 25 02:43:05 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Oct 2025 02:43:05 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v2]
In-Reply-To: <FfKkoLkqvJr_jBUM5XyHumRi4t8MEoI6E0trF8cX5ks=.2120f2d8-a5b9-4621-a126-d999011bc206@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <bU0gf-Ta795JwaJvDGhJDQj8pnzHo6HKR9efUpdAYaM=.098f0a2a-f713-49d7-9367-8db78ddbc35c@github.com>
 <XF5SX-T1nEDC9RiJ3qwvw_2iGLhFbX75b3A3Hswglzg=.cedaab94-b09a-4273-bd07-65b41aa2f014@github.com>
 <FfKkoLkqvJr_jBUM5XyHumRi4t8MEoI6E0trF8cX5ks=.2120f2d8-a5b9-4621-a126-d999011bc206@github.com>
Message-ID: <i5pDBSa4Wcqh2_3OwzQzA8ajQJSpO6DLFydwBm5WuLI=.fb9bb148-0274-4191-9a6a-d05edb104582@github.com>

On Thu, 16 Oct 2025 16:23:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209:
>> 
>>> 207:     // the last_sp saved in the frame (remove possible alignment added while
>>> 208:     // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp
>>> 209:     // saved in the frame as it is not expected to be set in case we preempt again.
>> 
>> A bit stronger?
>> Suggestion:
>> 
>>     // saved in the frame because it must be clear if we freeze again.
>
> Just to add more context, not clearing last_sp will make this assert [1] fire if we freeze again. That assert is mostly a verification check, because we know the interpreter doesn?t set last_sp for the top frame when calling into the VM. But I don?t see a fundamental reason why it must be cleared (removing the assert and not clearing last_sp works). I don?t see any other code that checks last_sp needs to be cleared for the top frame (other than in the interpreter before calling into the VM).
> How about changing that last sentence with: `We also clear last_sp to match the behavior when calling the VM from the interpreter (we check for this in FreezeBase::prepare_freeze_interpreted_top_frame).`
> 
> [1] https://github.com/openjdk/jdk/blob/87092ef1d97e00ddb6674b0e309f2f904d307604/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L136

FWIW, interpreter_frame_tos_address() behaves differently depending on if last_sp() is cleared or not.  I know deoptimization sets last_sp temporarily but makes sure to clear it before giving control back to the interpreter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2462366413

From duke at openjdk.org  Sat Oct 25 02:53:01 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:01 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v13]
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <QBwjoRxK6LU0NYy3le6TAPBxXOQ3wd3Cd2AYVzLMq6w=.65496765-65ef-471b-ac18-7cdd8d6c72b9@github.com>

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Update ExchangeImpl.java
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - Create UpgradeOutputStream.java
 - close raw streams
 - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184

-------------

Changes: https://git.openjdk.org/jdk/pull/27751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12
  Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod
  Patch: https://git.openjdk.org/jdk/pull/27751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751

PR: https://git.openjdk.org/jdk/pull/27751

From duke at openjdk.org  Sat Oct 25 02:53:02 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:02 GMT
Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <xzMm3alltKr_uQFUr-WnPiY0p0n-oXxvx0JY9OcrdHc=.8e9e00b5-731a-41e4-9fe2-68bca97f4413@github.com>

On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel <duke at openjdk.org> wrote:

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27751

From iklam at openjdk.org  Sat Oct 25 05:02:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 25 Oct 2025 05:02:06 GMT
Subject: RFR: 8334898: Resolve static field/method references at CDS dump
 time [v3]
In-Reply-To: <Go7anF5AdVzbX0NMdehvV4e81FCMOX2QcVbhlvaVX0I=.e27e7d01-a3ab-4aff-a3e7-da8a19a91774@github.com>
References: <ruZwp3wmACI2qFGEG0QFL4RmoHo--wJ7fXklNxk9HLg=.c9e3f068-df58-420d-bcaf-b03040800d8d@github.com>
 <Go7anF5AdVzbX0NMdehvV4e81FCMOX2QcVbhlvaVX0I=.e27e7d01-a3ab-4aff-a3e7-da8a19a91774@github.com>
Message-ID: <fm2PyNM3xARxc7TxXG3FNWniGbuOnimNnkEYb7iBAws=.7269114c-a6cc-4bef-9b7a-ca0c16892a17@github.com>

On Fri, 24 Oct 2025 18:39:19 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch pre-resolves constant pool entries referred by getstatic, putstatic and invokestatic bytecodes in the assembly phase.
>> It also extends ResolvedConstants.java test to run in AOT mode workflow and additional test for checking resolution of static CP entries.
>> 
>> Before this PR, stats on pre-resolved CP entries in the assembly phase reported by -Xlog:aot=info:
>> 
>> [2.161s][info ][aot        ] Class  CP entries =  12553, archived =   3707 ( 29.5%), reverted =      0
>> [2.161s][info ][aot        ] Field  CP entries =   5236, archived =   1355 ( 25.9%), reverted =      0
>> [2.161s][info ][aot        ] Method CP entries =   3835, archived =   3818 ( 99.6%), reverted =     17
>> [2.161s][info ][aot        ] Indy   CP entries =      9, archived =      9 (100.0%), reverted =      0
>> 
>> 
>> After this PR:
>> 
>> 2.323s][info ][aot        ] Class  CP entries =  12553, archived =   3700 ( 29.5%), reverted =      0
>> [2.323s][info ][aot        ] Field  CP entries =   5236, archived =   3519 ( 67.2%), reverted =      0
>> [2.323s][info ][aot        ] Method CP entries =  21027, archived =   5527 ( 26.3%), reverted =     17
>> [2.323s][info ][aot        ] Indy   CP entries =    353, archived =      9 (  2.5%), reverted =      0
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move check for VM_Version::supports_fast_class_init_checks() to
>   remove_resolved_method_entries_if_non_deterministic()
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Update looks good!

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27958#pullrequestreview-3379686999

From pikolasikolatest5 at gmail.com  Sat Oct 25 17:58:59 2025
From: pikolasikolatest5 at gmail.com (Chihab chger)
Date: Sat, 25 Oct 2025 19:58:59 +0200
Subject: =?UTF-8?B?2LTZh9in2K/YqSDYp9mE2KPYqNmI2Kkg2YHZiiDYp9mE2YXYutix2Kg=?=
Message-ID: <CAHtTZ=m_jUmoKUXLqNAYK1BZvzEKUr4P8YmPvZFbDaRonLzMwQ@mail.gmail.com>

????? ?????? ?? ??????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251025/f7c2f880/attachment-0001.htm>

From pikolasikolatest5 at gmail.com  Sat Oct 25 17:59:53 2025
From: pikolasikolatest5 at gmail.com (Chihab chger)
Date: Sat, 25 Oct 2025 19:59:53 +0200
Subject: =?UTF-8?B?2KfZhti22YUg2KfZhNii2YYg2KXZhNmJINit2LPYp9ioIENhbnZhIFBybyDZhdis2KfZhg==?=
 =?UTF-8?B?2YvYpw==?=
Message-ID: <CAHtTZ=kwS6g-onSirbTyrMvbpx=xK1RZiF7axKs9SH_9bbhcMg@mail.gmail.com>

???? ???? ??? ???? Canva Pro ?????? ??? ???? ?????? ?????? ???????? ???????
?? 2025? ?????? ?? ???? ??????? ???????? ??? ?? ?????. ?? ??? ?????? ????
?? ????? ?????? ??? ???? ?????? ????? Canva Pro Edu? ??? ???? ????? ??
???????? ??????? ???????? ??????? ???????.
https://www.targir.com/2025/02/canva-pro.html
?? ?? Canva Pro?
Canva ???? ????? ?????? ??????? ???? ????? ???? ???????? ??????? ???????
????????? ???????? ???? ??? ??????. ?????? ??????? ???? ????? ??????
??????? ????? ???? Canva Pro ????? ???? ?? ????? ???????????? ?????
???????? ??? ????? ???????? ?????? ????? ???? ?????.

????? ????????

?????? ???????: ???? ?????? ????? ??????? ???? ??????? ??????? ?? 5 ????
?????. ????? ?????????.

Canva Pro: ????? ???? ???? ?? 100 ????? ????? ????? ??????? 1 ????????
?????? ?????? ??? ????? ?????? ???????.

Canva Teams: ???? ????????? ?? ????? ????? ???? ?????? ??????? ????????.

Canva Pro Edu: ????? ???????? ???????? ????? ??? ???? ????? Canva Pro
???????? ??? ????? ???????.

??? ???? ??? Canva Pro Edu ???????
? ??????? ??? ???? ???? ???? ??? ????????.
? ????? ???? ???? ?? ??????? ????? ???????? ?? ????.
? ??? ???? ??????? ????? ????? ???????? ??? Canva Pro Edu ????? ?????
???????.

???? ????? ????????
? ?? ???? ?????? ?? ?????? ?????? ???????.
? ???? ???????? ????? ???????? (??? edu).
? ???????? ??? ???? ???? ???.

?? ???? ?????? ??? Canva Pro ???? ?????
???? ???? ???? ??????? ?????? ???? 30 ????? ????? ?????? ??? ?????? ??????.
???? ??? ?????? ?????? ????? ???????? ?????? ????? ???????? ??? ????????
????? ??????. ??? ?????? ??? Canva Pro ???? ?????? ???? ????? ???? ???? ???
??? ?????? ?????????.

??? ??????? ???? ?????? Canva Pro Edu ??????
? ????? ??? ???? ?? 100 ????? ???? ????? ?????????.
? ???? ?? 600 ??? ???? ???????.
? ????? ?????? ??? ????? ??????? ?????? ?????? ????????.
? ????? ????? 1 ????????.
? ??????? ????? ??????? ?? ?????? ???????? ??? ?????? ??????.

????? ????? Canva Pro Edu?
??? ?????? ????? ???? ????? Canva Pro ??? ?????? ??? ????? ???????? ??????
???? ???????? ??????? ?????? ?????? ????? ????????. ?????? ??? ??? ????
?????? ????? ????? ???? ????? ?????????.

?????
??? ??? ?????? ?? ??????? ??? ???? ????? ?????? ??? Canva Pro ?????? ?? ???
???? ?????? ??? Canva Pro Edu. ???? ?????? ????? ?? ???? ??????? ???????
??? ?? ????. ???? ???? ?????? ?? ???? ????? ???? ?? ????? ??????? ?????????
????????? ??????? ??? ????? ??????? ???????? Canva Pro Edu ?? 2025.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251025/4a76753d/attachment.htm>

From lmesnik at openjdk.org  Sat Oct 25 18:13:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:13:44 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
 [v2]
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <_dZqCSMdfrPcIOp7gcq08L9Mfk7p_GXOAD2oay0xbm4=.50fe9fc9-1411-4879-9e17-84b679dc0cd4@github.com>

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Leonid Mesnik 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 23 additional commits since the last revision:

 - fixed comments
 - fixed comments
 - cleanup
 - The global flag implemented
 - the post compiled method updated
 - added antoher transition
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8355631
 - better sync
 - restore eventmark
 - Revert "removed unused field"
   
   This reverts commit 379991eca4e54e1990ba2ade3d9a5c53d1f3657c.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/c205be47...35b7c647

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27504/files
  - new: https://git.openjdk.org/jdk/pull/27504/files/b71ee9b9..35b7c647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=00-01

  Stats: 163338 lines in 1904 files changed: 135305 ins; 18271 del; 9762 mod
  Patch: https://git.openjdk.org/jdk/pull/27504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504

PR: https://git.openjdk.org/jdk/pull/27504

From lmesnik at openjdk.org  Sat Oct 25 18:13:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:13:44 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <bqrlt7PbRSSb2OO6Wk4ZIqq8oJkHg9fTwtmg-Nw5taA=.571b3370-d76c-4319-9d95-11d2bfff40fa@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

I updated the fix and description to synchronize events posting during VM shutdown.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3446990469

From lmesnik at openjdk.org  Sat Oct 25 18:27:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:27:39 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
 [v3]
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <E0UEu0wiBicncqTfTSKk1iqJSNG6Ojg0hCXyC9L3ZNs=.925f9c73-3944-4c0d-aeca-1f87637484a6@github.com>

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27504/files
  - new: https://git.openjdk.org/jdk/pull/27504/files/35b7c647..405d5a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=01-02

  Stats: 14 lines in 3 files changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504

PR: https://git.openjdk.org/jdk/pull/27504

From davidalayachew at gmail.com  Sat Oct 25 22:41:47 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 25 Oct 2025 18:41:47 -0400
Subject: =?UTF-8?B?UmU6INin2YbYttmFINin2YTYotmGINil2YTZiSDYrdiz2KfYqCBDYW52YSBQcm8g2YXYrA==?=
 =?UTF-8?B?2KfZhtmL2Kc=?=
In-Reply-To: <CAHtTZ=kwS6g-onSirbTyrMvbpx=xK1RZiF7axKs9SH_9bbhcMg@mail.gmail.com>
References: <CAHtTZ=kwS6g-onSirbTyrMvbpx=xK1RZiF7axKs9SH_9bbhcMg@mail.gmail.com>
Message-ID: <CAA9v-_MTUAqBg=k5J-B3b7DwFXg-dJMoC6pezrAWq-ucM08W8g@mail.gmail.com>

Advertisement.

On Sat, Oct 25, 2025 at 2:00?PM Chihab chger <pikolasikolatest5 at gmail.com>
wrote:

> ???? ???? ??? ???? Canva Pro ?????? ??? ???? ?????? ?????? ????????
> ??????? ?? 2025? ?????? ?? ???? ??????? ???????? ??? ?? ?????. ?? ???
> ?????? ???? ?? ????? ?????? ??? ???? ?????? ????? Canva Pro Edu? ??? ????
> ????? ?? ???????? ??????? ???????? ??????? ???????.
> https://www.targir.com/2025/02/canva-pro.html
> ?? ?? Canva Pro?
> Canva ???? ????? ?????? ??????? ???? ????? ???? ???????? ??????? ???????
> ????????? ???????? ???? ??? ??????. ?????? ??????? ???? ????? ??????
> ??????? ????? ???? Canva Pro ????? ???? ?? ????? ???????????? ?????
> ???????? ??? ????? ???????? ?????? ????? ???? ?????.
>
> ????? ????????
>
> ?????? ???????: ???? ?????? ????? ??????? ???? ??????? ??????? ?? 5 ????
> ?????. ????? ?????????.
>
> Canva Pro: ????? ???? ???? ?? 100 ????? ????? ????? ??????? 1 ????????
> ?????? ?????? ??? ????? ?????? ???????.
>
> Canva Teams: ???? ????????? ?? ????? ????? ???? ?????? ??????? ????????.
>
> Canva Pro Edu: ????? ???????? ???????? ????? ??? ???? ????? Canva Pro
> ???????? ??? ????? ???????.
>
> ??? ???? ??? Canva Pro Edu ???????
> ? ??????? ??? ???? ???? ???? ??? ????????.
> ? ????? ???? ???? ?? ??????? ????? ???????? ?? ????.
> ? ??? ???? ??????? ????? ????? ???????? ??? Canva Pro Edu ????? ?????
> ???????.
>
> ???? ????? ????????
> ? ?? ???? ?????? ?? ?????? ?????? ???????.
> ? ???? ???????? ????? ???????? (??? edu).
> ? ???????? ??? ???? ???? ???.
>
> ?? ???? ?????? ??? Canva Pro ???? ?????
> ???? ???? ???? ??????? ?????? ???? 30 ????? ????? ?????? ??? ??????
> ??????. ???? ??? ?????? ?????? ????? ???????? ?????? ????? ???????? ???
> ???????? ????? ??????. ??? ?????? ??? Canva Pro ???? ?????? ???? ????? ????
> ???? ??? ??? ?????? ?????????.
>
> ??? ??????? ???? ?????? Canva Pro Edu ??????
> ? ????? ??? ???? ?? 100 ????? ???? ????? ?????????.
> ? ???? ?? 600 ??? ???? ???????.
> ? ????? ?????? ??? ????? ??????? ?????? ?????? ????????.
> ? ????? ????? 1 ????????.
> ? ??????? ????? ??????? ?? ?????? ???????? ??? ?????? ??????.
>
> ????? ????? Canva Pro Edu?
> ??? ?????? ????? ???? ????? Canva Pro ??? ?????? ??? ????? ???????? ??????
> ???? ???????? ??????? ?????? ?????? ????? ????????. ?????? ??? ??? ????
> ?????? ????? ????? ???? ????? ?????????.
>
> ?????
> ??? ??? ?????? ?? ??????? ??? ???? ????? ?????? ??? Canva Pro ?????? ??
> ??? ???? ?????? ??? Canva Pro Edu. ???? ?????? ????? ?? ???? ???????
> ??????? ??? ?? ????. ???? ???? ?????? ?? ???? ????? ???? ?? ????? ???????
> ????????? ????????? ??????? ??? ????? ??????? ???????? Canva Pro Edu ??
> 2025.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251025/da35a60e/attachment-0001.htm>

From aph at openjdk.org  Sun Oct 26 08:43:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 26 Oct 2025 08:43:11 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v10]
In-Reply-To: <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>
Message-ID: <U10OXDO0_9UqgPkByQlwg-TwT3vU31hDCFw8UM8a_TI=.929d4a6f-4e4c-4d20-a33a-2adf56775e3d@github.com>

On Fri, 24 Oct 2025 20:11:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Missing unlock diagnostic VM options, and remove unintended comment
>  - Fix for minimal
>  - Change streaming/mapping states to be binary instead of tri states
>  - Clean up VMProps
>  - Make AOTStreamableObjects diagnostic
>  - Test polishing
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Test fix
>  - move exception marks outside locks
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/97e5ac6e...3d771ca2

Can you talk a little bit about the cost of doing all this? There's something superficially attractive about simply mapping the heap into memory at startup time. Will that continue to be an option with some GCs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3448210742

From alanb at openjdk.org  Sun Oct 26 14:20:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Oct 2025 14:20:09 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v8]
In-Reply-To: <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
Message-ID: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>

On Fri, 24 Oct 2025 18:27:47 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 300:

> 298:      * nanoseconds, or {@code -1}.
> 299:      *
> 300:      * @since 26

The latest API docs is good, thanks for accepting all the comments/suggestions to get this right.

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 305:

> 303:     default public long getTotalGcCpuTime() {
> 304:         return -1;
> 305:     };

No need for the semicolon after the closing brace. No need for `public` modifier either but okay to leave it as event the abstract methods in this interface have it, even if not explicitly needed as they are public anyway.

test/jdk/java/lang/management/MemoryMXBean/GetTotalGcCpuTime.java line 44:

> 42: import java.lang.management.ThreadMXBean;
> 43: 
> 44: public class GetTotalGcCpuTime {

This test will need re-work.

What is the reason for launching a sub-process? The child process starts 4 * ncores threads, the main thread in the child process then exits with status 0. It would be a lot simpler to have a single VM and verify that the GC time increases monotonically when there are busy mutators and/or explicit GC.

The API is designed to work in conjunction with OperatingSystemMXBean.getProcessCpuTime so you can test them together to ensure that GC cpu time is <= process cpu time.

The test can implement MemoryPoolMXBean, just the abstract methods, so you can test the default method.

Look at other tests to see how `@requires` is used in test selection, e.g. tests that uses -XX:+UseZGC will have `@requires vm.gc.Z` in the test description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463840541
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463839299
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463846623

From duke at openjdk.org  Sun Oct 26 15:13:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 26 Oct 2025 15:13:04 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v8]
In-Reply-To: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
 <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
Message-ID: <tpeUYz__7DhR5V9clMYBZVYjhLaG2S6ZZ3TEQM8cS1A=.72649b8e-9a66-400a-8b0b-1f0922513e33@github.com>

On Sun, 26 Oct 2025 14:17:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test will need re-work.

The end-goal of this test was to verify that the implementation correctly guarded against races during shutdown which it manged to test. So to that end I'm not sure this particular test needs re-work as it correctly manages to run Java code that races on this method during VM shutdown. However, if I understand your comment you are suggesting that we should (1) simplify how the test is invoked (2) add a test for checking that the value is monotonically increasing. For the latter I did not add such test as we in the end rely on`os::thread_cpu_time`.

> `GC cpu time is <= process cpu time`

I think we are at the mercy of how well the underlying OS update thread CPU time. I know that for extremely short-lived processes, the accounting for CPU time may be less reliable at least on Linux. In general, can Hotspot make any guarantee about CPU time for threads vs process CPU time?

> What is the reason for launching a sub-process? 

I looked at other tests how they launched tests for different GCs and that's the way I found to achieve that. If `@requires` is another way and is the preferred one I can change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463870835

From duke at openjdk.org  Sun Oct 26 15:16:07 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 26 Oct 2025 15:16:07 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v8]
In-Reply-To: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
 <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
Message-ID: <CK-KQu0jjq-iTraiBmkVErHC2_AUvXZjjNSSKUJXT_M=.daf81ebe-6d0a-4e0a-933d-01159b795d0d@github.com>

On Sun, 26 Oct 2025 14:05:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 300:
> 
>> 298:      * nanoseconds, or {@code -1}.
>> 299:      *
>> 300:      * @since 26
> 
> The latest API docs is good, thanks for accepting all the comments/suggestions to get this right.

I should say thank you all for the attention to detail :-) The API docs is indeed much better than the original suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463872264