From amenkov at openjdk.org  Tue Jul  1 00:33:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Jul 2025 00:33:40 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
Message-ID: <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com>

On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed if tu assert

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2973134141

From sviswanathan at openjdk.org  Tue Jul  1 00:47:42 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Jul 2025 00:47:42 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <1F2MWloqst4ZYni3KE4o_IOIhVYcw9kjv6TRw3utgy0=.c72ad565-088b-42f3-a14e-1ab264a5fc4e@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2973146764

From cjplummer at openjdk.org  Tue Jul  1 00:48:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Jul 2025 00:48:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
Message-ID: <n4Pi48mZ7ewMDMtWQW0yG5_0DWHYQkBjO1g8drmKWmU=.c7bbfa5b-1bd6-4ba0-832f-22189487baca@github.com>

On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed if tu assert

The fix looks good, but I assume that the static analysis tool that reported the false warning is still going to report it, or at least do so in product builds where the assert code is not included.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2973147893

From dholmes at openjdk.org  Tue Jul  1 00:53:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 00:53:50 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v3]
In-Reply-To: <QHD4zzKMWN_h-YFLXBSBGGWV5wB4hn2Zo2zH03vJq_E=.da85dc91-ce2c-4cb1-9a5f-de9d9813558b@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <QHD4zzKMWN_h-YFLXBSBGGWV5wB4hn2Zo2zH03vJq_E=.da85dc91-ce2c-4cb1-9a5f-de9d9813558b@github.com>
Message-ID: <vm78qD4LHwURQ6EPg9OSd2GbJaAIEi18tkdX80NmZ_s=.0e19a836-953f-4f90-b0ab-ed1a25cbcff9@github.com>

On Mon, 30 Jun 2025 22:11:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed comment updates

Just a drive-by comment ...

src/hotspot/share/cds/aotClassInitializer.cpp line 247:

> 245: 
> 246:   if (CDSConfig::is_dumping_method_handles()) {
> 247:     // The list of @AOTClassInitializer was created with the help of CDSHeapVerifier.

Given there is no longer a list these left over comments seem out of place here. Perhaps the `has_aot_initialization` method should document how it was determined which classes to annotate and what additional constraints there are. Though that could also be left for the documentation in AOT.md, rather than the code.

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

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2973142829
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2176188797

From fyang at openjdk.org  Tue Jul  1 02:12:39 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 1 Jul 2025 02:12:39 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>

On Thu, 26 Jun 2025 15:58:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Hotspot tier1 has passed on linux-riscv64. The riscv part seems fine after a cursory look. Thanks for the ping.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2973254676

From dholmes at openjdk.org  Tue Jul  1 02:30:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 02:30:40 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v2]
In-Reply-To: <JRBsn24tTFekjuIxr60JQgkDLbF5QoKtDUEzJtHnrh4=.5943578f-1b36-47c6-bfd8-8430027a959a@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <JRBsn24tTFekjuIxr60JQgkDLbF5QoKtDUEzJtHnrh4=.5943578f-1b36-47c6-bfd8-8430027a959a@github.com>
Message-ID: <q25fD8ZuwUiCcJ28FfQZh2DdOYhMcz9SSKL_sZU-OuY=.290b4a63-b8ca-4fa8-9093-5ac81c6e714e@github.com>

On Mon, 30 Jun 2025 21:20:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed jmethodid to methodHandle.

`methodHandle` form seems okay to me too.

src/hotspot/share/prims/jvmtiImpl.cpp line 192:

> 190: void VM_ChangeBreakpoints::doit() {
> 191:   if (_bp->method()->is_old()) {
> 192:     // The bp->_method become old because VMOp with class redefinition happened for this class

Suggestion:

    // The bp->_method became old because VMOp with class redefinition happened for this class

src/hotspot/share/prims/jvmtiImpl.cpp line 193:

> 191:   if (_bp->method()->is_old()) {
> 192:     // The bp->_method become old because VMOp with class redefinition happened for this class
> 193:     // fter JvmtBreakpoint was created but before JVM_ChangeBreakpoints started.

Suggestion:

    // after JvmtiBreakpoint was created but before JVM_ChangeBreakpoints started.

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

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2973294055
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2176290929
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2176291229

From dholmes at openjdk.org  Tue Jul  1 03:08:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 03:08:42 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v7]
In-Reply-To: <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
Message-ID: <S3v8iJ_QO09eaogRj3gdJHH3VxMhtns54y7UFk1E77A=.1cb4eb65-27e5-4eda-a527-49d2a069635d@github.com>

On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls 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:
> 
>  - remove test definition changes
>  - TLH: use cv_internal_thread_to_JavaThread()
>  - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
>  - Test requires: permit linux debug testing
>  - comment update
>  - comment update
>  - newline
>  - Test fails on minimal VM: require jvmti feature
>  - Correct THROW macro
>  - ThreadDumper thread count
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/393efb22...e2043438

Some minor nits/suggestions but generally looks good.

src/hotspot/share/services/threadService.cpp line 1445:

> 1443:   JavaThread* java_thread = nullptr;
> 1444:   oop thread_oop;
> 1445:   bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop);

Suggestion:

  bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop);
  assert((has_javathread && thread_oop != nullptr) || !has_javathread, "Missing Thread oop");

src/hotspot/share/services/threadService.cpp line 1447:

> 1445:   bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop);
> 1446:   Handle thread_h(THREAD, thread_oop);
> 1447:   bool is_virtual = java_lang_VirtualThread::is_instance(thread_h());

Suggestion:

  bool is_virtual = java_lang_VirtualThread::is_instance(thread_h());  // Deals with null

Just to make it clear we don't need an external null check here.

src/hotspot/share/services/threadService.cpp line 1450:

> 1448: 
> 1449:   if (!has_javathread && !is_virtual) {
> 1450:     return nullptr; // thread terminated

Suggestion:

    return nullptr; // thread terminated so not of interest

It took me a lot of backtracking in the Java code to find ThreadContainer which finally stated that only live threads are of interest, so an expanded comment here would help me. ( I was ready to suggest we should be creating a `ThreadSnapshot` that represents the terminated thread.)

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 313:

> 311:      * @throws UncheckedIOException if an I/O error occurs
> 312:      */
> 313:     private static boolean dumpThread(Thread thread, JsonWriter jsonWriter) {

Please document the return value in the javadoc comment.

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 56:

> 54:      * Take a snapshot of a Thread to get all information about the thread.
> 55:      * Return null if a ThreadSnapshot cannot be created, for example if the
> 56:      * thread has terminated.

Strictly speaking we can create a snapshot for a terminated thread, but our only client doesn't care about them so we don't.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2973312048
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176304440
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176303308
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176318110
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176319448
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176320553

From dholmes at openjdk.org  Tue Jul  1 03:15:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 03:15:40 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
Message-ID: <Sgk3eIEfEprxu8kO6QLoT-wKQ8-gbsoomhzfmVErYWA=.2ff58080-7f8e-4c7e-af22-c6605549ec68@github.com>

On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed if tu assert

src/hotspot/share/prims/jvmtiTagMap.cpp line 947:

> 945: // invoked for each object in the heap
> 946: void IterateOverHeapObjectClosure::do_object(oop o) {
> 947:   assert(o != nullptr, "Parameter 'o' must not be null!");

Suggestion:

  assert(o != nullptr, "Heap iteration should never produce null");

Same with the other assertion please. Though as @plummercj  states I don't see how this will help with the static analysis tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26002#discussion_r2176326686

From lmesnik at openjdk.org  Tue Jul  1 03:17:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 03:17:41 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v3]
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/prims/jvmtiImpl.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/prims/jvmtiImpl.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26031/files
  - new: https://git.openjdk.org/jdk/pull/26031/files/e1524bbd..c7aaa804

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

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

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

From dholmes at openjdk.org  Tue Jul  1 03:24:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 03:24:41 GMT
Subject: RFR: 8360776: Enable -XX:+UseAPX as experimental feature in all
 builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <b_Dp4saNdfqrhCcCj3Wztl9nnR73-b1IyBktfpplbIA=.f9c9ddd3-6446-4e18-9470-b926069ecf95@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

Okay the changes do as described.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26029#pullrequestreview-2973354395

From dholmes at openjdk.org  Tue Jul  1 03:50:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 03:50:39 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v3]
In-Reply-To: <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
Message-ID: <jVffC4kDbL_nwnVo85LGsGKu8ezLvEbaXrusG-b-wuE=.ab2798c7-20b6-43d5-9d2f-137ddf5bd61a@github.com>

On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Seems fine to me.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2973380226

From jbhateja at openjdk.org  Tue Jul  1 05:36:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 05:36:40 GMT
Subject: RFR: 8360776: Enable -XX:+UseAPX as experimental feature in all
 builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <KMioxsg2TAlT5eG9L4CEZKblENMttZ9aIDM6PDD9CvY=.65fa6ebf-e8a3-484b-afe5-1c81802ae68f@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

LGTM.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26029#pullrequestreview-2973558539

From jbhateja at openjdk.org  Tue Jul  1 05:44:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 05:44:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <pJYimNDzlpki3-qL8nM4KiFxKALz-B9TQQjWdHS3Mz0=.7841e6f5-f325-4072-8893-2238b400b0a1@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <yLFxvGfpEeemgeePGLOAMTNkzhrFCEmcGYvP_YgV2l8=.e4b1f131-a230-4e3f-ab02-99e28fd242e7@github.com>
 <4JWUyNwX9neYkTIymwpEpaXMig0AGc5ylQvPlWjqLR0=.5ffb5edb-3bb6-4d36-b3a3-820b4cafd704@github.com>
 <pJYimNDzlpki3-qL8nM4KiFxKALz-B9TQQjWdHS3Mz0=.7841e6f5-f325-4072-8893-2238b400b0a1@github.com>
Message-ID: <PZ8S3O3hjSuuIp6KA-nGrXl2ShdMtwo7NchHytWqaPU=.7705d4ce-004a-4cdd-82db-5302986fccfd@github.com>

On Mon, 30 Jun 2025 22:14:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> @jatin-bhateja Pusha is not expected to change any registers. The inadvertent change of registers is very hard to debug. So in my thoughts it is better to have a conservative implementation currently which doesn't change RAX register.
>
> Please see the updated code which fixes the issue by restoring the contents of RAX. The tests are passing with this update.

Thanks @vamsi-parasa , yes this looks fine to me now, I had a similar thought to fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2176475736

From jbhateja at openjdk.org  Tue Jul  1 05:48:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 05:48:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <JfzX_i7Ybo8SCY-lA6NL8IP8-aEQBfCvzvPmGB_a_M4=.a183c931-763d-4b04-8000-b63cafab0ae3@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

LGTM.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2973586361

From jbhateja at openjdk.org  Tue Jul  1 06:06:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 06:06:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 387:

> 385:     __ movptr(Address(rsp, (--slot) * wordSize), r29);
> 386:     __ movptr(Address(rsp, (--slot) * wordSize), r30);
> 387:     __ movptr(Address(rsp, (--slot) * wordSize), r31);

I think you should use pushp2 / pop2p for these instructions also , maybe it can be handled along with 
https://github.com/openjdk/jdk/pull/25889

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2176501724

From xgong at openjdk.org  Tue Jul  1 06:09:44 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 1 Jul 2025 06:09:44 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Address review comments
>  - Merge 'jdk:master' into JDK-8355563
>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API

Ping again! Thanks in advance!

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3021961883

From amitkumar at openjdk.org  Tue Jul  1 06:29:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 1 Jul 2025 06:29:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
Message-ID: <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>

On Mon, 30 Jun 2025 16:14:44 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>
>n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."


@adinn is this something which is expected:

Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc

[error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]

Retrying call stack printing without source information...


I don't see any truncation message in the hs_err output.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022029790

From epeter at openjdk.org  Tue Jul  1 06:38:45 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 1 Jul 2025 06:38:45 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
Message-ID: <LFxGEZIjTE6Jmz8s2EklREGHhmxN61_P_Ty6iqwGUBc=.7b79a619-0459-472e-b6ce-40b77d1b306f@github.com>

On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Address review comments
>>  - Merge 'jdk:master' into JDK-8355563
>>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API
>
> Ping again! Thanks in advance!

@XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look.

I quickly looked through your new benchmark results you published after integration of https://github.com/openjdk/jdk/pull/25539. There seem to still be a few cases where `Gain < 1`. Especially:

GatherOperationsBenchmark.microShortGather512_MASK         256 thrpt  30  ops/ms 11587.465  10674.598  0.92
GatherOperationsBenchmark.microShortGather512_MASK        1024 thrpt  30  ops/ms  2902.731   2629.739  0.90
GatherOperationsBenchmark.microShortGather512_MASK        4096 thrpt  30  ops/ms   741.546    671.124  0.90

and

GatherOperationsBenchmark.microShortGather256_MASK         256 thrpt  30  ops/ms 11339.217  10951.141  0.96
GatherOperationsBenchmark.microShortGather256_MASK        1024 thrpt  30  ops/ms  2840.081   2718.823  0.95
GatherOperationsBenchmark.microShortGather256_MASK        4096 thrpt  30  ops/ms   725.334    696.343  0.96

and

GatherOperationsBenchmark.microByteGather512_MASK           64 thrpt  30  ops/ms 50588.210  48220.741  0.95


Do you know what happens in those cases?

That said: https://github.com/openjdk/jdk/pull/25539 seems to have been quite the sucess, there are way fewer regressions now than before ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022057434

From xgong at openjdk.org  Tue Jul  1 06:43:44 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 1 Jul 2025 06:43:44 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
Message-ID: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>

On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Address review comments
>>  - Merge 'jdk:master' into JDK-8355563
>>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API
>
> Ping again! Thanks in advance!

> @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look.
> 
> I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially:
> 
> ```
> GatherOperationsBenchmark.microShortGather512_MASK         256 thrpt  30  ops/ms 11587.465  10674.598  0.92
> GatherOperationsBenchmark.microShortGather512_MASK        1024 thrpt  30  ops/ms  2902.731   2629.739  0.90
> GatherOperationsBenchmark.microShortGather512_MASK        4096 thrpt  30  ops/ms   741.546    671.124  0.90
> ```
> 
> and
> 
> ```
> GatherOperationsBenchmark.microShortGather256_MASK         256 thrpt  30  ops/ms 11339.217  10951.141  0.96
> GatherOperationsBenchmark.microShortGather256_MASK        1024 thrpt  30  ops/ms  2840.081   2718.823  0.95
> GatherOperationsBenchmark.microShortGather256_MASK        4096 thrpt  30  ops/ms   725.334    696.343  0.96
> ```
> 
> and
> 
> ```
> GatherOperationsBenchmark.microByteGather512_MASK           64 thrpt  30  ops/ms 50588.210  48220.741  0.95
> ```
> 
> Do you know what happens in those cases?

Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that?

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022088710

From jbhateja at openjdk.org  Tue Jul  1 06:45:42 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 06:45:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>

On Thu, 19 Jun 2025 05:15:40 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
> 
> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
> 
> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.

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

> 798: void MacroAssembler::push(Register src, bool is_pair) {
> 799:   if (is_pair && VM_Version::supports_apx_f()) {
> 800:     pushp(src);

What does is_pair signify here ? You are just pushing one register. Do you intend to use has_matching_pop ?

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

> 805: 
> 806: void MacroAssembler::pop(Register dst, bool is_pair) {
> 807:   if (is_pair && VM_Version::supports_apx_f()) {

Same as above, new argument suggestion: please use has_matching_push.
I understand your purpose here is to delegate the responsibility of balancing of PPX pair to the user.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2176508727
PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2176511119

From jbhateja at openjdk.org  Tue Jul  1 06:45:42 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 06:45:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
Message-ID: <Q6XtC6Wc77yo7VxQsJhhU9AtY_Mg0kGk0b-YbCtPmcY=.0bff10a6-ce88-4502-9051-d8c9e5cab5fe@github.com>

On Tue, 1 Jul 2025 06:11:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 807:
> 
>> 805: 
>> 806: void MacroAssembler::pop(Register dst, bool is_pair) {
>> 807:   if (is_pair && VM_Version::supports_apx_f()) {
> 
> Same as above, new argument suggestion: please use has_matching_push.
> I understand your purpose here is to delegate the responsibility of balancing of PPX pair to the user.

For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker in the stub snippets using push/pop instruction sequence and wrap the actual assembler call underneath. The idea here is to catch the balancing error upfront as PPX is purely a performance hint. Instructions with this hint have the same functional semantics as those without. PPX hints set by the compiler that violate the balancing rule may turn off the PPX
optimization, but they will not affect program semantics..


class APXPushPopPairTracker {
    private:
        int _counter;
 
    public:
        APXPushPopPairTracker() _counter(0) {
        }

       ~APXPushPopPairTracker() {
           assert(_counter == 0, "Push/pop pair mismatch");
        }
     
        void push(Register reg, bool has_matching_pop) {
            if (has_matching_pop && VM_Version::supports_apx_f()) {
               Assembler::pushp(reg);
               incrementCounter();
            } else {
               Assembler::push(reg);
            }
        }
        void pop(Register reg, bool has_matching_push) {
            if (has_matching_push && VM_Version::supports_apx_f()) {
               Assembler::popp(reg);
               decrementCounter();
            } else {
               Assembler::pop(reg);
            }
        }     
        void incrementCounter() {
          _counter++;
        }
       void decrementCounter() {
         _counter--;
       }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2176549150

From jbhateja at openjdk.org  Tue Jul  1 06:48:42 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 06:48:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
Message-ID: <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>

On Tue, 1 Jul 2025 06:11:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 807:
> 
>> 805: 
>> 806: void MacroAssembler::pop(Register dst, bool is_pair) {
>> 807:   if (is_pair && VM_Version::supports_apx_f()) {
> 
> Same as above, new argument suggestion: please use has_matching_push.
> I understand your purpose here is to delegate the responsibility of balancing of PPX pair to the user.

For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker in the stub snippets using push/pop instruction sequence and wrap the actual assembler call underneath. The idea here is to catch the balancing error upfront as PPX is purely a performance hint. Instructions with this hint have the same functional semantics as those without. PPX hints set by the compiler that violate the balancing rule may turn off the PPX
optimization, but they will not affect program semantics..


class APXPushPopPairTracker {
    private:
        int _counter;
 
    public:
        APXPushPopPairTracker() _counter(0) {
        }

       ~APXPushPopPairTracker() {
           assert(_counter == 0, "Push/pop pair mismatch");
        }
     
        void push(Register reg, bool has_matching_pop) {
            if (has_matching_pop && VM_Version::supports_apx_f()) {
               Assembler::pushp(reg);
               incrementCounter();
            } else {
               Assembler::push(reg);
            }
        }
        void pop(Register reg, bool has_matching_push) {
            if (has_matching_push && VM_Version::supports_apx_f()) {
               Assembler::popp(reg);
               decrementCounter();
            } else {
               Assembler::pop(reg);
            }
        }     
        void incrementCounter() {
          _counter++;
        }
        void decrementCounter() {
           _counter--;
        }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2176564840

From tschatzl at openjdk.org  Tue Jul  1 06:49:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Jul 2025 06:49:42 GMT
Subject: RFR: 8346914: UB issue in scalbnA
In-Reply-To: <in6uOP73K4zvwEiEWc8K8o426BQ3QMK4pMNmNQWe2m0=.05bb06d3-0e1b-4af3-80c4-a064664973fb@github.com>
References: <in6uOP73K4zvwEiEWc8K8o426BQ3QMK4pMNmNQWe2m0=.05bb06d3-0e1b-4af3-80c4-a064664973fb@github.com>
Message-ID: <7FIhKuiUnuschis_aT_MggWlJDWLFwkPi4_mIh4CVyQ=.e8605221-93b5-4d17-9efe-3aa8b63ac40b@github.com>

On Fri, 20 Jun 2025 16:06:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that replaces uses of our scalbnA function with
> using the standard scalbn function. Removed scalbnA, and also copysignA.
> 
> For more details, see first comment and JBS.
> 
> Testing: mach5 tier1-6. Though from discussion in
> https://github.com/openjdk/jdk/pull/25656, it's hard to get to our uses of
> scalbn/scalbnA.
> 
> Before removing it, I tested scalbnA via a gtest that is attached to the JBS
> issue.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25917#pullrequestreview-2973757802

From epeter at openjdk.org  Tue Jul  1 06:55:41 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 1 Jul 2025 06:55:41 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
 <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
Message-ID: <jHk0oiJdpn20vF43Mzzlu0SYupv3sHSfBJSQhIjlu2c=.99fb9125-0ee8-49d5-977c-691d998cd88b@github.com>

On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Ping again! Thanks in advance!
>
>> @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look.
>> 
>> I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially:
>> 
>> ```
>> GatherOperationsBenchmark.microShortGather512_MASK         256 thrpt  30  ops/ms 11587.465  10674.598  0.92
>> GatherOperationsBenchmark.microShortGather512_MASK        1024 thrpt  30  ops/ms  2902.731   2629.739  0.90
>> GatherOperationsBenchmark.microShortGather512_MASK        4096 thrpt  30  ops/ms   741.546    671.124  0.90
>> ```
>> 
>> and
>> 
>> ```
>> GatherOperationsBenchmark.microShortGather256_MASK         256 thrpt  30  ops/ms 11339.217  10951.141  0.96
>> GatherOperationsBenchmark.microShortGather256_MASK        1024 thrpt  30  ops/ms  2840.081   2718.823  0.95
>> GatherOperationsBenchmark.microShortGather256_MASK        4096 thrpt  30  ops/ms   725.334    696.343  0.96
>> ```
>> 
>> and
>> 
>> ```
>> GatherOperationsBenchmark.microByteGather512_MASK           64 thrpt  30  ops/ms 50588.210  48220.741  0.95
>> ```
>> 
>> Do you know what happens in those cases?
> 
> Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that?

@XiaohongGong Maybe someone from Intel (@jatin-bhateja @sviswa7) can help you with the x86 specific issues. You could always use hardware counters to measure cache misses. Also if the vectors are not cache-line aligned, there may be split loads or stores. Also that can be measured with hardware counters. Maybe the benchmark needs to be improved somehow, to account for issues with alignment.

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022132271

From xgong at openjdk.org  Tue Jul  1 07:10:41 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 1 Jul 2025 07:10:41 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
 <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
Message-ID: <N1M67Ae8UGs0Pcs1SUMGK4XS8pJxqZ6JCfEfbqYngDY=.d26a5b4c-2c87-4d8c-9f0a-fc976112fa2e@github.com>

On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Ping again! Thanks in advance!
>
>> @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look.
>> 
>> I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially:
>> 
>> ```
>> GatherOperationsBenchmark.microShortGather512_MASK         256 thrpt  30  ops/ms 11587.465  10674.598  0.92
>> GatherOperationsBenchmark.microShortGather512_MASK        1024 thrpt  30  ops/ms  2902.731   2629.739  0.90
>> GatherOperationsBenchmark.microShortGather512_MASK        4096 thrpt  30  ops/ms   741.546    671.124  0.90
>> ```
>> 
>> and
>> 
>> ```
>> GatherOperationsBenchmark.microShortGather256_MASK         256 thrpt  30  ops/ms 11339.217  10951.141  0.96
>> GatherOperationsBenchmark.microShortGather256_MASK        1024 thrpt  30  ops/ms  2840.081   2718.823  0.95
>> GatherOperationsBenchmark.microShortGather256_MASK        4096 thrpt  30  ops/ms   725.334    696.343  0.96
>> ```
>> 
>> and
>> 
>> ```
>> GatherOperationsBenchmark.microByteGather512_MASK           64 thrpt  30  ops/ms 50588.210  48220.741  0.95
>> ```
>> 
>> Do you know what happens in those cases?
> 
> Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that?

> @XiaohongGong Maybe someone from Intel (@jatin-bhateja @sviswa7) can help you with the x86 specific issues. You could always use hardware counters to measure cache misses. Also if the vectors are not cache-line aligned, there may be split loads or stores. Also that can be measured with hardware counters. Maybe the benchmark needs to be improved somehow, to account for issues with alignment.

I also tried to measure cache misses with perf on my x86 machine, and I noticed the cache miss is increased. The generated code layout of the test/benchmark is changed with my changes in Java side, so I guess maybe the alignment is different with before. To verify my thought, I used the vm option `-XX:OptoLoopAlignment=32`, and the performance can be improved a lot compared with the version without my change. So I think the patch itself maybe acceptable even we noticed minor regressions.

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022195040

From asemenov at openjdk.org  Tue Jul  1 07:38:31 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 1 Jul 2025 07:38:31 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
Message-ID: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>

> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  Updated the text of assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26002/files
  - new: https://git.openjdk.org/jdk/pull/26002/files/88f1e494..3c810260

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

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

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

From adinn at openjdk.org  Tue Jul  1 07:47:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 07:47:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
Message-ID: <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>

On Tue, 1 Jul 2025 06:27:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar I managed to run the test on an s390x build and it passed. I didn't get any hserr output in the jtr file when I set DEBUG on the command line. So, I modified the test to write the hserr file to system.err unconditionially (i.e. I changed the if at line 137 of MachCodeFramesInErrorFile.java to 'if (true)'.
>> 
>> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>> 
>> n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."
>> 
>> If that is the case and if you can reproduce the problem after modifying the test to write the hserr contents unconditionally then you ought to be able to see all the file contents by setting system property javatest.maxOutputSize to a suitable value (default is 100000).
>
>> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>>
>>n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."
> 
> 
> @adinn is this something which is expected:
> 
> Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
> J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
> j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
> j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
> v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
> 
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
> 
> Retrying call stack printing without source information...
> 
> 
> I don't see any truncation message in the hs_err output.

@offamitkumar Thanks for following up.

> is this something which is expected:

    Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
    J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
    j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
    j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
    v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
    
    [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
    
    Retrying call stack printing without source information...

That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.

The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022350306

From amitkumar at openjdk.org  Tue Jul  1 08:37:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 1 Jul 2025 08:37:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
Message-ID: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>

On Tue, 1 Jul 2025 07:44:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.

There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022653170

From adinn at openjdk.org  Tue Jul  1 08:37:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:37:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <tRiL5T6iD5lp2v_Fe4T3GSmD0CeS-hSpcYWmDx66gbM=.146b6a5e-4499-4d2f-8637-ed811f546742@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <tRiL5T6iD5lp2v_Fe4T3GSmD0CeS-hSpcYWmDx66gbM=.146b6a5e-4499-4d2f-8637-ed811f546742@github.com>
Message-ID: <rSrystcuGWdUXlN8hlm4H7w3CiMieYv3ciJbu4LoOHs=.9a6a1a67-681d-4a26-a9df-0fff8f1f009b@github.com>

On Mon, 30 Jun 2025 20:27:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/cpu/x86/stubDeclarations_x86.hpp line 121:
> 
>> 119:                 vector_byte_shuffle_mask, vector_byte_shuffle_mask)     \
>> 120:   do_stub(compiler, vector_short_shuffle_mask)                          \
>> 121:   do_arch_entry(x86, compiler, vector_short_shuffle_mask,               \
> 
> Was it bug?

I think this was just a potential bug for the Leyden premain repo not an actual one for that repo and not a bug for mainline.

The declaration was attaching the entry to the wrong stub. I don't think this causes any problem, even in premain, because that wrong stub is still in the same blob as the correct stub. The bad declaration means that when premain saves and restores the entry address it will compute an offset from the wrong base address -- the one for the wrongly declared stub. That means the offset will identify a code address belonging to another stub i.e. it may be negative or greater than the extent of the declared owner. This won't cause a crash because it will still end up pointing at the desired address in the current blob. However, premain really ought to assert that the offset is non-negative and less than the associated stub's extent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176837367

From sspitsyn at openjdk.org  Tue Jul  1 08:41:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 08:41:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <BbeTm6iCHsR7YGVoOl1u_nDm6vQTP965CNah4RC6yl8=.9beb52f0-a241-458b-8823-5930dffd8763@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
 <OxfzZUtbE_DVnlcDyC7_cXzVK_4igL8DrzTwt6voRz4=.05c6969f-5e12-4e2c-b7ad-2dd5b1b674fa@github.com>
 <BbeTm6iCHsR7YGVoOl1u_nDm6vQTP965CNah4RC6yl8=.9beb52f0-a241-458b-8823-5930dffd8763@github.com>
Message-ID: <wb_CuyGWD3G6kTADE-iOTkPxeQAauF1NVfR2Oemu70Y=.0d0faedb-8443-4d98-ae76-489fa305163a@github.com>

On Mon, 30 Jun 2025 11:53:36 GMT, Anton Artemov <duke at openjdk.org> wrote:

> I reverted closure names changes in JVMT files.

Thanks! Unification is good in general but there is a price to pay.
So, we are normally balancing among different requirements. :)
The `HSClosure` suffix is not perfect either because `HS` normally stands for HotSpot.
But I can be wrong with this assumption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176851022

From adinn at openjdk.org  Tue Jul  1 08:43:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:43:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <Afd5sCYQc6QYVsl998LpjaGXctTqUEFlg0Vtz0uZoyA=.d32011dc-b5b1-434e-a946-874975b90414@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Afd5sCYQc6QYVsl998LpjaGXctTqUEFlg0Vtz0uZoyA=.d32011dc-b5b1-434e-a946-874975b90414@github.com>
Message-ID: <6JrLRhTlBHNeDL9NPy5IE0dPWyVF7ZTeEoH9K90yQQc=.c83860b5-5a93-450b-803f-6c5337270ec3@github.com>

On Mon, 30 Jun 2025 20:47:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/share/runtime/stubCodeGenerator.hpp line 109:
> 
>> 107:   bool _print_code;
>> 108:   BlobId _blob_id;
>> 109: protected:
> 
> Please return spacing for `protected:` line.

Done

> src/hotspot/share/runtime/stubCodeGenerator.hpp line 118:
> 
>> 116: 
>> 117:   MacroAssembler* assembler() const              { return _masm; }
>> 118:   BlobId blob_id()                        { return _blob_id; }
> 
> Align body of methods. May be move them to the left - I don't see why we have such big spacing.

I believe the spacing is meant to align with the declarations that follow.

I have simply realigned the modified line with the old line to avoid unnecessary changes.

> src/hotspot/share/runtime/stubDeclarations.hpp line 1235:
> 
>> 1233:                  do_arch_entry, do_arch_entry_init)                     \
>> 1234: 
>> 1235: 
> 
> No need this empty line.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176858735
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176856030
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176859879

From adinn at openjdk.org  Tue Jul  1 08:52:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:52:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <rYmS4L6d2XiEr-6Mr-UdpL_J03NS0jnRhdPJW0gRgHo=.ad459a0c-8fce-4538-bc7d-8418dd19d9da@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

Yes please!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022753622

From adinn at openjdk.org  Tue Jul  1 08:52:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:52:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <ztsZ4lGRaS-DkADj9dQFBBzZ1Y653C_MIqUCI-fXMIM=.d7be0bb9-e3f1-434f-bac5-06dedbc4f51f@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ztsZ4lGRaS-DkADj9dQFBBzZ1Y653C_MIqUCI-fXMIM=.d7be0bb9-e3f1-434f-bac5-06dedbc4f51f@github.com>
Message-ID: <6jkjxCQdnjuzVj9Eeg9jSBRTSdotEy9FTJRQIMtHJrE=.b9a5fedf-af69-48f4-820d-55bdfeed51be@github.com>

On Mon, 30 Jun 2025 20:54:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/share/runtime/stubRoutines.cpp line 235:
> 
>> 233: SharedRuntime::_jbyte_array_copy_ctr++;      // Slow-path byte array copy
>> 234: #endif // !PRODUCT
>> 235: Copy::conjoint_jbytes_atomic(src, dest, count);
> 
> Why you removed leading spaces here and in the following methods?

Sorry, I mistakenly reformatted more a larger region than I should. Reverted.

> src/hotspot/share/runtime/stubRoutines.cpp line 378:
> 
>> 376: #define RETURN_STUB_PARM(xxx_arraycopy, parm) {                 \
>> 377:     name = parm ? #xxx_arraycopy "_uninit": #xxx_arraycopy;     \
>> 378:     return StubRoutines::xxx_arraycopy(parm); }
> 
> No need these spacing changes - it was fine.

Same issue. All restored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176878410
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176879334

From sspitsyn at openjdk.org  Tue Jul  1 09:02:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:02:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
Message-ID: <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>

On Mon, 30 Jun 2025 11:57:23 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
>> 
>> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
>> 
>> Tested in GHA and tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Reverted closure names in JVMTI

This looks okay in general.
I've posted several nits though.

src/hotspot/share/classfile/javaClasses.cpp line 1980:

> 1978:   ResourceMark rm(THREAD);
> 1979:   HandleMark   hm(THREAD);
> 1980:   GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread));

Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2288:

> 2286:   };
> 2287: 
> 2288:   ReadMonitorsHandshakeClosure rmc;

Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2319:

> 2317:     jint num_threads_completed() const { return _num_threads_completed; }
> 2318:   };
> 2319:   TraceSelfHandshakeClosure tsc(Thread::current());

Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2357:

> 2355:     bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr);
> 2356:     if (is_alive) {
> 2357:       TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target);

Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

src/hotspot/share/runtime/synchronizer.cpp line 1837:

> 1835:     // A JavaThread needs to handshake in order to safely free the
> 1836:     // ObjectMonitors that were deflated in this cycle.
> 1837:     DeflationHandshakeClosure hfd_hc;

Nit: Rename: `hfd_hc` => `dhc` or `hfd_hc` => `cl`.

src/hotspot/share/runtime/vmThread.cpp line 456:

> 454:       if (HandshakeALot) {
> 455:         MutexUnlocker mul(VMOperation_lock);
> 456:         ALotOfHandshakeClosure hal_cl;

Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`.

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

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974276487
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176875478
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176885943
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176889645
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176891619
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176908630
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176911514

From mhaessig at openjdk.org  Tue Jul  1 09:11:32 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 09:11:32 GMT
Subject: RFR: 8308094: Add a compilation timeout flag to catch long running
 compilations [v2]
In-Reply-To: <rJAYKR5w4xEHWCIzf2sAdDHzyrJY6i-uF33FjQpPGGM=.60ee6d42-3ede-443f-bd9e-c2705ae06a62@github.com>
References: <rJAYKR5w4xEHWCIzf2sAdDHzyrJY6i-uF33FjQpPGGM=.60ee6d42-3ede-443f-bd9e-c2705ae06a62@github.com>
Message-ID: <_Ye19u_7PlqlsoRSuR0dNeAGbeuHyN_oqD1ZS4q9Nvk=.b94fd29d-d43e-4561-9926-7f5a46434d8e@github.com>

> This PR adds `-XX:CompileTaskTimeout` on Linux to limit the amount of time a compilation task can run. The goal of this is initially to be able to find and investigate long-running compilations.
> 
> The timeout is implemented using a POSIX timer that sends a `SIGALRM` to the compiler thread the compile task is running on. Each compiler thread registers a signal handler that triggers an assert upon receiving `SIGALRM`. This is currently only implemented for Linux, because it relies on `SIGEV_THREAD_ID` to get the signal delivered to the same thread that timed out.
> 
> Since `SIGALRM` is now used, the test `runtime/signal/TestSigalrm.java` now requires `vm.flagless` so it will not interfere with the compiler thread signal handlers.
> 
> Testing:
>  - [ ] Github Actions
>  - [x] tier1, tier2 on all platforms
>  - [x] tier3, tier4 and Oracle internal testing on Linux fastdebug
>  - [x] tier1 through tier4 with `-XX:CompileTaskTimeout=60000` (one minute timeout) to see what fails (`compiler/codegen/TestAntiDependenciesHighMemUsage2.java`, `compiler/loopopts/TestMaxLoopOptsCountReached.java`, and `compiler/c2/TestScalarReplacementMaxLiveNodes.java` fail)

Manuel H?ssig 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 branch 'master' into JDK-8308094-timeout
 - Fix SIGALRM test
 - Add timeout functionality to compiler threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26023/files
  - new: https://git.openjdk.org/jdk/pull/26023/files/09e0e58c..5840cc2e

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

  Stats: 4936 lines in 244 files changed: 2913 ins; 773 del; 1250 mod
  Patch: https://git.openjdk.org/jdk/pull/26023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26023/head:pull/26023

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

From adinn at openjdk.org  Tue Jul  1 09:11:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 09:11:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  fix formatting issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/29f02865..7908e895

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

  Stats: 29 lines in 3 files changed: 0 ins; 1 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/26004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26004/head:pull/26004

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

From sspitsyn at openjdk.org  Tue Jul  1 09:13:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:13:40 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
Message-ID: <ClM1eSGgW2ID7_ALYsNbspw55JtNRfyRZKnolmk8j54=.d4d2c8b5-fecd-4c4a-bf3b-eeb3d3a4827b@github.com>

On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the text of assert

This looks okay.
However, I agree with David it is not going to address the issue with static analysis tool.
Is it right?
Also, why are there two bugs associated with this PR?

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

PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2974392851

From sspitsyn at openjdk.org  Tue Jul  1 09:19:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:19:40 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v3]
In-Reply-To: <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
Message-ID: <mwdEq_RVtq0gnWb3s-FzZK9JHaSs7CvyfP6u5PjDIxk=.418c2fb4-fbfa-492a-bb89-8f6e197f36b2@github.com>

On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Looks good.
Please, ignore my previous comment as I agree with current approach.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2974422198

From asemenov at openjdk.org  Tue Jul  1 09:30:48 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 1 Jul 2025 09:30:48 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <ClM1eSGgW2ID7_ALYsNbspw55JtNRfyRZKnolmk8j54=.d4d2c8b5-fecd-4c4a-bf3b-eeb3d3a4827b@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
 <ClM1eSGgW2ID7_ALYsNbspw55JtNRfyRZKnolmk8j54=.d4d2c8b5-fecd-4c4a-bf3b-eeb3d3a4827b@github.com>
Message-ID: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com>

On Tue, 1 Jul 2025 09:11:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This looks okay. However, I agree with David it is not going to address the issue with static analysis tool. Is it right? Also, why are there two bugs associated with this PR?



    Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR.

    Regarding the analyzer, we will rerun the analysis with assert enabled and check if it helps to suppress the analyzer warnings

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3022949352

From kevinw at openjdk.org  Tue Jul  1 09:33:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 09:33:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v8]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <877zCTrsEsy0Onpp7jSkwb7fnRLJyiy6vi-5Z2Gfl7A=.3764d4da-6373-4c52-bca9-c38b3534339d@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/hotspot/share/services/threadService.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/services/threadService.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/services/threadService.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/e2043438..d56e9d16

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

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

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

From kevinw at openjdk.org  Tue Jul  1 09:33:31 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 09:33:31 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v7]
In-Reply-To: <S3v8iJ_QO09eaogRj3gdJHH3VxMhtns54y7UFk1E77A=.1cb4eb65-27e5-4eda-a527-49d2a069635d@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
 <S3v8iJ_QO09eaogRj3gdJHH3VxMhtns54y7UFk1E77A=.1cb4eb65-27e5-4eda-a527-49d2a069635d@github.com>
Message-ID: <lGFb9quJSsBL3dnkuwL9N3VuAHYiAv9Ry5XHDuduB0M=.f391c849-e2e8-4987-ac57-6407f5fcd02a@github.com>

On Tue, 1 Jul 2025 03:01:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kevin Walls 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:
>> 
>>  - remove test definition changes
>>  - TLH: use cv_internal_thread_to_JavaThread()
>>  - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
>>  - Test requires: permit linux debug testing
>>  - comment update
>>  - comment update
>>  - newline
>>  - Test fails on minimal VM: require jvmti feature
>>  - Correct THROW macro
>>  - ThreadDumper thread count
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/88ec329a...e2043438
>
> src/hotspot/share/services/threadService.cpp line 1450:
> 
>> 1448: 
>> 1449:   if (!has_javathread && !is_virtual) {
>> 1450:     return nullptr; // thread terminated
> 
> Suggestion:
> 
>     return nullptr; // thread terminated so not of interest
> 
> It took me a lot of backtracking in the Java code to find ThreadContainer which finally stated that only live threads are of interest, so an expanded comment here would help me. ( I was ready to suggest we should be creating a `ThreadSnapshot` that represents the terminated thread.)

Yes, although we could return _something_ for a terminated thread, that seems like a fiction that might do us no good, forgetting it and moving on seems good...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176995651

From sspitsyn at openjdk.org  Tue Jul  1 09:33:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:33:31 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v7]
In-Reply-To: <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
Message-ID: <T4-lRrupxHsqvCHQj7w_VJKuez6kW05_VxrOfZET3F8=.1c34e3c4-e6f8-4236-aa12-b0324b79d973@github.com>

On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls 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:
> 
>  - remove test definition changes
>  - TLH: use cv_internal_thread_to_JavaThread()
>  - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
>  - Test requires: permit linux debug testing
>  - comment update
>  - comment update
>  - newline
>  - Test fails on minimal VM: require jvmti feature
>  - Correct THROW macro
>  - ThreadDumper thread count
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/88ec329a...e2043438

Looks good.

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 172:

> 170:     }
> 171: }
> 172: 

Nit: It seems that an unneeded extra empty line was added at the end of file.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2974497586
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176996670

From duke at openjdk.org  Tue Jul  1 09:39:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 09:39:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8284016: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26014/files
  - new: https://git.openjdk.org/jdk/pull/26014/files/65b9ecc5..bb95404c

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

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

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

From duke at openjdk.org  Tue Jul  1 09:39:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 09:39:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
 <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>
Message-ID: <yWrC1VBRGIs-r9Oas51SV7tkVNITJT5jdTQSUhFpGCI=.8483e927-5e76-4d33-b62e-6ceec8f4b4e5@github.com>

On Tue, 1 Jul 2025 08:46:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284016: Reverted closure names in JVMTI
>
> src/hotspot/share/classfile/javaClasses.cpp line 1980:
> 
>> 1978:   ResourceMark rm(THREAD);
>> 1979:   HandleMark   hm(THREAD);
>> 1980:   GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread));
> 
> Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/prims/whitebox.cpp line 2288:
> 
>> 2286:   };
>> 2287: 
>> 2288:   ReadMonitorsHandshakeClosure rmc;
> 
> Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/prims/whitebox.cpp line 2357:
> 
>> 2355:     bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr);
>> 2356:     if (is_alive) {
>> 2357:       TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target);
> 
> Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/runtime/vmThread.cpp line 456:
> 
>> 454:       if (HandshakeALot) {
>> 455:         MutexUnlocker mul(VMOperation_lock);
>> 456:         ALotOfHandshakeClosure hal_cl;
> 
> Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177016990
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017247
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017485
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017688

From sspitsyn at openjdk.org  Tue Jul  1 09:49:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:49:42 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
 <ClM1eSGgW2ID7_ALYsNbspw55JtNRfyRZKnolmk8j54=.d4d2c8b5-fecd-4c4a-bf3b-eeb3d3a4827b@github.com>
 <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com>
Message-ID: <ZlrJEtw5qnMSMXT2Yd_sEwa9rIoFGThOdQNPd03gcCc=.eddda76d-d924-486e-8681-b21dca97abdd@github.com>

On Tue, 1 Jul 2025 09:26:59 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR.

Is it a specific requirement to create a separate bug for each complain? Normally, one bug for both has to be enough. One bug would be even enough for multiple complains in several files of the same development area.

> Regarding the analyzer, we will rerun the analysis with assert enabled and check if it helps to suppress the analyzer warnings

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023050372
PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023059816

From sspitsyn at openjdk.org  Tue Jul  1 09:53:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:53:39 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <0t5vpK_Z-2WRiRvG6gUsq-wfR6_CUUG4yAwPcxNnPmw=.5c6ef9ce-6fdd-469d-a4c8-bdf8d4eea82d@github.com>

On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
>> 
>> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
>> 
>> Tested in GHA and tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

Thank you for the update. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974608407

From asemenov at openjdk.org  Tue Jul  1 10:14:40 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 1 Jul 2025 10:14:40 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <ZlrJEtw5qnMSMXT2Yd_sEwa9rIoFGThOdQNPd03gcCc=.eddda76d-d924-486e-8681-b21dca97abdd@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
 <ClM1eSGgW2ID7_ALYsNbspw55JtNRfyRZKnolmk8j54=.d4d2c8b5-fecd-4c4a-bf3b-eeb3d3a4827b@github.com>
 <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com>
 <ZlrJEtw5qnMSMXT2Yd_sEwa9rIoFGThOdQNPd03gcCc=.eddda76d-d924-486e-8681-b21dca97abdd@github.com>
Message-ID: <oTBSkYrzPKTaNTSnIrCgCs6g4FFiucnkeX_ROvkzBgA=.b0587588-1112-4aa5-9d86-287fec4dc5ee@github.com>

On Tue, 1 Jul 2025 09:45:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR.
> 
> Is it a specific requirement to create a separate bug for each complain? Normally, one bug for both has to be enough. One bug would be even enough for multiple complains in several files of the same development area.

TNX

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023162703

From kevinw at openjdk.org  Tue Jul  1 10:20:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 10:20:12 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v9]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited
 - Feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/d56e9d16..93ad155d

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

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

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

From adinn at openjdk.org  Tue Jul  1 10:21:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 10:21:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>
Message-ID: <5kA9iwhMigdn2kR4YPyOoF8iM0fn5YbbgbAz4g82NqU=.a5cac722-ead5-418b-b600-69c1215223a9@github.com>

On Tue, 1 Jul 2025 02:10:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hotspot tier1 has passed on linux-riscv64. The riscv part seems fine after a cursory look. Thanks for the ping.

@RealFYang Thanks for the test and review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3023205993

From coleenp at openjdk.org  Tue Jul  1 11:23:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 11:23:45 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <a1tax3OyPoBG25U-Zr3TTbfI4IwzYMCLiiM0F0E1VbI=.428fd292-2861-4bbb-9b44-04bf6b63b1e6@github.com>

On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
>> 
>> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
>> 
>> Tested in GHA and tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

Still looks good.  So the pattern is that something that inherits directly from HandshakeClosure is TheThingHandshakeClosure and in the case of JVMTI further inheritance has a shorter name.  Seems fine.  So many handshakes!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974982990

From mhaessig at openjdk.org  Tue Jul  1 11:27:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 11:27:49 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <U2pkrbJtCOAswOM9iXx8kEf2FQuQZDgedCpf0ZHreh0=.f519ca6c-aa4a-465b-9e11-825c9071afc8@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Backing out #24831 sounds reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3023516324

From ayang at openjdk.org  Tue Jul  1 11:37:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 1 Jul 2025 11:37:43 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v9]
In-Reply-To: <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
Message-ID: <dMLILFioWq8Cs_AhhQpKJRUGHO5Q7Ak2nFqbUdLE10c=.09509e58-11d8-4229-8a25-7f3065a0ad90@github.com>

On Mon, 30 Jun 2025 12:42:11 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1453:

> 1451:     _g1h->increment_total_collections();
> 1452: 
> 1453:     if (_g1h->last_gc_was_periodic()) {

Could you add some comment why this checking is needed? (It's not obvious from the context.)

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 175:

> 173:   assert(cpu_usage_delta >= 0.0, "must be");
> 174: 
> 175:   const double min_scale_factor = G1ShrinkByPercentOfAvailable / 1000.0;

I wonder if this can be written as `min = max / 10`. At first glance, I thought it's a typo, `1000` instead of `100`, but the key msg is that min is 1/10 of max (next line), right?

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 41:

> 39: // GC CPU usage set by the user.
> 40: //
> 41: // The heuristics track both short and long term GC behavior to effect heap resizing.

Typo: "effect" -> "affect".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177256550
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177293569
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2177317790

From coleenp at openjdk.org  Tue Jul  1 11:56:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 11:56:43 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v3]
In-Reply-To: <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
Message-ID: <rjLtwcOvLECLtfX2m1S4tTMMIvQqbzm_gi_p-whVTHc=.266c96fc-6927-4126-9f09-81f61c7526e2@github.com>

On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

This looks great.  Thank you for sorting through all this code and my speculation about the problem to find the real problem.   For the record, I don't think my change to remove is_running_emcp() caused this or any bug. I wrote a test case for it yesterday and that code seems fine.  Nice work finding the real problem here and the straightforward solution.
There are several places in the JVM where we have to check for is_old() methods to exclude them for various things.  is_old() methods leaking into places is a common bug pattern. This change is consistent with this approach of fixing this.

src/hotspot/share/prims/jvmtiImpl.cpp line 262:

> 260:   }
> 261: 
> 262:   // ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit()

Suggestion:

  // Ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit().

src/hotspot/share/prims/jvmtiImpl.cpp line 274:

> 272:   }
> 273: 
> 274:   // ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit()

Suggestion:

  // Ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit().

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2975077594
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2177385911
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2177386666

From duke at openjdk.org  Tue Jul  1 12:19:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Jul 2025 12:19:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <vp8I3MWFyOjF8XR7NIIb4ZvRIJVOXuxB0nX32VhZoS4=.0db2c1c9-fd1f-4938-981f-5d5c4ba31ace@github.com>

On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
>> 
>> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
>> 
>> Tested in GHA and tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

@toxaart 
Your change (at version bb95404ced78f32f161bc1982def196a6bde6f30) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26014#issuecomment-3023766086

From iwalulya at openjdk.org  Tue Jul  1 12:33:22 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 1 Jul 2025 12:33:22 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v10]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <435Jyl8OLAtEIrTNAp151LApVhXiN-2D_Xfhnm9sOvA=.77728335-e46f-4bfe-808b-ae1593b5fdd7@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/88434073..b62c827e

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

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

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

From coleenp at openjdk.org  Tue Jul  1 12:33:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 12:33:45 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
Message-ID: <03QoDXp-rOR3n546DRKYfDabRcdMYUOI8wCnINdW69Y=.c6fca915-9dc2-4737-92d1-a09c27babae9@github.com>

On Mon, 26 May 2025 08:56:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
> 
> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
> 
> Testing
>  - new test
>  - Tiers 1-4 (sanity)

Cool test. Looks fine.  I had some earlier comments but nothing that would really improve the change.

src/hotspot/share/prims/jniCheck.cpp line 400:

> 398:   if (orig_result == STRING_TAG || orig_result == STRING_UTF_TAG) {
> 399:     bool was_utf = orig_result == STRING_UTF_TAG;
> 400:     tty->print_cr("%s: called on something allocated by %s",

Can you use log_warning(memory) for this message rather than tty?
Maybe these should be tty since they're in jniCheck.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25444#pullrequestreview-2975217066
PR Review Comment: https://git.openjdk.org/jdk/pull/25444#discussion_r2177467112

From coleenp at openjdk.org  Tue Jul  1 12:33:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 12:33:46 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <PT1_XgXnar6hx2uKNo5YWew274xAEzeGs9I8CZPV_Ug=.709283de-e0ed-4e0b-a93b-6cb65f95e96a@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
 <7yKgOu_xQq36unKaBPVvMwJSwosu2nYN3DUwgFQtxqI=.6d563f83-b139-41ce-8dce-9d727132e82f@github.com>
 <PT1_XgXnar6hx2uKNo5YWew274xAEzeGs9I8CZPV_Ug=.709283de-e0ed-4e0b-a93b-6cb65f95e96a@github.com>
Message-ID: <E55CL4Mkkq44dpX8i70tphYmaBYjwdgdeuct-LolAcY=.cf823f81-037d-4f44-a415-ec9dc16501ed@github.com>

On Thu, 29 May 2025 03:45:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/jniCheck.cpp line 357:
>> 
>>> 355: 
>>> 356: // Arbitrary (but well-known) tag for GetStringUTFChars
>>> 357: const void* STRING_UTF_TAG = (void*) 0x48124812;
>> 
>> Why is this well-known?  This ending in 12 could be an address, do you not want to make this a possible address?
>
> These are "well-known" by this code. Note I just moved these definitions, I did not invent them.

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25444#discussion_r2177475101

From asemenov at openjdk.org  Tue Jul  1 12:49:39 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 1 Jul 2025 12:49:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <Sgk3eIEfEprxu8kO6QLoT-wKQ8-gbsoomhzfmVErYWA=.2ff58080-7f8e-4c7e-af22-c6605549ec68@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
 <Sgk3eIEfEprxu8kO6QLoT-wKQ8-gbsoomhzfmVErYWA=.2ff58080-7f8e-4c7e-af22-c6605549ec68@github.com>
Message-ID: <HZNNnsTX7jSlESIO8pg0MHLL-Davc6evHan3SxCk0F4=.6a5e3ede-2203-4545-84df-386d9a58edaa@github.com>

On Tue, 1 Jul 2025 03:13:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Same with the other assertion please. Though as @plummercj states I don't see how this will help with the static analysis tool.

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26002#discussion_r2177518930

From adinn at openjdk.org  Tue Jul  1 13:18:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 13:18:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <rR2tUrdK33SZmLZTOUjoAysdVZpYDDIX8Mufn2qqCHA=.fecff99f-baee-4dc0-967b-14baa3bbb52f@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar I'm stumped as to why this could be causing any problem on s390x. The error you are seeing appears to be in happening under frame::next_frame during lookup of the parent frame for the call stub frame. That occurs when printing the 'Native frames' part of the hs_err file content.

If I run my build on an s390 box I don't see that error. The frames are printed to the file as expected. Neither can I see any way in which the changes I have made could influence the stack walk code. They do not change the frame size and layout.

@TheRealMDoerr Would you be able to run hotspot jtreg test runtime/ErrorHandling/MachCodeFramesInErrorFile.java on an s390 box and see if you can reproduce the error that @offamitkumar is seeing?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3023980729

From mdoerr at openjdk.org  Tue Jul  1 14:08:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 14:08:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar: Is the crash you reported reproducible? Could it be that `save_return_pc()` is missing in `address generate_call_stub(address& return_address)`? PPC64 has it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3024189963

From adinn at openjdk.org  Tue Jul  1 14:35:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 14:35:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
 <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>
Message-ID: <yxvoSFrkPR6J4ZDwnIZWtB3HCkNsDwvr33WTt5jQGoU=.dfd771ee-a131-4aa4-ba7e-a9fdb2efdec4@github.com>

On Tue, 1 Jul 2025 14:05:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.
>
> @offamitkumar: Is the crash you reported reproducible? Could it be that `save_return_pc()` is missing in `address generate_call_stub(address& return_address)`? PPC64 has it.

@TheRealMDoerr Hmm, that might possibly be it. It could explain why I am not seeing the error and @offamitkumar is (the failure will depend on what happens to be left lying in the saved PC register). What do you think, Amit?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3024306793

From duke at openjdk.org  Tue Jul  1 15:09:12 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 15:09:12 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
Message-ID: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>

Hi, please consider the following changes:

this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 

The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 

Tested in tiers 1-3 and GHA.

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

Commit messages:
 - 8320353: Fixed comment
 - 8320353: Fixed whitespace error
 - 8320353:  Fiixed build problem
 - 8320353: Added debug only case
 - 8320353: More work
 - 8320353: More work
 - 8320353: Reenabled stringop-overflow warning for linux zero/fastdebug

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

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

From kvn at openjdk.org  Tue Jul  1 15:45:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 1 Jul 2025 15:45:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
Message-ID: <3wvWU3L2EeptYlaNLcut7IaxLUTfY_eWbqzeQu-otu8=.36da587e-8a53-438a-8c95-349e9d8fb636@github.com>

On Tue, 1 Jul 2025 09:11:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix formatting issues

My testing passed. Thank you for addressing my comments.

I assume you will address s390 issue before integration.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2976000297

From lmesnik at openjdk.org  Tue Jul  1 16:01:10 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 16:01:10 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v4]
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com>

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/prims/jvmtiImpl.cpp
   
   Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>
 - Update src/hotspot/share/prims/jvmtiImpl.cpp
   
   Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26031/files
  - new: https://git.openjdk.org/jdk/pull/26031/files/c7aaa804..242880c5

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

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

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

From lmesnik at openjdk.org  Tue Jul  1 16:02:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 16:02:53 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v3]
In-Reply-To: <rjLtwcOvLECLtfX2m1S4tTMMIvQqbzm_gi_p-whVTHc=.266c96fc-6927-4126-9f09-81f61c7526e2@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <n6zzc13sbxIJugjqzk7ZfS3jKd2KhKKvRiayB6O8oM8=.87e077b4-df76-4a1b-8402-55c391df4543@github.com>
 <rjLtwcOvLECLtfX2m1S4tTMMIvQqbzm_gi_p-whVTHc=.266c96fc-6927-4126-9f09-81f61c7526e2@github.com>
Message-ID: <p7CXGzGl0NJwOsmNvT6TJKX4ke6DCPOcB-CtjyNOtiM=.96afefc4-49af-408e-adb0-d7d4610d10e1@github.com>

On Tue, 1 Jul 2025 11:54:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> This looks great.  Thank you for sorting through all this code and my speculation about the problem to find the real problem.   For the record, I don't think my change to remove is_running_emcp() caused this or any bug. I wrote a test case for it yesterday and that code seems fine.  Nice work finding the real problem here and the straightforward solution.
> There are several places in the JVM where we have to check for is_old() methods to exclude them for various things.  is_old() methods leaking into places is a common bug pattern. This change is consistent with this approach of fixing this.

@coleenp Thanks. When I mention that your change is related to this problem,  I meant related to this area. The change was correct and bug existed before.
@dholmes-ora , @sspitsyn  Thank you for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3024630778

From coleenp at openjdk.org  Tue Jul  1 17:10:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 17:10:39 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v4]
In-Reply-To: <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com>
Message-ID: <4ExBfUTBQLZWCprnXZKNIkm-62cqdVmFQ2yu2ki6L_M=.b507f587-58c6-4003-845a-bdfca6844302@github.com>

On Tue, 1 Jul 2025 16:01:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>
>  - Update src/hotspot/share/prims/jvmtiImpl.cpp
>    
>    Co-authored-by: Coleen Phillimore <coleen.phillimore at oracle.com>

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2976297700

From lmesnik at openjdk.org  Tue Jul  1 17:25:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 17:25:44 GMT
Subject: Integrated: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <8IAR00IghKe6-kHzqImCF0nEG0EV-q6bkf5XeWR5ctA=.68e19495-8c9e-4844-98f7-60c355ea8fa9@github.com>

On Sat, 28 Jun 2025 05:02:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

This pull request has now been integrated.

Changeset: 282ee40a
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/282ee40a56af46521b94fe6e4c90e78b8f513b29
Stats:     14 lines in 1 file changed: 14 ins; 0 del; 0 mod

8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint

Reviewed-by: coleenp, dholmes, sspitsyn

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

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

From shade at openjdk.org  Tue Jul  1 17:47:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 17:47:40 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v2]
In-Reply-To: <XKlF2wvzr3VvuWEhNS1UtoQYXydutUd3ZDfP3b_bcAU=.d2446bf6-8766-4490-9486-e7de1ed53a39@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <XKlF2wvzr3VvuWEhNS1UtoQYXydutUd3ZDfP3b_bcAU=.d2446bf6-8766-4490-9486-e7de1ed53a39@github.com>
Message-ID: <Rg94VnBKCxnujfiLTdRHxkFcag7BpYKqGFVkVSlZ8ps=.3bddf64f-8383-4d02-8594-ecdd6c0e4ee4@github.com>

On Fri, 27 Jun 2025 16:01:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam 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 branch 'master' into 8358680-aot-cache-creation-fails-with-no-strings-should-have-been-added
>  - @coleenp comment: change items_count() to items_count_acquire()
>  - 8358680: AOT cache creation fails: no strings should have been added

Yes, as we discussed offline, there seem to be no better solution for JDK 25 than this. Awkward as it is.

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

PR Review: https://git.openjdk.org/jdk/pull/25816#pullrequestreview-2976418730

From shade at openjdk.org  Tue Jul  1 17:47:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 17:47:40 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v2]
In-Reply-To: <IZRVcB8uIgRLskOLSzxx-WCScOPexe6Vl7gwyy6sok4=.94cb49b5-c45c-4d15-bf69-03243bb178ec@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <KloqWSOIKfPPqxMGqJqx5U_-ToWV8zdP0_jAK4fXZEE=.77db5c0e-ba38-4b12-9baf-efecb04302b3@github.com>
 <IZRVcB8uIgRLskOLSzxx-WCScOPexe6Vl7gwyy6sok4=.94cb49b5-c45c-4d15-bf69-03243bb178ec@github.com>
Message-ID: <XXO8yvzSjFOZgp1cfvEgRYasM9omh8Q9pl9Niy4THEU=.1710fb6d-df3d-42e7-a0d8-8acb7df99710@github.com>

On Fri, 27 Jun 2025 15:47:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/stringTable.cpp line 970:
>> 
>>> 968:   // This flag will be cleared after intern table dumping has completed, so we can run the
>>> 969:   // compiler again (for future AOT method compilation, etc).
>>> 970:   DEBUG_ONLY(Atomic::release_store(&_disable_interning_during_cds_dump, 1));
>> 
>> I think atomics work with bool or is this a refcount ?
>
> I tried to changed to a `bool` but Atomics doesn't like that. I got an compilation error.

Atomics are supposed to work with `bool`-s. I looked around, and this was the first hit:
https://github.com/openjdk/jdk/blob/282ee40a56af46521b94fe6e4c90e78b8f513b29/src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp#L60

Also, I just tried to switch `_disable_interning_during_cds_dump` to `bool` in this PR branch, and it worked at least on Linux x86_64. Can you try again and post what compilation error you are seeing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25816#discussion_r2178199104

From psandoz at openjdk.org  Tue Jul  1 18:06:45 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 1 Jul 2025 18:06:45 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Address review comments
>  - Merge 'jdk:master' into JDK-8355563
>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API

Marked as reviewed by psandoz (Reviewer).

This is a nice simplification, Java changes look good. I'll let the Intel folks sign-off related to regressions. IMO minor regressions like this are acceptable if the generated code quality is good, and if the benchmark reports higher variance and averaging results from multiple forks close the gap. (In this case i don't understand how the Java changes impacts alignment).

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

PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2976493924
PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3025029477

From kevinw at openjdk.org  Tue Jul  1 18:20:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 18:20:41 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v9]
In-Reply-To: <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
Message-ID: <lacHr8bl1HEKiGIz0lT8qsDA6PBoyMy907mPibiHwjk=.b406c64b-577c-4e15-a27d-a297eb9bcf27@github.com>

On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited
>  - Feedback

Thanks for all the feedback and reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3025066011

From iklam at openjdk.org  Tue Jul  1 18:26:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 18:26:57 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v3]
In-Reply-To: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
Message-ID: <72Pw1wW68nGAY9-FYyMD2RI1qXn0qjMP5Oibzb5qiXA=.e6a2e239-938a-4ebf-a4b9-77d65a03d20c@github.com>

> Background: when writing the string table in the AOT cache, we do this:
> 
> 1. Find out the number of strings in the interned string table
> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
> 3. Enter safepoint
> 4. Copy the strings into the arrays
> 
> This bug happened because:
> 
> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
> - JIT compiler threads may create more interned strings after step 1
> 
> This PR attempts to fix both issues.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Use bool for _disable_interning_during_cds_dump

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25816/files
  - new: https://git.openjdk.org/jdk/pull/25816/files/94a64f97..57ceaa9c

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

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

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

From iklam at openjdk.org  Tue Jul  1 18:26:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 18:26:58 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v2]
In-Reply-To: <XKlF2wvzr3VvuWEhNS1UtoQYXydutUd3ZDfP3b_bcAU=.d2446bf6-8766-4490-9486-e7de1ed53a39@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <XKlF2wvzr3VvuWEhNS1UtoQYXydutUd3ZDfP3b_bcAU=.d2446bf6-8766-4490-9486-e7de1ed53a39@github.com>
Message-ID: <uh9EOrSkNG4_Igyk5ZLjgzyLauy9eqZM37vmsAzxYxI=.690b479b-99ba-4a35-9409-c040c4b3e1e2@github.com>

On Fri, 27 Jun 2025 16:01:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam 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 branch 'master' into 8358680-aot-cache-creation-fails-with-no-strings-should-have-been-added
>  - @coleenp comment: change items_count() to items_count_acquire()
>  - 8358680: AOT cache creation fails: no strings should have been added

> Atomics are supposed to work with bool

I updated the code to use `bool` instead. What I did wrong was I used `0` instead of `false, and the templates didn't like it.


Atomic::release_store(&_disable_interning_during_cds_dump, 0)

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

PR Comment: https://git.openjdk.org/jdk/pull/25816#issuecomment-3025089027

From shade at openjdk.org  Tue Jul  1 18:30:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Jul 2025 18:30:40 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v3]
In-Reply-To: <72Pw1wW68nGAY9-FYyMD2RI1qXn0qjMP5Oibzb5qiXA=.e6a2e239-938a-4ebf-a4b9-77d65a03d20c@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <72Pw1wW68nGAY9-FYyMD2RI1qXn0qjMP5Oibzb5qiXA=.e6a2e239-938a-4ebf-a4b9-77d65a03d20c@github.com>
Message-ID: <T4v60OFjAK_IZF6RLNbAuCijA3HNVbu7_-RDMmcFzkg=.0373fcfd-9602-452b-a5e0-700458125519@github.com>

On Tue, 1 Jul 2025 18:26:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use bool for _disable_interning_during_cds_dump

All right. Someone else needs to approve as well, if we are pulling this into JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25816#pullrequestreview-2976574469

From ihse at openjdk.org  Tue Jul  1 19:04:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 19:04:37 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <bxWyyE5VCVY0EhzEwu3fgOwoK1g1eH-1ar3VEE2RbHw=.30e71e59-041e-4280-8b11-ce40bf154990@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Build changes look good. Someone else will have to review the hotspot changes.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2976656855

From amenkov at openjdk.org  Tue Jul  1 19:07:42 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Jul 2025 19:07:42 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v9]
In-Reply-To: <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
Message-ID: <aU07KWk8WJO3aFlkFWsVFN0-zCAiYzjVuwr8tGJUWzg=.1b8ced11-9b76-40da-b683-7e33a3a86f17@github.com>

On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited
>  - Feedback

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2976663584

From kevinw at openjdk.org  Tue Jul  1 19:10:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 19:10:47 GMT
Subject: Integrated: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <yq5E2QhMqYI_3HtFtm0UESqCaAN-EcF3MogqaGUXjaI=.26161a8e-ae49-49dc-87b2-3505da7d9174@github.com>

On Tue, 24 Jun 2025 17:00:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

This pull request has now been integrated.

Changeset: 13a39278
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13a3927855da61fe27f3b43e5e4755d0c5ac5a16
Stats:     32 lines in 5 files changed: 22 ins; 2 del; 8 mod

8359870: JVM crashes in AccessInternal::PostRuntimeDispatch

Reviewed-by: amenkov, dholmes, sspitsyn

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

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

From sparasa at openjdk.org  Tue Jul  1 19:14:40 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 1 Jul 2025 19:14:40 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <AwzZvbH8VQnQXGR5XI3Glcx81TBqOCFiK4ccbhsBRBI=.9cc10e57-0853-4407-b393-38edf06f2c45@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

Hi Emanuel (@eme64),

Would it be possible to test this PR?
Please let me know.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3025218887

From iklam at openjdk.org  Tue Jul  1 20:33:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Jul 2025 20:33:15 GMT
Subject: RFR: 8361215: Add AOT test case: verification constraint classes are
 excluded
Message-ID: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>

If the AOT cache contains a class like this:


class A {
    X foo() {
        return new Y();
    }
}

A will be stored with the following verification constraint:

- `X` must be a supertype of `Y`

This constraint is checked when class `A` is linked.

I added a test case for this scenario to make sure it works properly even when `X` and/or `Y` are excluded from the AOT cache.

I also fixed some pre-existing problems with test exclusion and logging.

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

Commit messages:
 - 8361215: Add AOT test case: verification constraint classes are excluded

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

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

From sparasa at openjdk.org  Tue Jul  1 21:27:40 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 1 Jul 2025 21:27:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <gGuAmunp7iklHitMz-TnjUMQCRBkNdO3AjFOUFP8g6w=.fae3b2fd-2a6c-4760-bdc4-92baaa6bc2b7@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Hi Emanuel (@eme64),

This PR is also ready for integration. Would it be possible for you to run the tests?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3025582589

From sparasa at openjdk.org  Tue Jul  1 21:27:41 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 1 Jul 2025 21:27:41 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>
Message-ID: <uevWlHqvKsXKPns_8xW4zmkLMspTCrOOhobTheDNJ6c=.f7373020-1e23-400f-85ef-00e25439947c@github.com>

On Tue, 1 Jul 2025 06:04:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore the orginal contents of rax
>
> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 387:
> 
>> 385:     __ movptr(Address(rsp, (--slot) * wordSize), r29);
>> 386:     __ movptr(Address(rsp, (--slot) * wordSize), r30);
>> 387:     __ movptr(Address(rsp, (--slot) * wordSize), r31);
> 
> I think you should use pushp2 / pop2p for these instructions also , maybe it can be handled along with 
> https://github.com/openjdk/jdk/pull/25889

Thanks Jatin (@jatin-bhateja) for the review and approval! This modification will be pursued in another PR (say #25889).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2178557739

From sviswanathan at openjdk.org  Tue Jul  1 21:33:44 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Jul 2025 21:33:44 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Address review comments
>  - Merge 'jdk:master' into JDK-8355563
>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API

Marked as reviewed by sviswanathan (Reviewer).

Agree with  Paul, these are minor regressions. Let us proceed with this patch.

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

PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2977019367
PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3025596784

From liach at openjdk.org  Tue Jul  1 23:03:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Jul 2025 23:03:32 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v4]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Stage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/9ec3d2e3..181c6f27

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

  Stats: 341 lines in 41 files changed: 159 ins; 94 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

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

From liach at openjdk.org  Tue Jul  1 23:20:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Jul 2025 23:20:59 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v5]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Reviewed the diff on github

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/181c6f27..d5a54f5b

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

  Stats: 19 lines in 9 files changed: 9 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

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

From liach at openjdk.org  Tue Jul  1 23:20:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Jul 2025 23:20:59 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v4]
In-Reply-To: <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>
Message-ID: <gMjLTwD4DFZxwbtzqPuAPG_iwKql4n_xpFddnwjcaio=.a8fca49f-f5d9-4449-845d-c388b6dac7dd@github.com>

On Tue, 1 Jul 2025 23:03:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stage

Turns out the current class initializer annotation is still quite restricted to MH - this means we will for now not merge this with the runtime setup annotation. I also added verification in classFileParser for runtimeSetup annotated methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3025824157

From ccheung at openjdk.org  Tue Jul  1 23:58:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Jul 2025 23:58:38 GMT
Subject: RFR: 8361215: Add AOT test case: verification constraint classes
 are excluded
In-Reply-To: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>
References: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>
Message-ID: <CesZfjBET8iK1GBEc9e9x1SCX1p8XlvzHxjIlrG4Fz4=.b33c3d76-f2f1-4596-b9bf-db98f61eb887@github.com>

On Tue, 1 Jul 2025 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> If the AOT cache contains a class like this:
> 
> 
> class A {
>     X foo() {
>         return new Y();
>     }
> }
> 
> A will be stored with the following verification constraint:
> 
> - `X` must be a supertype of `Y`
> 
> This constraint is checked when class `A` is linked.
> 
> I added a test case for this scenario to make sure it works properly even when `X` and/or `Y` are excluded from the AOT cache.
> 
> I also fixed some pre-existing problems with test exclusion and logging.

Looks good.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26079#pullrequestreview-2977249631

From sviswanathan at openjdk.org  Wed Jul  2 00:04:39 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 2 Jul 2025 00:04:39 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v5]
In-Reply-To: <zQiBVSPt9UMJcaJ3HIzP9iip2Qq99WcLLmVLl033UA8=.35b03101-f58a-4aca-b138-99e5ec364ec7@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <zQiBVSPt9UMJcaJ3HIzP9iip2Qq99WcLLmVLl033UA8=.35b03101-f58a-4aca-b138-99e5ec364ec7@github.com>
Message-ID: <wm7lJX1a0tOGWLu8BN7GRTXYCDVMPtJ5ST2JKKcPpuc=.6fa0cd79-2bcf-4466-9e0f-a23cfecef445@github.com>

On Mon, 30 Jun 2025 08:38:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Intel@ AVX10 ISA [1] extensions added new floating point MIN/MAX instructions which comply with definitions in IEEE-754-2019 standard section 9.6 and can directly emulate Math.min/max semantics without the need for any special handling for NaN, +0.0 or -0.0 detection.
>> 
>> **The following pseudo-code describes the existing algorithm for min/max[FD]:**
>> 
>> Move the non-negative value to the second operand; this will ensure that we correctly handle 0.0 and -0.0 values, if values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. Existing MINPS and MAXPS semantics only check for NaN as the second operand; hence, we need special handling to check for NaN at the first operand.
>> 
>>   btmp = (b < +0.0) ? a : b
>>   atmp = (b < +0.0) ? b : a
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> For min[FD] we need a small tweak in the above algorithm, i.e., move the non-negative value to the first operand, this will ensure that we correctly select -0.0 if both the operands being compared are 0.0 or -0.0.
>> 
>>   btmp = (b < +0.0) ? b : a
>>   atmp = (b < +0.0) ? a : b
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> Thus, we need additional special handling for NaNs and +/-0.0 to compute floating-point min/max values to comply with the semantics of Math.max/min APIs using existing MINPS / MAXPS instructions. AVX10.2 added a new instruction, VPMINMAX[SH,SS,SD]/[PH,PS,PD], which comprehensively handles special cases, thereby eliminating the need for special handling.
>> 
>> Patch emits new instructions for reduction and non-reduction operations for single, double, and Float16 type.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/cpu/x86/x86_64.ad
>    
>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>  - Update src/hotspot/cpu/x86/x86_64.ad
>    
>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>

src/hotspot/cpu/x86/assembler_x86.cpp line 8800:

> 8798:   attributes.set_is_evex_instruction();
> 8799:   attributes.set_embedded_opmask_register_specifier(mask);
> 8800:   attributes.set_address_attributes(/* tuple_type */ EVEX_FVM, /* input_size_in_bits */ EVEX_NObit);

It looks to me that the tuple_type should be EVEX_FV for all of evminmax ps, pd, ph.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25914#discussion_r2178735442

From kbarrett at openjdk.org  Wed Jul  2 00:19:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:19:43 GMT
Subject: RFR: 8346914: UB issue in scalbnA
In-Reply-To: <V8YFBfRf8QHlXuDMKu-oBmzfpVsGQkMyDazGd8txq58=.3aac8e61-5cac-44de-ae4f-76452c3c0365@github.com>
References: <in6uOP73K4zvwEiEWc8K8o426BQ3QMK4pMNmNQWe2m0=.05bb06d3-0e1b-4af3-80c4-a064664973fb@github.com>
 <V8YFBfRf8QHlXuDMKu-oBmzfpVsGQkMyDazGd8txq58=.3aac8e61-5cac-44de-ae4f-76452c3c0365@github.com>
Message-ID: <Cv1lfEzj88BDm4Wf2Fb3mBrMT5L9emCzzn1dvKTT5yQ=.301735c3-2edc-42f5-86e3-ef3ac04a519d@github.com>

On Sat, 21 Jun 2025 12:18:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Please review this change that replaces uses of our scalbnA function with
>> using the standard scalbn function. Removed scalbnA, and also copysignA.
>> 
>> For more details, see first comment and JBS.
>> 
>> Testing: mach5 tier1-6. Though from discussion in
>> https://github.com/openjdk/jdk/pull/25656, it's hard to get to our uses of
>> scalbn/scalbnA.
>> 
>> Before removing it, I tested scalbnA via a gtest that is attached to the JBS
>> issue.
>
> That makes sense.

Thanks for reviews @theRealAph and @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/25917#issuecomment-3025900519

From kbarrett at openjdk.org  Wed Jul  2 00:19:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 00:19:43 GMT
Subject: Integrated: 8346914: UB issue in scalbnA
In-Reply-To: <in6uOP73K4zvwEiEWc8K8o426BQ3QMK4pMNmNQWe2m0=.05bb06d3-0e1b-4af3-80c4-a064664973fb@github.com>
References: <in6uOP73K4zvwEiEWc8K8o426BQ3QMK4pMNmNQWe2m0=.05bb06d3-0e1b-4af3-80c4-a064664973fb@github.com>
Message-ID: <xrdV86FGraiv4P9T8GFKP1DFKKMeIONw6pRSxcdAPpk=.846cc621-6871-49d4-b608-a65339eb7b45@github.com>

On Fri, 20 Jun 2025 16:06:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that replaces uses of our scalbnA function with
> using the standard scalbn function. Removed scalbnA, and also copysignA.
> 
> For more details, see first comment and JBS.
> 
> Testing: mach5 tier1-6. Though from discussion in
> https://github.com/openjdk/jdk/pull/25656, it's hard to get to our uses of
> scalbn/scalbnA.
> 
> Before removing it, I tested scalbnA via a gtest that is attached to the JBS
> issue.

This pull request has now been integrated.

Changeset: a910b20b
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a910b20b51157d8f36418bd60b328193ebfb502e
Stats:     67 lines in 4 files changed: 0 ins; 55 del; 12 mod

8346914: UB issue in scalbnA

Reviewed-by: aph, tschatzl

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

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

From sviswanathan at openjdk.org  Wed Jul  2 00:31:41 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 2 Jul 2025 00:31:41 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v5]
In-Reply-To: <wm7lJX1a0tOGWLu8BN7GRTXYCDVMPtJ5ST2JKKcPpuc=.6fa0cd79-2bcf-4466-9e0f-a23cfecef445@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <zQiBVSPt9UMJcaJ3HIzP9iip2Qq99WcLLmVLl033UA8=.35b03101-f58a-4aca-b138-99e5ec364ec7@github.com>
 <wm7lJX1a0tOGWLu8BN7GRTXYCDVMPtJ5ST2JKKcPpuc=.6fa0cd79-2bcf-4466-9e0f-a23cfecef445@github.com>
Message-ID: <XLdvZD2ulCaUQWUmURNRYzTFSzXJSq_yg1aP3mP6Ssk=.ef0ca046-b53c-45bd-b68a-01e2d30184fc@github.com>

On Tue, 1 Jul 2025 23:49:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/x86/x86_64.ad
>>    
>>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>>  - Update src/hotspot/cpu/x86/x86_64.ad
>>    
>>    Co-authored-by: Manuel H?ssig <manuel at haessig.org>
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8800:
> 
>> 8798:   attributes.set_is_evex_instruction();
>> 8799:   attributes.set_embedded_opmask_register_specifier(mask);
>> 8800:   attributes.set_address_attributes(/* tuple_type */ EVEX_FVM, /* input_size_in_bits */ EVEX_NObit);
> 
> It looks to me that the tuple_type should be EVEX_FV for all of evminmax ps, pd, ph.

Other than that the rest of the PR looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25914#discussion_r2178762877

From xgong at openjdk.org  Wed Jul  2 01:54:50 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 2 Jul 2025 01:54:50 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>
Message-ID: <ImOVwSUN4QJIyz7QACAltEr2IBpPrqt3uG4ePZ-ARwk=.9911135e-4bd4-410d-8699-ac1d8e7b94e8@github.com>

On Tue, 1 Jul 2025 18:03:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This is a nice simplification, Java changes look good. I'll let the Intel folks sign-off related to regressions. IMO minor regressions like this are acceptable if the generated code quality is good, and if the benchmark reports higher variance and averaging results from multiple forks close the gap. (In this case i don't understand how the Java changes impacts alignment).

Thanks for your review and comments @PaulSandoz ! The java changes in this patch makes the outer loop in test not be peeled as before since all the range checks or branches are hoisted out side of the loop. While it needs one iteration of loop peeling to eliminate branches before. I think this makes the whole generated code's layout changes a lot.

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026080127

From xgong at openjdk.org  Wed Jul  2 01:54:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 2 Jul 2025 01:54:51 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
Message-ID: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>

On Tue, 1 Jul 2025 21:30:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Agree with Paul, these are minor regressions. Let us proceed with this patch.

Thanks so much for your review @sviswa7 !

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026080679

From amenkov at openjdk.org  Wed Jul  2 01:55:48 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 2 Jul 2025 01:55:48 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors
Message-ID: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>

Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.

The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
Iterator now needs only single pointer to next agent.
Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).

Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/26083/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355960
  Stats: 83 lines in 5 files changed: 27 ins; 28 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/26083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083

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

From jbhateja at openjdk.org  Wed Jul  2 01:57:46 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Jul 2025 01:57:46 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v6]
In-Reply-To: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
Message-ID: <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>

> Intel@ AVX10 ISA [1] extensions added new floating point MIN/MAX instructions which comply with definitions in IEEE-754-2019 standard section 9.6 and can directly emulate Math.min/max semantics without the need for any special handling for NaN, +0.0 or -0.0 detection.
> 
> **The following pseudo-code describes the existing algorithm for min/max[FD]:**
> 
> Move the non-negative value to the second operand; this will ensure that we correctly handle 0.0 and -0.0 values, if values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. Existing MINPS and MAXPS semantics only check for NaN as the second operand; hence, we need special handling to check for NaN at the first operand.
> 
>   btmp = (b < +0.0) ? a : b
>   atmp = (b < +0.0) ? b : a
>   Tmp = Max_Float(atmp , btmp)
>   Res = (atmp == NaN) ? atmp : Tmp
> 
> For min[FD] we need a small tweak in the above algorithm, i.e., move the non-negative value to the first operand, this will ensure that we correctly select -0.0 if both the operands being compared are 0.0 or -0.0.
> 
>   btmp = (b < +0.0) ? b : a
>   atmp = (b < +0.0) ? a : b
>   Tmp = Max_Float(atmp , btmp)
>   Res = (atmp == NaN) ? atmp : Tmp
> 
> Thus, we need additional special handling for NaNs and +/-0.0 to compute floating-point min/max values to comply with the semantics of Math.max/min APIs using existing MINPS / MAXPS instructions. AVX10.2 added a new instruction, VPMINMAX[SH,SS,SD]/[PH,PS,PD], which comprehensively handles special cases, thereby eliminating the need for special handling.
> 
> Patch emits new instructions for reduction and non-reduction operations for single, double, and Float16 type.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Sandhya's review comments resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25914/files
  - new: https://git.openjdk.org/jdk/pull/25914/files/5597b615..3854a871

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

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

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

From jbhateja at openjdk.org  Wed Jul  2 02:04:41 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Jul 2025 02:04:41 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v5]
In-Reply-To: <XLdvZD2ulCaUQWUmURNRYzTFSzXJSq_yg1aP3mP6Ssk=.ef0ca046-b53c-45bd-b68a-01e2d30184fc@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <zQiBVSPt9UMJcaJ3HIzP9iip2Qq99WcLLmVLl033UA8=.35b03101-f58a-4aca-b138-99e5ec364ec7@github.com>
 <wm7lJX1a0tOGWLu8BN7GRTXYCDVMPtJ5ST2JKKcPpuc=.6fa0cd79-2bcf-4466-9e0f-a23cfecef445@github.com>
 <XLdvZD2ulCaUQWUmURNRYzTFSzXJSq_yg1aP3mP6Ssk=.ef0ca046-b53c-45bd-b68a-01e2d30184fc@github.com>
Message-ID: <C-rireZ0-JqjSxaWNoMhMcfm5RBmkFUEqtx7hQe8aHI=.04acc9b3-ad6d-41db-8ff3-1f0aa10a6635@github.com>

On Wed, 2 Jul 2025 00:29:02 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 8800:
>> 
>>> 8798:   attributes.set_is_evex_instruction();
>>> 8799:   attributes.set_embedded_opmask_register_specifier(mask);
>>> 8800:   attributes.set_address_attributes(/* tuple_type */ EVEX_FVM, /* input_size_in_bits */ EVEX_NObit);
>> 
>> It looks to me that the tuple_type should be EVEX_FV for all of evminmax ps, pd, ph.
>
> Other than that the rest of the PR looks good to me.

> It looks to me that the tuple_type should be EVEX_FV for all of evminmax ps, pd, ph.

Yes, all these new vector instructions do have embedded broadcast variants. We don't use them currently,  in the absence of embedded broadcasting, the scalar factor (N) selection for compressed disp8 displacement is the same for both EVEX_FV and EVEX_FVM tuple types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25914#discussion_r2178831749

From iklam at openjdk.org  Wed Jul  2 04:27:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 04:27:46 GMT
Subject: RFR: 8361215: Add AOT test case: verification constraint classes
 are excluded
In-Reply-To: <CesZfjBET8iK1GBEc9e9x1SCX1p8XlvzHxjIlrG4Fz4=.b33c3d76-f2f1-4596-b9bf-db98f61eb887@github.com>
References: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>
 <CesZfjBET8iK1GBEc9e9x1SCX1p8XlvzHxjIlrG4Fz4=.b33c3d76-f2f1-4596-b9bf-db98f61eb887@github.com>
Message-ID: <21o_hvaQsa1tduEIRUit5PRHpnOUg3g5g0-7yZ_jXaQ=.f30c83f6-6be6-4c77-a25f-178e97efd55d@github.com>

On Tue, 1 Jul 2025 23:56:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> If the AOT cache contains a class like this:
>> 
>> 
>> class A {
>>     X foo() {
>>         return new Y();
>>     }
>> }
>> 
>> A will be stored with the following verification constraint:
>> 
>> - `X` must be a supertype of `Y`
>> 
>> This constraint is checked when class `A` is linked.
>> 
>> I added a test case for this scenario to make sure it works properly even when `X` and/or `Y` are excluded from the AOT cache.
>> 
>> I also fixed some pre-existing problems with test exclusion and logging.
>
> Looks good.

Thanks @calvinccheung for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26079#issuecomment-3026371466

From iklam at openjdk.org  Wed Jul  2 04:27:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 04:27:47 GMT
Subject: Integrated: 8361215: Add AOT test case: verification constraint
 classes are excluded
In-Reply-To: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>
References: <BUReN3NQ_MizRXhSJB2QI9DlEvZfzr4lXY343fsoSaY=.d3dc44d8-64c6-4f25-8af7-3576b066f7cd@github.com>
Message-ID: <8PHdopSpqbQu4dAfpQhSLXoTxJuyFJDtYb9w0MkFsw0=.da188fc6-4856-4465-bcd6-0a5eb56aa68c@github.com>

On Tue, 1 Jul 2025 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> If the AOT cache contains a class like this:
> 
> 
> class A {
>     X foo() {
>         return new Y();
>     }
> }
> 
> A will be stored with the following verification constraint:
> 
> - `X` must be a supertype of `Y`
> 
> This constraint is checked when class `A` is linked.
> 
> I added a test case for this scenario to make sure it works properly even when `X` and/or `Y` are excluded from the AOT cache.
> 
> I also fixed some pre-existing problems with test exclusion and logging.

This pull request has now been integrated.

Changeset: 055d2ffa
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/055d2ffa69e129b7617369e268f272517f25e2d7
Stats:     70 lines in 3 files changed: 54 ins; 1 del; 15 mod

8361215: Add AOT test case: verification constraint classes are excluded

Reviewed-by: ccheung

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

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

From iklam at openjdk.org  Wed Jul  2 04:49:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 04:49:40 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v5]
In-Reply-To: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
Message-ID: <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>

On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewed the diff on github

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/aotClassInitializer.cpp line 41:

> 39: 
> 40: // Tell if ik is marked as AOT initialization safe via @jdk.internal.vm.annotation.AOTSafeClassInitializer.
> 41: bool AOTClassInitializer::allows_aot_initialization(InstanceKlass* ik) {

Instead of doing the asserts here, I think the checks should be done in `ClassFileParser`: if a class is marked `@AOTSafeClassInitializer` annotation, then each of its supertypes must either be marked `@AOTSafeClassInitializer`, or have no `<clinit>`. Otherwise an exception should be thrown (ClassFileFormatError??).

This will be a good reminder that if you mark a class as `@AOTSafeClassInitializer`, you should check the `<clinit>` of all of its supertypes.

Then, this function can be removed, and the caller can call `ik->has_aot_safe_initializer()` directly.

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68:

> 66:  * @param <S> species data type.
> 67:  */
> 68: @AOTSafeClassInitializer

This should be placed below the `/*non-public*/` comment.

src/java.base/share/classes/jdk/internal/vm/annotation/AOT.md line 47:

> 45: because the result of loading an AOT cache must look like a valid,
> 46: standard-conformant execution of the JVM.  But a heap object with an
> 47: uninitialized class is an impossibility within the JVMS.

We should resolve the differences between this file and AOTSafeClassInitializer.java. The comments in the latter describes the current implementation, whereas this file describes what we want in the future.

See https://github.com/openjdk/jdk/blob/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce/src/hotspot/share/cds/heapShared.cpp#L317-L331

In the current implementation, only the objects in the "special object graph" have their classes marked as "aot-initialized". The "special object graph" is described here:

https://github.com/openjdk/jdk/blob/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce/src/hotspot/share/cds/heapShared.hpp#L274-L279

It essentially corresponds to the "objects directly or indirectly referenced by resolved constant pool entries" by the comments in  AOTSafeClassInitializer.java.

src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java line 53:

> 51: ///    entries when it's safe and beneficial to do so.
> 52: ///
> 53: /// An AOT-resolved constant pool entry for an invokedynamic or invokehandle bytecodes can

bytecodes -> bytecode

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

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2977642139
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179033016
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179038052
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179049071
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179050047

From thartmann at openjdk.org  Wed Jul  2 05:43:39 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Jul 2025 05:43:39 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <VJa620uJmx8Zmgo7x0F7xpRmK22fqXYm1rSasdssvfo=.9498b077-a049-488a-bb21-cd4c0746a0dc@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

I submitted testing for this and will report back once it passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3026525761

From dholmes at openjdk.org  Wed Jul  2 06:35:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 06:35:40 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <03QoDXp-rOR3n546DRKYfDabRcdMYUOI8wCnINdW69Y=.c6fca915-9dc2-4737-92d1-a09c27babae9@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
 <03QoDXp-rOR3n546DRKYfDabRcdMYUOI8wCnINdW69Y=.c6fca915-9dc2-4737-92d1-a09c27babae9@github.com>
Message-ID: <cVeuDir_pveRDjZQrqsCI5AUdbx04RRNEBFJFxCwzOk=.a9502fd2-a75f-4596-815a-9e1eddd75c91@github.com>

On Tue, 1 Jul 2025 12:31:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
>> 
>> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
>> 
>> Testing
>>  - new test
>>  - Tiers 1-4 (sanity)
>
> Cool test. Looks fine.  I had some earlier comments but nothing that would really improve the change.

Thanks for the review @coleenp !

> src/hotspot/share/prims/jniCheck.cpp line 400:
> 
>> 398:   if (orig_result == STRING_TAG || orig_result == STRING_UTF_TAG) {
>> 399:     bool was_utf = orig_result == STRING_UTF_TAG;
>> 400:     tty->print_cr("%s: called on something allocated by %s",
> 
> Can you use log_warning(memory) for this message rather than tty?
> Maybe these should be tty since they're in jniCheck.

`tty` is used throughout the jniCheck code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25444#issuecomment-3026627820
PR Review Comment: https://git.openjdk.org/jdk/pull/25444#discussion_r2179232621

From thartmann at openjdk.org  Wed Jul  2 06:36:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Jul 2025 06:36:45 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <SP9mvYeUA6Xyh5xAWtCRXiJYdkRakqOWaUrfeXRtmBk=.e825c3fa-3a6b-4c57-933c-d0b8a8ebe3dd@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <WwFnXXFdWig-6NcpPMoBR8FUGpeBTDlmmiwZuDICmao=.f01bd266-c31e-4edd-9300-da97d1a1e088@github.com>
 <SP9mvYeUA6Xyh5xAWtCRXiJYdkRakqOWaUrfeXRtmBk=.e825c3fa-3a6b-4c57-933c-d0b8a8ebe3dd@github.com>
Message-ID: <aQ3msyqjxcz-Ni5QvWrDIb29buIF67glPnqHljwFe_s=.c04bedf1-9eb3-4d69-89c5-2fdc05f8b328@github.com>

On Mon, 30 Jun 2025 18:26:01 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> We should also backport it to JDK-25 before RDP2

Enabling APX as an experimental feature in product feels like an enhancement to me, I therefore converted this from a bug to an RFE. Per [JEP 3](https://openjdk.org/jeps/3), this would need approval for being backported to JDK 25 during RDP 1.

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

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3026625793

From duke at openjdk.org  Wed Jul  2 06:52:48 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 2 Jul 2025 06:52:48 GMT
Subject: Integrated: 8284016: Normalize handshake closure names
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <TOysmxCpnh6Wp026OjPljEDZqxqw6bZ7_L8JoP-k84U=.c47dfeb4-e5be-402f-917c-61e06cd44ce0@github.com>

On Fri, 27 Jun 2025 09:10:26 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

This pull request has now been integrated.

Changeset: 0f1cd987
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f1cd987b3520eaeab31e9faf782d6f81050803a
Stats:     116 lines in 18 files changed: 0 ins; 0 del; 116 mod

8284016: Normalize handshake closure names

Reviewed-by: coleenp, sspitsyn

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

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

From dholmes at openjdk.org  Wed Jul  2 06:57:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 06:57:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LIm3kaxNVCwLe6hk7kwoQ8yoiL9EJOiqI3c0U7GSY1s=.3088b118-a78c-47f1-9d84-97b3ac823cc8@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Sorry but I really dislike seeing this compiler-specific pollution in shared code. It is even worse that you have to put it in two places (what is so special about the jvmci code to require this?) just because gcc is "too dumb" keep track of things.

Also IIUC from JBS the problem was only seen building Zero, so maybe we can do something there that is Zero specific?

Sorry.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2977963403

From tschatzl at openjdk.org  Wed Jul  2 07:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Jul 2025 07:03:47 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v10]
In-Reply-To: <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
 <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
Message-ID: <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@github.com>

On Tue, 17 Jun 2025 12:52:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert suggestions
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894:
> 
>> 892: 
>> 893:   bool should_expand;
>> 894:   size_t resize_bytes = _heap_sizing_policy->full_collection_resize_amount(should_expand, allocation_word_size);
> 
> pre-existing:  I wonder why this isn't a function that returns a `ptrdiff_t` delta on the current size,
> removing the need for multiple values, one being returned via a by-reference out parameter.
> Similarly for the young collection case. Or return the size & direction as a pair-like object.
> (Personally, I find by-reference out parameters confusing to read, but maybe that's just me.)

One potential reason: on 32 bit platforms `ptrdiff_t` is +- 2GB. Heap can be ~4GB on Linux, so `ptrdiff_t` could not represent all potential resize sizes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2179279576

From dholmes at openjdk.org  Wed Jul  2 07:19:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:19:43 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com>

On Wed, 2 Jul 2025 01:47:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

I'm not very familiar with these aspects of C++ but this seems to be a very complex solution to what sounds in JBS to be a pretty straight-forward problem.

src/hotspot/share/prims/jvmtiAgentList.cpp line 35:

> 33: 
> 34: JvmtiAgent* JvmtiAgentList::_head = nullptr;
> 35: JvmtiAgent** JvmtiAgentList::_tail = nullptr;

Why is the tail a pointer to a pointer? Sorry I'm not understanding how your list is being managed here.

I'm trying to work out where you need acquire/release because I'm pretty sure it is missing where needed, but again I can't understand how you are actually constructing and using the list.

src/hotspot/share/prims/jvmtiAgentList.cpp line 105:

> 103:   while (true) {
> 104:     // set _tail to address of agent->_next
> 105:     JvmtiAgent** tail = Atomic::load_acquire(&_tail);

You don't need acquire semantics here as you are not doing anything with the `_tail` pointer value other than use it in relation to cmpxchg which provides fully memory barriers.

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

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2977985314
PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2179305538
PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2179284415

From yzheng at openjdk.org  Wed Jul  2 07:22:29 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:22:29 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v9]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

Yudi Zheng 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:

 - address comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8357424
 - Merge tag 'jdk-26+3' into JDK-8357424
   
   Added tag jdk-26+3 for changeset 08b1fa4c
 - Merge tag 'jdk-26+2' into JDK-8357424
   
   Added tag jdk-26+2 for changeset d7aa3498
 - fix compilation error
 - address comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8357424
 - address comments
 - address comments
 - update copyright
 - ... and 1 more: https://git.openjdk.org/jdk/compare/dcb21872...022546a0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/fb32a8c7..022546a0

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

  Stats: 13776 lines in 672 files changed: 6912 ins; 3534 del; 3330 mod
  Patch: https://git.openjdk.org/jdk/pull/25356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25356/head:pull/25356

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

From yzheng at openjdk.org  Wed Jul  2 07:24:42 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:24:42 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <Y_CBG-Cq-k1SvYWgzDR4I5-qP3yk9BR9dGUH5QgZrpM=.a0c9d62b-cb23-47c2-ad43-90547630b712@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
 <Y_CBG-Cq-k1SvYWgzDR4I5-qP3yk9BR9dGUH5QgZrpM=.a0c9d62b-cb23-47c2-ad43-90547630b712@github.com>
Message-ID: <JBa8jXAyBzHCPwzUBtzTuKMKj59NcUkIzvhB_is7cOI=.8a551733-765b-4abc-88ca-bb8650edb650@github.com>

On Fri, 13 Jun 2025 20:59:05 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Yudi Zheng 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+2' into JDK-8357424
>>    
>>    Added tag jdk-26+2 for changeset d7aa3498
>>  - fix compilation error
>>  - address comments
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>>  - address comments
>>  - address comments
>>  - update copyright
>>  - [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod
>
> src/hotspot/share/code/nmethod.cpp line 1951:
> 
>> 1949:   // Could be gated by ProfileTraps, but do not bother...
>> 1950: #if INCLUDE_JVMCI
>> 1951:   if (is_jvmci_hosted()) {
> 
> Someone (like me!) is going to see this code a while from now and try remember why the decompilation count is not being decremented for JVMCI hosted nmethods. I think it's worth adding a comment.

See https://github.com/openjdk/jdk/pull/25356/commits/022546a09ed9ca06898459df2f7b6ddc2877f69b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179317632

From yzheng at openjdk.org  Wed Jul  2 07:24:43 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 07:24:43 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v7]
In-Reply-To: <kTQsJam-H-l24jhzIztbGbn7V0Lf2TxpI5eYTk6SKIE=.c2f32a12-ef80-4d7f-8edd-0959bc717470@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <jK9lKheluCp0kBQUfIw0aOeLrtosIrBW3DtWoSStTEM=.f312343e-05d1-4a21-b0ea-bf8179599218@github.com>
 <kTQsJam-H-l24jhzIztbGbn7V0Lf2TxpI5eYTk6SKIE=.c2f32a12-ef80-4d7f-8edd-0959bc717470@github.com>
Message-ID: <QhBGF44CWOEDGWj_QhvSlGIJ6xVRGuHlLr4SUd1ZFUM=.fe8adef0-16dc-427e-9e46-a72495def25f@github.com>

On Tue, 17 Jun 2025 17:06:14 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Yudi Zheng 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+2' into JDK-8357424
>>    
>>    Added tag jdk-26+2 for changeset d7aa3498
>>  - fix compilation error
>>  - address comments
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>>  - address comments
>>  - address comments
>>  - update copyright
>>  - [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod
>
> src/hotspot/share/runtime/deoptimization.cpp line 2367:
> 
>> 2365: 
>> 2366: #if INCLUDE_JVMCI
>> 2367:     if (nm->is_jvmci_hosted()) {
> 
> A comment here will probably be helpful as well.

See https://github.com/openjdk/jdk/pull/25356/commits/022546a09ed9ca06898459df2f7b6ddc2877f69b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179317776

From dholmes at openjdk.org  Wed Jul  2 07:43:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 07:43:48 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v9]
In-Reply-To: <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <BWhnWJlJGmhGUcjc9yLtYtDinhjXyKvf4tVLT43ENHM=.f4f62030-3306-4749-a3d0-c828fd6587da@github.com>
Message-ID: <UqHAmLthRq86yOk0YypiC_JeHbqeFBtbLhuPFlgLI3g=.fd19e4e7-4585-4b8e-872d-1e26f416e0b8@github.com>

On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited
>  - Feedback

Belated thumbs up from me too.

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

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2978088296

From adinn at openjdk.org  Wed Jul  2 07:51:39 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 07:51:39 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v5]
In-Reply-To: <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
 <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
Message-ID: <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>

On Wed, 2 Jul 2025 04:38:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewed the diff on github
>
> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68:
> 
>> 66:  * @param <S> species data type.
>> 67:  */
>> 68: @AOTSafeClassInitializer
> 
> This should be placed below the `/*non-public*/` comment.

Perhaps also the same for BoundMethodHandle? and others?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179368175

From adinn at openjdk.org  Wed Jul  2 08:10:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 08:10:46 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v5]
In-Reply-To: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
Message-ID: <wK838xbUHK6qkiOmWYDANgi2B7e3o0OJ9OqyRmRGqlg=.60983c58-d1c2-4494-9115-f18d39adeccf@github.com>

On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewed the diff on github

src/java.base/share/classes/jdk/internal/vm/annotation/AOT.md line 67:

> 65: only the data images created by such threads.
> 66: 
> 67: Therefore, if a class A is marked `AOTClassInitializer`, and it has

This mentions the annotation without saying what it is or how it relates to the preceding discussion. Can we maybe introduce it at this point? Something like this:

"Annotation `AOTClassInitializer` is provided to declare that a specific JDK class's metadata, its class mirror and, potentially, its instances can safely be included in an AOT cache. If a class A is marked ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179407537

From epeter at openjdk.org  Wed Jul  2 08:23:47 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 2 Jul 2025 08:23:47 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Submitted testing for commit 2 / v01 :)

However: I can only test on SSE/AVX machines, so you will have to make sure it runs fine on APX and other architectures that may be impacted.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3026920797

From epeter at openjdk.org  Wed Jul  2 08:26:46 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 2 Jul 2025 08:26:46 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
Message-ID: <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Agree with  Paul, these are minor regressions. Let us proceed with this patch.
>
>> Agree with Paul, these are minor regressions. Let us proceed with this patch.
> 
> Thanks so much for your review @sviswa7 !

@XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h.

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026931008

From mhaessig at openjdk.org  Wed Jul  2 08:35:51 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 2 Jul 2025 08:35:51 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v6]
In-Reply-To: <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>
Message-ID: <f8ar2XEaSqheEfhUFWq9QvyXGHAEmZxcSp2ZsLdxvjo=.4f5def7d-b38d-49f0-9752-85aaf86bcecf@github.com>

On Wed, 2 Jul 2025 01:57:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Intel@ AVX10 ISA [1] extensions added new floating point MIN/MAX instructions which comply with definitions in IEEE-754-2019 standard section 9.6 and can directly emulate Math.min/max semantics without the need for any special handling for NaN, +0.0 or -0.0 detection.
>> 
>> **The following pseudo-code describes the existing algorithm for min/max[FD]:**
>> 
>> Move the non-negative value to the second operand; this will ensure that we correctly handle 0.0 and -0.0 values, if values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. Existing MINPS and MAXPS semantics only check for NaN as the second operand; hence, we need special handling to check for NaN at the first operand.
>> 
>>   btmp = (b < +0.0) ? a : b
>>   atmp = (b < +0.0) ? b : a
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> For min[FD] we need a small tweak in the above algorithm, i.e., move the non-negative value to the first operand, this will ensure that we correctly select -0.0 if both the operands being compared are 0.0 or -0.0.
>> 
>>   btmp = (b < +0.0) ? b : a
>>   atmp = (b < +0.0) ? a : b
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> Thus, we need additional special handling for NaNs and +/-0.0 to compute floating-point min/max values to comply with the semantics of Math.max/min APIs using existing MINPS / MAXPS instructions. AVX10.2 added a new instruction, VPMINMAX[SH,SS,SD]/[PH,PS,PD], which comprehensively handles special cases, thereby eliminating the need for special handling.
>> 
>> Patch emits new instructions for reduction and non-reduction operations for single, double, and Float16 type.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sandhya's review comments resolution

Marked as reviewed by mhaessig (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25914#pullrequestreview-2978248768

From thartmann at openjdk.org  Wed Jul  2 08:57:47 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Jul 2025 08:57:47 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <EqGFAY21OGHJ0yn6gAV0DpgKAmQ83BPoDHA1n04GnKg=.5b18ccab-2e0f-43d0-8502-fb74fd8afabb@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

Testing is clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3027027518

From dnsimon at openjdk.org  Wed Jul  2 08:58:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 08:58:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <wMHIciMZ4QYUToxmNokc5_kGX8T_fnwXxmbHlQXt7Qg=.d0cb5bfa-64d4-42b0-b76d-6b5bd81a2956@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 929:

> 927:   if (thread == nullptr) {
> 928:     // This is to prevent --stringop-overflow warning from GCC on linux/fastdebug.
> 929:     // GCC does believe that JavaThread::current() can return nullptr,

`does believe` -> `believes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179510064

From xgong at openjdk.org  Wed Jul  2 08:59:47 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 2 Jul 2025 08:59:47 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
Message-ID: <Ogar2jtCWm6qWHewe3L0M02mwXma8FA6Q4xofrIW3tA=.28b0cc65-254a-4174-9cd8-2d52d43d1840@github.com>

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Agree with  Paul, these are minor regressions. Let us proceed with this patch.
>
>> Agree with Paul, these are minor regressions. Let us proceed with this patch.
> 
> Thanks so much for your review @sviswa7 !

> @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h.

Good to know that. Thanks so much for your testing @eme64 !

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3027032342

From kevinw at openjdk.org  Wed Jul  2 09:04:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 09:04:51 GMT
Subject: [jdk25] RFR: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
Message-ID: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>

Clean backport to JDK 25.

This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

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

Commit messages:
 - Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16

Changes: https://git.openjdk.org/jdk/pull/26088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359870
  Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26088/head:pull/26088

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

From jwaters at openjdk.org  Wed Jul  2 09:07:44 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:07:44 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <T6noB03P0f3RK2RfhSkBqKzxwv8Nvgilrp-8KUPfkNo=.1398d88c-5e1a-4a17-84f1-7e98d9875eaf@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

src/hotspot/share/runtime/javaThread.hpp line 1070:

> 1068:   // Returns the running thread as a JavaThread
> 1069:   static JavaThread* current() {
> 1070:     auto result = JavaThread::cast(Thread::current());

Why auto when the type is known?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179528150

From dnsimon at openjdk.org  Wed Jul  2 09:10:45 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 09:10:45 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v9]
In-Reply-To: <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <8HUFsVgvqriVdKkkm-tkU-_XisP9uFPzSlhBFiGd9i8=.ca3a9645-e01b-4072-bdc8-6c3fb2f7bb81@github.com>
Message-ID: <AM3xZo4mO-a52COruDpMMKZx2pa4JEo6wW0zVjH66eM=.ece42ba7-da61-40e1-a90d-153a9c1aa78f@github.com>

On Wed, 2 Jul 2025 07:22:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng 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:
> 
>  - address comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>  - Merge tag 'jdk-26+3' into JDK-8357424
>    
>    Added tag jdk-26+3 for changeset 08b1fa4c
>  - Merge tag 'jdk-26+2' into JDK-8357424
>    
>    Added tag jdk-26+2 for changeset d7aa3498
>  - fix compilation error
>  - address comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357424
>  - address comments
>  - address comments
>  - update copyright
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f01309be...022546a0

src/hotspot/share/code/nmethod.cpp line 1939:

> 1937:   // Could be gated by ProfileTraps, but do not bother...
> 1938: #if INCLUDE_JVMCI
> 1939:   // Deoptimizations from non-default (non-CompileBroker) compilations should not

Suggestion:

  // Deoptimization count is used by the CompileBroker to reason about compilations
  // it requests so do not pollute the count for deoptimizations in non-default (i.e.
  // non-CompilerBroker) compilations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25356#discussion_r2179536365

From jwaters at openjdk.org  Wed Jul  2 09:12:40 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:12:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <0_bgDyCHArbkXPSDNQdNWLbrhY2AOJT_BjFTMD38tuY=.9ca01026-bf7e-4d59-8326-d5c4537acc17@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

A less messy solution could be to use PRAGMA_STRINGOP_OVERFLOW_IGNORED instead. The conditionals for the PRAGMA IGNORED macros are already all handled for you, so there's no need to put conditionalizations at the use sites. As an example, simply do the following:


PRAGMA_DIAG_PUSH
PRAGMA_STRINGOP_OVERFLOW_IGNORED
// Problem code here
PRAGMA_DIAG_POP


The first 2 macros are placed directly in front of the problem code, and the last goes behind.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3027075027

From iwalulya at openjdk.org  Wed Jul  2 09:27:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 2 Jul 2025 09:27:46 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
Message-ID: <p0oM0BFSTgasCSc_qLFVl0P-RPZXcefFbCGhvrZnit8=.805a1924-70c5-4508-9e08-e4c57dcf4cbf@github.com>

On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

LGTM! very nice overhaul.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2978420691

From haosun at openjdk.org  Wed Jul  2 09:50:47 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 2 Jul 2025 09:50:47 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
Message-ID: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>

On Tue, 1 Jul 2025 09:11:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix formatting issues

Hi.

Not a review. Here lists our internal test result.

## 1. VM crashed for arm32

I created one armhf build via cross-compilation and ran `java --version` via Qemu.
Here lists the error log.


$ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
#  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
#
# JRE version:  (26.0) (fastdebug build )
# Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
#
# An error report file with more information is saved as:
# //hs_err_pid117661.log
#
#
qemu: uncaught target signal 6 (Aborted) - core dumped
environment: line 1: 117660 Aborted                 "$@"


It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49

## 2. copyright year should be updated for the following files


src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
src/hotspot/share/c1/c1_CodeStubs.hpp
src/hotspot/share/runtime/stubCodeGenerator.hpp

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027198670

From adinn at openjdk.org  Wed Jul  2 09:58:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 09:58:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <VV9NRlIAquMwXoHH0EVMUziWggxFKURd505E_Ol6ShU=.9f43df62-587c-425f-899d-50db48b5d7c5@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

@vnkozlov 
> I assume you will address s390 issue before integration.

Amit and Martin followed up on this offline. The problem apppears to be an independent, unrelated issue to do with save and restore of SP at the correct point and they are following it up separately. It only happens intermittently because it depends on what gets left in memory.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027225291

From jsjolen at openjdk.org  Wed Jul  2 10:01:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 2 Jul 2025 10:01:42 GMT
Subject: RFR: 8360023: Add an insertion sort implementation to Hotspot [v7]
In-Reply-To: <f6N6CDcu-PSF-fS2YlEW1DY6gTMXIBbILK4ul9kiiMg=.50035075-a1ec-4cb8-94e1-32024f5a6f1f@github.com>
References: <7-Pyowek_M5CSJRJQV73o6SJ8GoHKVuDz0pFjqxVjAg=.6ba9b804-39aa-4379-b689-f55fda4dd17e@github.com>
 <f6N6CDcu-PSF-fS2YlEW1DY6gTMXIBbILK4ul9kiiMg=.50035075-a1ec-4cb8-94e1-32024f5a6f1f@github.com>
Message-ID: <sG_VosbsBVv9BN-i6avXnodFh7WV3GKI7WQa7BewgHE=.336ea79f-89e9-4bc5-9b9b-e70a0c3b2acf@github.com>

On Fri, 20 Jun 2025 11:02:25 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds an implementation of insertion sort to Hotspot. It is an algorithm that is inplace and stable, and it is the ideal algorithm for arrays with small numbers of elements. The motivation for this is [JDK-8357186](https://bugs.openjdk.org/browse/JDK-8357186) in which a stable sort is desired and the number of elements is small. Additionally, since insertion sort is the most efficient sorting algorithm for small arrays, it can be used in non-stable sort as well.
>> 
>> In addition, I make some improvements to `GrowableArrayIterator`:
>> 
>> - Make a non-const variant (our current iterator is const only).
>> - Add various utility operators to align with a typical iterator.
>> 
>> [JDK-8360032](https://bugs.openjdk.org/browse/JDK-8360032) is a follow-up work that will build a stable merge-insertion sort on top of this PR.
>> 
>> Please take a look and share your thoughts. Thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small changes

This is placed in `sort.hpp`, could we merge the `quicksort.hpp` header into this as well?

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25895#pullrequestreview-2978533090

From adinn at openjdk.org  Wed Jul  2 10:06:44 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:06:44 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <WmRJQtuojke66gpLOJKKh6MrI5VxBEhpMBhjr3RMayc=.91e240ac-ce01-4ace-850e-a2efe90f2149@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

@shqking Thank you for testing and reporting the issue and also for noticing the missing copyright updates.

The assertion is happening because the arm-specific stub declarations are inconsistent. The entry declaration for `atomic_store_long_entry` claims it belongs to stub `atomic_load_long` but the current stub is actually `atomic_store_long`.

I will push a patch to fix that and another one for the copyrights.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027247244

From adinn at openjdk.org  Wed Jul  2 10:37:34 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:37:34 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - update copyrights
 - fix inconsistent stub declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/7908e895..e42ec698

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

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

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

From adinn at openjdk.org  Wed Jul  2 10:37:35 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:37:35 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <tZH39ADnMeVR6_0nj1DKMX1FwfekDXG6NoPKjYoMONc=.00623622-36e2-4378-a598-4c16d4d4dd45@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

@shqking I hope the arm build will now work ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027336478

From alanb at openjdk.org  Wed Jul  2 10:58:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Jul 2025 10:58:39 GMT
Subject: [jdk25] RFR: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
In-Reply-To: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
References: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
Message-ID: <xvJVpkskwpEKojErO_r4Ug64yFZozt9F3xmEMuyvrDM=.c4b38dfa-31e5-48b0-aaf2-b7f2162a3e58@github.com>

On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to JDK 25.
> 
> This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

Clean backport .

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26088#pullrequestreview-2978690636

From sspitsyn at openjdk.org  Wed Jul  2 11:19:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 11:19:39 GMT
Subject: [jdk25] RFR: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
In-Reply-To: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
References: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
Message-ID: <7-mQC-lrxpz1sZQSy4RcpUl_kO0uX_mHuvUkMc40EvM=.02acae01-8078-4f88-82da-1712da475ef4@github.com>

On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to JDK 25.
> 
> This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

It is a clean backport.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26088#pullrequestreview-2978748931

From sspitsyn at openjdk.org  Wed Jul  2 11:23:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 11:23:44 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
Message-ID: <mFGmb3Xl1iUJUiJGL2nEUq5_opt1nEhwzqNgHPdep6A=.5a65079d-5c56-45b9-b0f9-de61b2a1defc@github.com>

On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the text of assert

I'm suggesting to close [JDK-8360670](https://bugs.openjdk.org/browse/JDK-8360670) as a dup of [JDK-8360664](https://bugs.openjdk.org/browse/JDK-8360664).

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3027493740

From yzheng at openjdk.org  Wed Jul  2 11:27:25 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 11:27:25 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25356/files
  - new: https://git.openjdk.org/jdk/pull/25356/files/022546a0..d6221921

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

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

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

From coleenp at openjdk.org  Wed Jul  2 11:30:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 11:30:40 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v3]
In-Reply-To: <72Pw1wW68nGAY9-FYyMD2RI1qXn0qjMP5Oibzb5qiXA=.e6a2e239-938a-4ebf-a4b9-77d65a03d20c@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <72Pw1wW68nGAY9-FYyMD2RI1qXn0qjMP5Oibzb5qiXA=.e6a2e239-938a-4ebf-a4b9-77d65a03d20c@github.com>
Message-ID: <O_-izu1gjvcdoh828sAhTBX-WbNsgVF1ZEzNO6nVcvo=.7bf3cd92-8e2e-49e0-ada0-441068acb9ef@github.com>

On Tue, 1 Jul 2025 18:26:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use bool for _disable_interning_during_cds_dump

This looks good.  Couple of simple suggestions and I'll reapprove.

src/hotspot/share/classfile/stringTable.cpp line 951:

> 949: }
> 950: 
> 951: // This is called BEFORE we enter the CDS safepoint. We can allocate still Java object arrays to

Suggestion:

// This is called BEFORE we enter the CDS safepoint. We can still allocate Java object arrays to

src/hotspot/share/classfile/stringTable.cpp line 960:

> 958:   CompileBroker::wait_for_no_active_tasks();
> 959: 
> 960:   precond(THREAD->is_Java_thread());

Suggestion:



If it's TRAPS and THREAD it is a JavaThread now.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25816#pullrequestreview-2978765132
PR Review Comment: https://git.openjdk.org/jdk/pull/25816#discussion_r2179802493
PR Review Comment: https://git.openjdk.org/jdk/pull/25816#discussion_r2179804244

From mhaessig at openjdk.org  Wed Jul  2 11:37:14 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 2 Jul 2025 11:37:14 GMT
Subject: RFR: 8361253: CommanLineOptionTest library should report observed
 values on failure
Message-ID: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>

When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of 


java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value


a mismatch in the `CICompilerCount` will now print


java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'.


Testing:
 - [ ] Github Actions
 - [ ] tier1 through tier3 plus Oracle internal testing

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

Commit messages:
 - Add observed values to CommandLineOptionTest error messages

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

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

From dnsimon at openjdk.org  Wed Jul  2 11:47:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 11:47:41 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <QIsi0QjccJ_REav4WWL85PnJ2Zj3XrLSV5ImIlNE73A=.a2e0873d-2109-485b-a0d2-1ec8bb3de4b1@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2978826504

From adinn at openjdk.org  Wed Jul  2 12:06:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 12:06:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <pk8hofhbfqKu8EtnoHxifBUr3Z2UvVTQC55g8T4Ii8g=.889a949b-e2e1-4f23-a611-8baecabd3ab4@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

@vnkozlov Could you please rereview this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027619494

From asemenov at openjdk.org  Wed Jul  2 12:10:39 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 2 Jul 2025 12:10:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <mFGmb3Xl1iUJUiJGL2nEUq5_opt1nEhwzqNgHPdep6A=.5a65079d-5c56-45b9-b0f9-de61b2a1defc@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
 <mFGmb3Xl1iUJUiJGL2nEUq5_opt1nEhwzqNgHPdep6A=.5a65079d-5c56-45b9-b0f9-de61b2a1defc@github.com>
Message-ID: <TRzEBskwgW5IAM0ZMFv_tMgSH85gjA3WdeV4e1w-BF4=.0759e41d-4135-46ac-bd1e-e930dce56b92@github.com>

On Wed, 2 Jul 2025 11:21:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I'm suggesting to close [JDK-8360670](https://bugs.openjdk.org/browse/JDK-8360670) as a dup of [JDK-8360664](https://bugs.openjdk.org/browse/JDK-8360664).

Ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3027629174

From dholmes at openjdk.org  Wed Jul  2 12:18:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 12:18:38 GMT
Subject: RFR: 8361253: CommanLineOptionTest library should report observed
 values on failure
In-Reply-To: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <MM4XxxtnOe4wxMUppPytCUVJ07UrOr0Dx9ZisiIfc8Q=.cf5e0430-cd14-4292-98fb-e431f0139fee@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of 
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value
> 
> 
> a mismatch in the `CICompilerCount` will now print
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'.
> 
> 
> Testing:
>  - [ ] Github Actions
>  - [ ] tier1 through tier3 plus Oracle internal testing

This looks reasonable to me. Thanks for addressing this so promptly!

There was a typo in the JBS issue title so you will need to adjust here.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26092#pullrequestreview-2978917364

From shade at openjdk.org  Wed Jul  2 12:41:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Jul 2025 12:41:38 GMT
Subject: RFR: 8361253: CommandLineOptionTest library should report observed
 values on failure
In-Reply-To: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <7TBGrTc8gKqAJfXiXhNBhXLFkWVFF0KQkJnMpN7e1Po=.d9ece700-fe5a-4c35-baa5-9ab4e4f586d2@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of 
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value
> 
> 
> a mismatch in the `CICompilerCount` will now print
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'.
> 
> 
> Testing:
>  - [x] Github Actions
>  - [ ] tier1 through tier3 plus Oracle internal testing

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26092#pullrequestreview-2978987090

From kbarrett at openjdk.org  Wed Jul  2 13:37:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 13:37:39 GMT
Subject: RFR: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <R409R4V8IbaDubiyyNeuc8f1lpl-DxM8a-K49_z451k=.00052370-bae4-43c0-87b2-6901ceb9426f@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25997#pullrequestreview-2979199847

From ayang at openjdk.org  Wed Jul  2 13:42:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 13:42:45 GMT
Subject: RFR: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <V1C_Hd2vVz19885kTYUyd9vgdrOMenLqWl5QwNmiGwM=.44839b51-87d1-4e7a-9435-5309b6fe806c@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25997#issuecomment-3027924284

From ayang at openjdk.org  Wed Jul  2 13:42:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 2 Jul 2025 13:42:45 GMT
Subject: Integrated: 8338474: Parallel: Deprecate and obsolete
 PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <AQ7P3na4FSD_Q9ZtQWTWUMyipd-6yXex6TFjlmqdX44=.12b5bf3d-7281-4e8a-a94f-6e505f14dc95@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

This pull request has now been integrated.

Changeset: 832bfbc0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/832bfbc0ddcf3068bab5d45d361803152736383f
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays

Reviewed-by: tschatzl, kbarrett

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

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

From kbarrett at openjdk.org  Wed Jul  2 14:01:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 14:01:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 926:

> 924: JVMCI::CodeInstallResult CodeInstaller::initialize_buffer(JVMCIObject compiled_code, CodeBuffer& buffer, HotSpotCompiledCodeStream* stream, u1 code_flags, JVMCI_TRAPS) {
> 925:   JavaThread* thread = stream->thread();
> 926: #if defined(__GNUC__) && !defined(__clang__) && !defined(PRODUCT)

Note that `!PRODUCT` does not imply `ASSERT`. There is also the "optimized" build type, which
defines neither `PRODUCT` nor `ASSERT`. I have no idea whether the false-positive gcc warnings
occur in that build configuration. If so, then my suggestion of using an assertion to give the compiler
the clue it needs won't work. But I'm guessing that isn't a problem, in which case the macro check
should be `defined(ASSERT)`.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:

> 934:     __builtin_unreachable();
> 935:   }
> 936: #endif

I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
function.

src/hotspot/share/runtime/javaThread.hpp line 1079:

> 1077:   }
> 1078: #endif
> 1079:     return result;

Similarly here, I think this could be replaced with asserting non-null.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2979254552
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180140733
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180123147
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180120768

From liach at openjdk.org  Wed Jul  2 15:14:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 15:14:56 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v6]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <r4zh-c_X_ZO_wCBcs5y3MGHBg3j9sjrfD-oZZKKYeCI=.54998a86-63e6-41de-a4f5-e3175be9b116@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Remove design document from code
 - Some more from reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/d5a54f5b..4b3906aa

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

  Stats: 168 lines in 10 files changed: 30 ins; 135 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

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

From liach at openjdk.org  Wed Jul  2 15:14:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 15:14:56 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v5]
In-Reply-To: <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
 <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
 <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>
Message-ID: <4OZnYKuL_IAwNtwQZqs4LkoWGKfhKr3-_n6AVVe3Jm4=.b10c26b4-65f7-4f90-bd21-68ae3a4bad05@github.com>

On Wed, 2 Jul 2025 07:48:05 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68:
>> 
>>> 66:  * @param <S> species data type.
>>> 67:  */
>>> 68: @AOTSafeClassInitializer
>> 
>> This should be placed below the `/*non-public*/` comment.
>
> Perhaps also the same for BoundMethodHandle? and others?

John disclosed these comments were from the initial iteration of JSR 292 implementation. Newer code does not have this comment, so I think I will just remove them outright.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180315616

From sparasa at openjdk.org  Wed Jul  2 15:27:45 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 2 Jul 2025 15:27:45 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <EqGFAY21OGHJ0yn6gAV0DpgKAmQ83BPoDHA1n04GnKg=.5b18ccab-2e0f-43d0-8502-fb74fd8afabb@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
 <EqGFAY21OGHJ0yn6gAV0DpgKAmQ83BPoDHA1n04GnKg=.5b18ccab-2e0f-43d0-8502-fb74fd8afabb@github.com>
Message-ID: <zVHclwDjWxoECXjlgHDpvJBLZZ6ZtVOAwd_QScJLjYA=.f4fd99e5-a456-4c76-83c0-fff6297726c1@github.com>

On Wed, 2 Jul 2025 08:55:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Testing is clean.

Thank you, Tobias!

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

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3028294266

From sparasa at openjdk.org  Wed Jul  2 15:29:43 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 2 Jul 2025 15:29:43 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
Message-ID: <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>

On Wed, 2 Jul 2025 08:20:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Submitted testing for commit 2 / v01 :)
> 
> However: I can only test on SSE/AVX machines, so you will have to make sure it runs fine on APX and other architectures that may be impacted.

Thank you, Emanuel! 
Yes, this was tested using Intel SDE to emulate the APX features.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3028302287

From mablakatov at openjdk.org  Wed Jul  2 15:56:28 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Wed, 2 Jul 2025 15:56:28 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
Message-ID: <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>

> 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 incrementally with two additional commits since the last revision:

 - Lift the vm.opt.TieredCompilation == null requirement from the tests
 - Combine the two shared trampoline request hash tables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25954/files
  - new: https://git.openjdk.org/jdk/pull/25954/files/5ac22c12..43ef90ce

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

  Stats: 133 lines in 8 files changed: 43 ins; 52 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/25954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954

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

From mablakatov at openjdk.org  Wed Jul  2 15:56:28 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Wed, 2 Jul 2025 15:56:28 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <cxa87s4YtgyQQFCadWBxSKCLUDLS0aneZ8ARJaVX77Y=.cceb528e-d6ff-4958-879c-7aac116095d4@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <cxa87s4YtgyQQFCadWBxSKCLUDLS0aneZ8ARJaVX77Y=.cceb528e-d6ff-4958-879c-7aac116095d4@github.com>
Message-ID: <iSeChfWR6NYy1SqGzdUUI5s0gWNrhbvtiazTBhylEjA=.890ea1d2-5ab8-40f4-a1d7-fa95ed3e3b61@github.com>

On Mon, 30 Jun 2025 22:52:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>>  - Combine the two shared trampoline request hash tables
>
> test/hotspot/jtreg/compiler/sharedstubs/SharedStaticCallTrampolineTest.java line 33:
> 
>> 31:  *
>> 32:  * @requires vm.compiler2.enabled
>> 33:  * @requires vm.opt.TieredCompilation == null
> 
> I don't think
> @requires vm.opt.TieredCompilation == null
> is needed here.
> Test always overrides TieredCompilation mode. 
> 
> The problem is that the test is going to be skipped if someone run testing with -XX:-TieredCompilation to test C2 changes. Please just remove this line so test is executed anytime if C2 is available.
> 
> The renamed test 'SharedRuntimeCallTrampolineTest' seems to have this problem also.

Thank you for a review @lmesnik , fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2180415094

From iklam at openjdk.org  Wed Jul  2 16:02:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 16:02:33 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v4]
In-Reply-To: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
Message-ID: <GrAnNsFwx7gPs3ek-pzexinbFEPpG6hTAKDxJhyCiqw=.ed8d04b1-d93f-44aa-acf5-5c926b1ed4a9@github.com>

> Background: when writing the string table in the AOT cache, we do this:
> 
> 1. Find out the number of strings in the interned string table
> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
> 3. Enter safepoint
> 4. Copy the strings into the arrays
> 
> This bug happened because:
> 
> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
> - JIT compiler threads may create more interned strings after step 1
> 
> This PR attempts to fix both issues.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @coleep comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25816/files
  - new: https://git.openjdk.org/jdk/pull/25816/files/57ceaa9c..ad8456e1

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

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

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

From mablakatov at openjdk.org  Wed Jul  2 16:02:41 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Wed, 2 Jul 2025 16:02:41 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method
In-Reply-To: <_PIZLj4M2dZ3LH1VANe43lZPgExy7gabgW8llHpEcQA=.04b3eda8-05c4-4daa-b8c3-1175fa4cfbad@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <W9SAPZh6PPMK00_66ZzIoPOlwrL7zqKnzdoRcVIr4xs=.5b177ce0-aa45-458c-9731-62fb9ad0554a@github.com>
 <T6EPb62F1iS7jUErm8hSXVVC49ufAwbL4mJzih2pLho=.dd16d206-5213-4f9b-8726-02adf84fb10f@github.com>
 <_PIZLj4M2dZ3LH1VANe43lZPgExy7gabgW8llHpEcQA=.04b3eda8-05c4-4daa-b8c3-1175fa4cfbad@github.com>
Message-ID: <qG8l_-0bJNzDb4xvYc-IYTsp-QKQ8eyiujS2pv2BftU=.dbeeb637-88ad-47ea-998d-02d4b6697e30@github.com>

On Thu, 26 Jun 2025 08:17:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We could use something like Pair<callKind, address> for keys instead and use the first to distinguish between runtime and static calls. I'd need to extend template<...> class Pair so it properly supports hashing and comparison (at least equality) for this to work.

> Sounds good.

Done. @theRealAph , could you give it another look when you've got some time?

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

PR Comment: https://git.openjdk.org/jdk/pull/25954#issuecomment-3028415201

From jkratochvil at openjdk.org  Wed Jul  2 16:34:16 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 2 Jul 2025 16:34:16 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to 'memset' is
 a pointer to non-trivially copyable type
Message-ID: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>

src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
   49 |   memset(this, 0, sizeof(*this));
      |          ^
src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
   49 |   memset(this, 0, sizeof(*this));
      |          ^
      |          (void*)
1 error generated.
src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
   43 |     memset(this, 0, sizeof(*this));
      |            ^
src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning
   43 |     memset(this, 0, sizeof(*this));
      |            ^
      |            (void*)
src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
   48 |     memset(this, 0, sizeof(*this));
      |            ^
src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning
   48 |     memset(this, 0, sizeof(*this));
      |            ^
      |            (void*)
2 errors generated.

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

Commit messages:
 - 8357579: Compilation error: first argument in call to 'memset' is a pointer to non-trivially copyable type

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

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

From jkratochvil at openjdk.org  Wed Jul  2 16:54:55 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 2 Jul 2025 16:54:55 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v2]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <zdER4mrK6z-WYYGCPngMMN3uVZIZcwsHtIZaAFhudqU=.4551b2b6-c2cd-4d78-82b9-dc312bdb5c19@github.com>

> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 1 error generated.
> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>    43 |     memset(this, 0, sizeof(*this));
>       |            ^
> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning
>    43 |     memset(this, 0, sizeof(*this));
>       |            ^
>       |            (void*)
> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>    48 |     memset(this, 0, sizeof(*this));
>       |            ^
> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning
>    48 |     memset(this, 0, sizeof(*this));
>       |            ^
>       |            (void*)
> 2 errors generated.

Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "8361288: Fix build of JTReg: wget exited with exit code 4"
   
   This reverts commit 6e6b8f6a26f8e555f1e70544546b92bbafcae6cc.
 - 8361288: Fix build of JTReg: wget exited with exit code 4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/fe514b44..09a45c6d

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

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

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

From kevinw at openjdk.org  Wed Jul  2 16:59:39 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 16:59:39 GMT
Subject: [jdk25] RFR: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
In-Reply-To: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
References: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
Message-ID: <APA7ddiYxBThJZT_xyl5AGsLFVpir_bupM0kQ04L3tg=.1f86feb1-239a-465f-b26f-523b02833447@github.com>

On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to JDK 25.
> 
> This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

Thanks Alan and Serguei, will integrate this clean backport to 25.

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

PR Comment: https://git.openjdk.org/jdk/pull/26088#issuecomment-3028589723

From kevinw at openjdk.org  Wed Jul  2 17:02:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 17:02:44 GMT
Subject: [jdk25] Integrated: 8359870: JVM crashes in
 AccessInternal::PostRuntimeDispatch
In-Reply-To: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
References: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>
Message-ID: <dQZMyD3FZv5ml-Jed0Ibf0tz1PANn-QIIV_Fg8DcKUA=.081049cc-1042-4789-9b48-d8730ee4056e@github.com>

On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to JDK 25.
> 
> This change recently integrated in JDK 26  and is through tiers 1 - 4 so far.

This pull request has now been integrated.

Changeset: 92268e17
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92268e17beec15f3fefa6784a48d6f0e1bb9c67a
Stats:     32 lines in 5 files changed: 22 ins; 2 del; 8 mod

8359870: JVM crashes in AccessInternal::PostRuntimeDispatch

Reviewed-by: alanb, sspitsyn
Backport-of: 13a3927855da61fe27f3b43e5e4755d0c5ac5a16

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

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

From mli at openjdk.org  Wed Jul  2 17:19:57 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Jul 2025 17:19:57 GMT
Subject: RFR: 8360000: RISC-V: implement aot
Message-ID: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>

Hi,
Can you help to review this patch?

https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.

Riscv should support these features and resolve relative issues.

## Test

### jtreg

run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 

### Performance

perf command to run the simplest Hello world java program:
* (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed

perf data:
* (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
* (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )

Thanks

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

Commit messages:
 - clean
 - revert
 - stop
 - clean
 - clean
 - fix stop
 - fix C1 guarantee(code_offset() - offset <= exception_handler_size(), overflow);
 - Merge branch 'aot-riscv' of https://github.com/Hamlin-Li/jdk into aot-riscv
 - Merge branch 'master' into aot-riscv
 - fix assert(is_instance(java_string)
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9d060574...b70493e2

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

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

From vpaprotski at openjdk.org  Wed Jul  2 17:30:51 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 2 Jul 2025 17:30:51 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
Message-ID: <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>

On Tue, 1 Jul 2025 06:45:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker ...

Using the suggested code as a base, Vamsi and I tinkered with the idea some more! Here is what we came up with. This also tracks the correct order of registers being pushed/poped.. (haven't compiled it, so might have some syntax bugs).

@dholmes-ora would you mind sharing your opinion? We seem to be making things more complicated, but hopefully in a good way?

Also included a sample usage in a stub.


#define __ _masm->

class PushPopTracker {
   private:
      int _counter;
      MacroAssembler *_masm;
      const int REGS = 32; // Increase as needed
      int regs[REGS];
   public:
      PushPopTracker(MacroAssembler *_masm) : _counter(0), _masm(_masm) {}
      ~PushPopTracker() {
         assert(_counter == 0, "Push/pop pair mismatch");
      }

      void push(Register reg) {
         assert(_counter<REGS, "Push/pop overflow");
         regs[_counter++] = reg.encoding();
         if (VM_Version::supports_apx_f()) {
            __ pushp(reg);
         } else {
            __ push(reg);
         }
      }
      void pop(Register reg) {
         assert(_counter>0, "Push/pop underflow");
         assert(regs[_counter] == reg.encoding(), "Push/pop pair mismatch: %d != %d", regs[_counter], reg.encoding());
         _counter--;
         if (VM_Version::supports_apx_f()) {
            __ popp(reg);
         } else {
            __ pop(reg);
         }
      }
}

address StubGenerator::generate_intpoly_montgomeryMult_P256() {
  __ align(CodeEntryAlignment);
  /*...*/
  address start = __ pc();
  __ enter();
  PushPopTracker s(_masm);
  s.push(r12); //1
  s.push(r13); //2
  s.push(r14); //3
  #ifdef _WIN64
  s.push(rsi); //4
  s.push(rdi); //5
  #endif
  s.push(rbp); //6
  __ movq(rbp, rsp);
  __ andq(rsp, -32);
  __ subptr(rsp, 32);
  // Register Map
  const Register aLimbs  = c_rarg0; // c_rarg0: rdi | rcx
  const Register bLimbs  = rsi;     // c_rarg1: rsi | rdx
  const Register rLimbs  = r8;      // c_rarg2: rdx | r8
  const Register tmp1    = r9;
  const Register tmp2    = r10;
  /*...*/
  __ movq(rsp, rbp);
  s.pop(rbp); //5
  #ifdef _WIN64
  s.pop(rdi); //4
  s.pop(rsi); //3
  #endif
  s.pop(r14); //2
  s.pop(r13); //1
  s.pop(r12); //0
  __ leave();
  __ ret(0);
  return start;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2180606586

From iklam at openjdk.org  Wed Jul  2 17:39:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 17:39:18 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop()
Message-ID: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>

A module has both a Java and a C++ representation

- C++: `ModuleEntry`
- Java: `java.lang.Module`

In C++, we have the following two methods

- `ModuleEntry* InstanceKlass::module()`
- `oop ModuleEntry::module()`

This can lead to confusing code like this:


InstanceKlass* ik = ...;
oop module = ik->module()->module()


Proposal:

- Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
- Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:


InstanceKlass* ik = ...;
oop module = ik->module()->module_oop()

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

Commit messages:
 - 8361292: Rename ModuleEntry::module() to module_oop()

Changes: https://git.openjdk.org/jdk/pull/26102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361292
  Stats: 35 lines in 12 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/26102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26102/head:pull/26102

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

From never at openjdk.org  Wed Jul  2 17:40:44 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 2 Jul 2025 17:40:44 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <wJxNwBEgrbJAdOeKL81u4lqNiQrwP8ARHc8klKxCoEI=.380309ef-80b2-4832-9099-424826d4e616@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Looks great.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2980076551

From coleenp at openjdk.org  Wed Jul  2 17:42:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 17:42:41 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v4]
In-Reply-To: <GrAnNsFwx7gPs3ek-pzexinbFEPpG6hTAKDxJhyCiqw=.ed8d04b1-d93f-44aa-acf5-5c926b1ed4a9@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <GrAnNsFwx7gPs3ek-pzexinbFEPpG6hTAKDxJhyCiqw=.ed8d04b1-d93f-44aa-acf5-5c926b1ed4a9@github.com>
Message-ID: <BzY2xiQuZCMBcJu9uWIGh2Jx5jgKGroHdkO34MJcPys=.abc15c90-36af-4cb4-ba00-be2d42a70894@github.com>

On Wed, 2 Jul 2025 16:02:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleep comments

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25816#pullrequestreview-2980082840

From jbhateja at openjdk.org  Wed Jul  2 17:47:41 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Jul 2025 17:47:41 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
 <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
Message-ID: <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>

On Wed, 2 Jul 2025 17:27:41 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker in the stub snippets using push/pop instruction sequence and wrap the actual assembler call underneath. The idea here is to catch the balancing error upfront as PPX is purely a performance hint. Instructions with this hint have the same functional semantics as those without. PPX hints set by the compiler that violate the balancing rule may turn off the PPX
>> optimization, but they will not affect program semantics..
>> 
>> 
>> class APXPushPopPairTracker {
>>     private:
>>         int _counter;
>>  
>>     public:
>>         APXPushPopPairTracker() _counter(0) {
>>         }
>> 
>>        ~APXPushPopPairTracker() {
>>            assert(_counter == 0, "Push/pop pair mismatch");
>>         }
>>      
>>         void push(Register reg, bool has_matching_pop) {
>>             if (has_matching_pop && VM_Version::supports_apx_f()) {
>>                Assembler::pushp(reg);
>>                incrementCounter();
>>             } else {
>>                Assembler::push(reg);
>>             }
>>         }
>>         void pop(Register reg, bool has_matching_push) {
>>             if (has_matching_push && VM_Version::supports_apx_f()) {
>>                Assembler::popp(reg);
>>                decrementCounter();
>>             } else {
>>                Assembler::pop(reg);
>>             }
>>         }     
>>         void incrementCounter() {
>>           _counter++;
>>         }
>>         void decrementCounter() {
>>            _counter--;
>>         }
>> }
>
>> For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker ...
> 
> Using the suggested code as a base, Vamsi and I tinkered with the idea some more! Here is what we came up with. This also tracks the correct order of registers being pushed/poped.. (haven't compiled it, so might have some syntax bugs).
> 
> @dholmes-ora would you mind sharing your opinion? We seem to be making things more complicated, but hopefully in a good way?
> 
> Also included a sample usage in a stub.
> 
> 
> #define __ _masm->
> 
> class PushPopTracker {
>    private:
>       int _counter;
>       MacroAssembler *_masm;
>       const int REGS = 32; // Increase as needed
>       int regs[REGS];
>    public:
>       PushPopTracker(MacroAssembler *_masm) : _counter(0), _masm(_masm) {}
>       ~PushPopTracker() {
>          assert(_counter == 0, "Push/pop pair mismatch");
>       }
> 
>       void push(Register reg) {
>          assert(_counter<REGS, "Push/pop overflow");
>          regs[_counter++] = reg.encoding();
>          if (VM_Version::supports_apx_f()) {
>             __ pushp(reg);
>          } else {
>             __ push(reg);
>          }
>       }
>       void pop(Register reg) {
>          assert(_counter>0, "Push/pop underflow");
>          assert(regs[_counter] == reg.encoding(), "Push/pop pair mismatch: %d != %d", regs[_counter], reg.encoding());
>          _counter--;
>          if (VM_Version::supports_apx_f()) {
>             __ popp(reg);
>          } else {
>             __ pop(reg);
>          }
>       }
> }
> 
> address StubGenerator::generate_intpoly_montgomeryMult_P256() {
>   __ align(CodeEntryAlignment);
>   /*...*/
>   address start = __ pc();
>   __ enter();
>   PushPopTracker s(_masm);
>   s.push(r12); //1
>   s.push(r13); //2
>   s.push(r14); //3
>   #ifdef _WIN64
>   s.push(rsi); //4
>   s.push(rdi); //5
>   #endif
>   s.push(rbp); //6
>   __ movq(rbp, rsp);
>   __ andq(rsp, -32);
>   __ subptr(rsp, 32);
>   // Register Map
>   const Register aLimbs  = c_rarg0; // c_rarg0: rdi | rcx
>   const Register bLimbs  = rsi;     // c_rarg1: rsi | rdx
>   const Register rLimbs  = r8;      // c_rarg2: rdx | r8
>   const Register tmp1    = r9;
>   const Register tmp2    = r10;
>   /*...*/
>   __ movq(rsp, rbp);
>   s.pop(rbp); //5
>   #ifdef _WIN64
>   s.pop(rdi); //4
>   s.pop(rsi); //3
>   #endif
>   s.pop(r14); //2
>   s.pop(r13); //1
>   s.pop(r12); //0
>   __ leave();
>   __ ret(0);
>   return start;
> }

@vamsi-parasa, It's better to make this as a subclass of MacroAssembler in src/hotspot/cpu/x86/macroAssembler_x86.hpp and pass Tracker as an argument to push / pop for a cleaner interface.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2180636365

From sviswanathan at openjdk.org  Wed Jul  2 17:49:49 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 2 Jul 2025 17:49:49 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v6]
In-Reply-To: <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>
Message-ID: <TvGN9RpQyO8X2_tU2FZwP3yWdkhQkYjkkufH8HMZ-xg=.5443f90e-8532-43ab-a449-fde794e27cc1@github.com>

On Wed, 2 Jul 2025 01:57:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Intel@ AVX10 ISA [1] extensions added new floating point MIN/MAX instructions which comply with definitions in IEEE-754-2019 standard section 9.6 and can directly emulate Math.min/max semantics without the need for any special handling for NaN, +0.0 or -0.0 detection.
>> 
>> **The following pseudo-code describes the existing algorithm for min/max[FD]:**
>> 
>> Move the non-negative value to the second operand; this will ensure that we correctly handle 0.0 and -0.0 values, if values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. Existing MINPS and MAXPS semantics only check for NaN as the second operand; hence, we need special handling to check for NaN at the first operand.
>> 
>>   btmp = (b < +0.0) ? a : b
>>   atmp = (b < +0.0) ? b : a
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> For min[FD] we need a small tweak in the above algorithm, i.e., move the non-negative value to the first operand, this will ensure that we correctly select -0.0 if both the operands being compared are 0.0 or -0.0.
>> 
>>   btmp = (b < +0.0) ? b : a
>>   atmp = (b < +0.0) ? a : b
>>   Tmp = Max_Float(atmp , btmp)
>>   Res = (atmp == NaN) ? atmp : Tmp
>> 
>> Thus, we need additional special handling for NaNs and +/-0.0 to compute floating-point min/max values to comply with the semantics of Math.max/min APIs using existing MINPS / MAXPS instructions. AVX10.2 added a new instruction, VPMINMAX[SH,SS,SD]/[PH,PS,PD], which comprehensively handles special cases, thereby eliminating the need for special handling.
>> 
>> Patch emits new instructions for reduction and non-reduction operations for single, double, and Float16 type.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sandhya's review comments resolution

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25914#pullrequestreview-2980096085

From jbhateja at openjdk.org  Wed Jul  2 17:49:49 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Jul 2025 17:49:49 GMT
Subject: RFR: 8360116: Add support for AVX10 floating point minmax
 instruction [v6]
In-Reply-To: <TvGN9RpQyO8X2_tU2FZwP3yWdkhQkYjkkufH8HMZ-xg=.5443f90e-8532-43ab-a449-fde794e27cc1@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
 <qk8Zq4OlXajx7DZ3GEWZBZ_V4vcRBcEr4LBN_8PlCpE=.c0d64952-ad9e-4625-b19b-df1c36b23d38@github.com>
 <TvGN9RpQyO8X2_tU2FZwP3yWdkhQkYjkkufH8HMZ-xg=.5443f90e-8532-43ab-a449-fde794e27cc1@github.com>
Message-ID: <69bq-sgmNdZBGkcLyGo1dccJoCcC04FacUZW4CPHqkE=.ab942681-27ab-4ed6-b425-66b8487b9ab8@github.com>

On Wed, 2 Jul 2025 17:45:29 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sandhya's review comments resolution
>
> Looks good to me.

Thanks @sviswa7  and @mhaessig  for approvals.

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

PR Comment: https://git.openjdk.org/jdk/pull/25914#issuecomment-3028779791

From jbhateja at openjdk.org  Wed Jul  2 17:49:50 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 2 Jul 2025 17:49:50 GMT
Subject: Integrated: 8360116: Add support for AVX10 floating point minmax
 instruction
In-Reply-To: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
References: <QnkfV8Ww-6zI0lGBMBpPQlX02P46zYsLiIbgpCqZUu8=.60575763-89d9-4f10-b43b-04e4d4cd47b4@github.com>
Message-ID: <dLxY8VPhDRg2qhXdP2O0OwkHQ9Smt3sfr8l-EZYpeW0=.e38142bd-5ee3-42f4-8bf0-a46fb8c2a768@github.com>

On Fri, 20 Jun 2025 11:08:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Intel@ AVX10 ISA [1] extensions added new floating point MIN/MAX instructions which comply with definitions in IEEE-754-2019 standard section 9.6 and can directly emulate Math.min/max semantics without the need for any special handling for NaN, +0.0 or -0.0 detection.
> 
> **The following pseudo-code describes the existing algorithm for min/max[FD]:**
> 
> Move the non-negative value to the second operand; this will ensure that we correctly handle 0.0 and -0.0 values, if values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. Existing MINPS and MAXPS semantics only check for NaN as the second operand; hence, we need special handling to check for NaN at the first operand.
> 
>   btmp = (b < +0.0) ? a : b
>   atmp = (b < +0.0) ? b : a
>   Tmp = Max_Float(atmp , btmp)
>   Res = (atmp == NaN) ? atmp : Tmp
> 
> For min[FD] we need a small tweak in the above algorithm, i.e., move the non-negative value to the first operand, this will ensure that we correctly select -0.0 if both the operands being compared are 0.0 or -0.0.
> 
>   btmp = (b < +0.0) ? b : a
>   atmp = (b < +0.0) ? a : b
>   Tmp = Max_Float(atmp , btmp)
>   Res = (atmp == NaN) ? atmp : Tmp
> 
> Thus, we need additional special handling for NaNs and +/-0.0 to compute floating-point min/max values to comply with the semantics of Math.max/min APIs using existing MINPS / MAXPS instructions. AVX10.2 added a new instruction, VPMINMAX[SH,SS,SD]/[PH,PS,PD], which comprehensively handles special cases, thereby eliminating the need for special handling.
> 
> Patch emits new instructions for reduction and non-reduction operations for single, double, and Float16 type.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

This pull request has now been integrated.

Changeset: 5e30bf68
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e30bf68353d989aadc2d8176181226b2debd283
Stats:     465 lines in 7 files changed: 423 ins; 4 del; 38 mod

8360116: Add support for AVX10 floating point minmax instruction

Reviewed-by: mhaessig, sviswanathan

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

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

From coleenp at openjdk.org  Wed Jul  2 17:54:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 17:54:40 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop()
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>

On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

I like this change other than precond().  ModuleEntry vs java.lang.Module oops is clearer with a different method name. I've been confused by this too.

src/hotspot/share/runtime/reflection.cpp line 555:

> 553:       } else {
> 554:         oop module_oop = module_to->module_oop();
> 555:         precond(module_oop != nullptr);

I don't like precond() when you could have a useful assert message instead.

src/hotspot/share/runtime/reflection.cpp line 582:

> 580:       } else {
> 581:         oop module_oop = module_from->module_oop();
> 582:         precond(module_oop != nullptr);

same here.  "Module oop should be non-null in ModuleEntry"

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980107062
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180644851
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180646204

From iklam at openjdk.org  Wed Jul  2 18:14:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 18:14:57 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <M_GjZP2maUrKXs-aaPPYEGCTlsbz7NUALRmMESxNpXI=.6b58c427-0063-4776-b62d-dc6ad6e6512e@github.com>
Message-ID: <70Nl64CPVziB0aP054IDyxJE2YC5QV55GhkxmMgQs0E=.560e3a99-5e84-4b67-be2f-10925c6367d2@github.com>

On Wed, 2 Jul 2025 17:50:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> src/hotspot/share/runtime/reflection.cpp line 582:
> 
>> 580:       } else {
>> 581:         oop module_oop = module_from->module_oop();
>> 582:         precond(module_oop != nullptr);
> 
> same here.  "Module oop should be non-null in ModuleEntry"

We have just read the oop from the module entry and assert that it's not null, so the original message didn't add any extra information. That's why I removed it.

I have added back a message, "should have been initialized".

The real story is more complex, but I think this message willl give enough hints -- the module oop is usually initialized inside the ModuleEntry constructor, except for a few cases for the java.base module where the module oop is retroactively updated. In any case, by the time we reach this assert, the module oop must have been initialized in one of those possible paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180678283

From iklam at openjdk.org  Wed Jul  2 18:14:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 18:14:57 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @coleenp comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26102/files
  - new: https://git.openjdk.org/jdk/pull/26102/files/69b453e2..f58f2852

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

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

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

From cslucas at openjdk.org  Wed Jul  2 18:24:39 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 2 Jul 2025 18:24:39 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <3XqBb7N7ypUenwmwX2F8lRjRTeJxrXb8BfqN4vwvPa8=.eb0f51d5-8718-41b1-b89e-20b00ab9820e@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

LGTM. Thanks.

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

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25356#pullrequestreview-2980201037

From duke at openjdk.org  Wed Jul  2 18:29:38 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Wed, 2 Jul 2025 18:29:38 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v2]
In-Reply-To: <zdER4mrK6z-WYYGCPngMMN3uVZIZcwsHtIZaAFhudqU=.4551b2b6-c2cd-4d78-82b9-dc312bdb5c19@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
 <zdER4mrK6z-WYYGCPngMMN3uVZIZcwsHtIZaAFhudqU=.4551b2b6-c2cd-4d78-82b9-dc312bdb5c19@github.com>
Message-ID: <6aVkREyq0knZ_9img7BOJQex_HkT21FV97jufY80z28=.60cfcdcd-af28-44f1-b626-ecb330f26e54@github.com>

On Wed, 2 Jul 2025 16:54:55 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>>       |          (void*)
>> 1 error generated.
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>>    43 |     memset(this, 0, sizeof(*this));
>>       |            ^
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning
>>    43 |     memset(this, 0, sizeof(*this));
>>       |            ^
>>       |            (void*)
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>>    48 |     memset(this, 0, sizeof(*this));
>>       |            ^
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning
>>    48 |     memset(this, 0, sizeof(*this));
>>       |            ^
>>       |            (void*)
>> 2 errors generated.
>
> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "8361288: Fix build of JTReg: wget exited with exit code 4"
>    
>    This reverts commit 6e6b8f6a26f8e555f1e70544546b92bbafcae6cc.
>  - 8361288: Fix build of JTReg: wget exited with exit code 4

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26098#pullrequestreview-2980225708

From vpaprotski at openjdk.org  Wed Jul  2 18:35:40 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 2 Jul 2025 18:35:40 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
 <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
 <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
Message-ID: <vutvNkyloJfM31StT-NGaawuDIbtLQrrnF26gTBUSB8=.f1f43476-5e52-4e50-9757-006d9e4aac6e@github.com>

On Wed, 2 Jul 2025 17:44:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> @vamsi-parasa, It's better to make this as a subclass of MacroAssembler in src/hotspot/cpu/x86/macroAssembler_x86.hpp and pass Tracker as an argument to push / pop for a cleaner interface.

I don't think its possible? Unless I am missing something.. 
- Subclass has an instance of the base class (i.e. the memory allocation of `PushPopTracker` would have the `MacroAssembler` base class with extra fields appended); and `MacroAssembler` has already been allocated (i.e. you can't tack on more fields onto the end of the underlying memory of existing `MacroAssembler`..)
- If its a subclass, there is no reason to pass it as a parameter, because it already would have the parent's instance? Also, the extra parameter to push/pop (flag) was what I had originally objected to? (i.e. would like for push/pop to still just take one register as a parameter..)
- This class is sort of a stripped-down implementation of reference counting; we want the stack-allocated variable (i.e. explicit constructor call) and the implicit destructor calls (i.e. inserted by g++ on all function exits). That is, we must have a stack allocated variable for it to be deallocated (and destructor called for assert check)

Here is an attempt to make it a subclass? And sample usage...

class PushPopTracker : public MacroAssembler {
   private:
      int _counter;
      const int REGS = 32; // Increase as needed
      int regs[REGS];
   public:
   // MacroAssembler(CodeBuffer* code) is the only constructor?
      PushPopTracker() : _counter(0), MacroAssembler(???) {} //FIXME???
      ~PushPopTracker() {
         assert(_counter == 0, "Push/pop pair mismatch");
      }

      void push(Register reg) {
         assert(_counter<REGS, "Push/pop overflow");
         regs[_counter++] = reg.encoding();
         if (VM_Version::supports_apx_f()) {
            Assembler::pushp(reg);
         } else {
            Assembler::push(reg);
         }
      }
/*...*/
}

address StubGenerator::generate_intpoly_montgomeryMult_P256() {
  __ align(CodeEntryAlignment);
  /*...*/
  address start = __ pc();
  __ enter();
  PushPopTracker s(???); //FIXME?
  s.push(r12, /* Extra parm? */); //1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2180738209

From yzheng at openjdk.org  Wed Jul  2 18:41:46 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 18:41:46 GMT
Subject: RFR: 8357424: [JVMCI] Avoid incrementing decompilation count for
 hosted compiled nmethod [v10]
In-Reply-To: <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
 <HAwSxZPRlw7XtPL0YEBg7Urkh-dFKKgefVtRVVBk2ME=.e50b96e9-2c1b-443a-b8aa-49e995bd5d90@github.com>
Message-ID: <tA3DNbYHPp6qW4-869cSMGMDwnU9SVUp9WGv1gCuYVM=.b7f6baef-206e-44a9-8efe-f803a77a45f5@github.com>

On Wed, 2 Jul 2025 11:27:25 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Thanks for the review! Passed Tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/25356#issuecomment-3028957076

From yzheng at openjdk.org  Wed Jul  2 18:41:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Jul 2025 18:41:47 GMT
Subject: Integrated: 8357424: [JVMCI] Avoid incrementing decompilation count
 for hosted compiled nmethod
In-Reply-To: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
References: <Tlf7gJojsuXSi0SBTjCvrgEwYfuc0kUB968V_jOZpTU=.38a4841e-8073-4aa2-a9f8-c2ea4395b2e1@github.com>
Message-ID: <i43UWll9T0ApM3y8LxSFSR4V8_y9mLcEzG_gtD-HEHk=.0b4acb86-0823-4c05-99f9-bade4e7a8f68@github.com>

On Wed, 21 May 2025 15:00:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

This pull request has now been integrated.

Changeset: ea86a20e
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea86a20e6d74baea54df32415d9096d3b7bba1d7
Stats:     58 lines in 5 files changed: 48 ins; 1 del; 9 mod

8357424: [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod

Reviewed-by: dnsimon, never, cslucas

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

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

From liach at openjdk.org  Wed Jul  2 18:44:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 18:44:00 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v7]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <ut2C23h-YNJzFBPhANthT9lrqU9n2ydqrzZT_ObHBlI=.7719b345-b553-4882-b8bc-fb3bbcaa62fa@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Don't fail for patching tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/4b3906aa..4af1a6af

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

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

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

From liach at openjdk.org  Wed Jul  2 18:47:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 18:47:58 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/4af1a6af..9f6bbd9c

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

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

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

From coleenp at openjdk.org  Wed Jul  2 19:04:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 19:04:38 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980324205

From iklam at openjdk.org  Wed Jul  2 21:21:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 21:21:40 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
Message-ID: <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Documentation

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/aotClassInitializer.cpp line 219:

> 217:     // MethodHandleStatics is an example of a class that must NOT get the aot-init treatment,
> 218:     // because of its strong reliance on (a) final fields which are (b) environmentally determined.
> 219:     if (ik->has_aot_safe_initializer()) {

I think the above 4 lines of comments can be deleted, as this topic is already covered in AOTSafeClassInitializer.java.

src/hotspot/share/classfile/classFileParser.cpp line 5171:

> 5169:       InstanceKlass* intf = _transitive_interfaces->at(i);
> 5170:       if (intf->class_initializer() != nullptr) {
> 5171:         if (!intf->has_aot_safe_initializer()) {

I think this is better, so you don't need to annotate a supertypes that have no `<clinit>`


if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) {

src/hotspot/share/oops/instanceKlassFlags.hpp line 58:

> 56:     flag(has_final_method                   , 1 << 13) /* True if klass has final method */ \
> 57:     flag(has_aot_safe_initializer           , 1 << 14) /* has @AOTSafeClassInitializer annotation */ \
> 58:     flag(is_runtime_setup_required          , 1 << 15) /* has a runtimeSetup method to be called */ \

This information is useful only during CDS dumping. Since `_flags` has limited width (only 16 bits) we should avoid using these bits but rather put the information inside `DumpTimeClassInfo`. However, there's a complication here, as `DumpTimeClassInfo` is not yet created when you call `set_has_aot_safe_initializer()`.

I think you can go ahead with the current design. I will make a follow-up PR to move the creation of `DumpTimeClassInfo` to an earlier time. Then I'll move these two bits into `DumpTimeClassInfo`. That way we can accommodate more annotations in the future.

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

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2980604461
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180955211
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180988960
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180982768

From ccheung at openjdk.org  Wed Jul  2 21:28:40 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Jul 2025 21:28:40 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good.

src/hotspot/share/classfile/moduleEntry.cpp line 52:

> 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr;
> 51: 
> 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); }

(Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp?

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980677723
PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181000093

From sspitsyn at openjdk.org  Wed Jul  2 21:46:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 21:46:46 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v5]
In-Reply-To: <gjp4FJf9yoF5RkVYFlARr2NF-CLI-DH9wcoBS5FNWLY=.2a680fa0-d7a1-48d9-804b-dc9d285478f5@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <gjp4FJf9yoF5RkVYFlARr2NF-CLI-DH9wcoBS5FNWLY=.2a680fa0-d7a1-48d9-804b-dc9d285478f5@github.com>
Message-ID: <UUD8fobRYp0cNGV-TQhU8tL83IylOK9zObdkyN9Hd4Q=.0e0a056f-6137-4ba6-a7f3-904a767c42c6@github.com>

On Thu, 26 Jun 2025 16:11:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

Thank you for making these changes!
I've looked at the `jvmti` tests only and posted some questions and nits.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 82:

> 80:                 };
> 81:             }
> 82:         };

Nit: The code above is not well readable. The variable names need to be more clear, or we need some comments explaining the abbreviations. Not everyone who is reading this code is familiar with the `ClassFile` api.
 `cm`: codeModel
 `mth`: ?
 `optSmt`: ?

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 88:

> 86:             var cf = ClassFile.of(ClassFile.ConstantPoolSharingOption.NEW_POOL);
> 87:             return cf.transformClass(cf.parse(classfileBuffer), new ClassTransform() {
> 88:                 // Shuffle constant pool

Q: What does `cf` mean, class file, code model or ...?

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineGenericSignatureTest.java line 151:

> 149:         var cf = ClassFile.of();
> 150:         return cf.transformClass(cf.parse(bytecode), new ClassTransform() {
> 151:             private boolean sourceSet = false;

Q: Same question as above.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineObject.java line 71:

> 69:                 } else {
> 70:                     cb.with(ce);
> 71:                 }

Nit: I'd suggest to rename the variables with implicit types:
  `cb` => `builder` or `classBuilder`
  `ce` => `element` or `classElement`

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102:

> 100:         var cm = ClassFile.of().parse(classBytes);
> 101:         var rvaa = cm.findAttribute(Attributes.runtimeVisibleAnnotations()).orElseThrow();
> 102:         var elements = rvaa.annotations().stream().filter(anno -> anno.className().isFieldType(CD_ClassVersion)).findFirst().orElseThrow().elements();

Nit: The line above is too long.

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

Changes requested by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-2980702277
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181014791
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181020007
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181021096
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181025634
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181026494

From sspitsyn at openjdk.org  Wed Jul  2 21:52:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 21:52:43 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
Message-ID: <XHFfj4E1Pg1UcNSS8TyLYD-SVlMd7oBBVZMeHUPdASc=.651f98fd-4ff7-48e3-8050-712a3ff71c49@github.com>

On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the text of assert

Looks good. Thank you for closing second bug as a dup.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2980735724

From iklam at openjdk.org  Wed Jul  2 21:52:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Jul 2025 21:52:44 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
 <xvphoMpF8eAF7GtuW56aL_bt4DfQGXjOFdEFt6mJkqU=.c15cce10-eabb-432a-b349-c8f28e8bea8e@github.com>
Message-ID: <padCj8omasOBWPUeezaLtnnERaKzLK_TttkYctLT_p0=.578c9522-263f-46a1-93e2-a1bd6dd50b99@github.com>

On Wed, 2 Jul 2025 21:25:04 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> src/hotspot/share/classfile/moduleEntry.cpp line 52:
> 
>> 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr;
>> 51: 
>> 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); }
> 
> (Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp?

I think it's because `OopHandle::resolve()` is an inline function, but we are not allowed to include `xxx.inline.hpp` in non-inlined `.hpp` files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181036271

From sspitsyn at openjdk.org  Wed Jul  2 22:04:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Jul 2025 22:04:43 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
Message-ID: <qrt85ua0kWKGSSGyDO0XDyFFBzsiOYQ_Rurhk5BgTKA=.6f6e079b-7685-4854-8aec-8c7a6135c4f9@github.com>

On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A module has both a Java and a C++ representation
>> 
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>> 
>> In C++, we have the following two methods
>> 
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>> 
>> This can lead to confusing code like this:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module()
>> 
>> 
>> Proposal:
>> 
>> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
>> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
>> 
>> 
>> InstanceKlass* ik = ...;
>> oop module = ik->module()->module_oop()
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980760653

From mdoerr at openjdk.org  Wed Jul  2 22:32:01 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 22:32:01 GMT
Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers
 [v3]
In-Reply-To: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
Message-ID: <4flgwHZndQpyKANuyMhhYxVw9vxNbZoghJSjAqU_t1E=.5f5fb6f7-147c-49d7-9a21-653bf18384db@github.com>

> 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - 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:
  - all: https://git.openjdk.org/jdk/pull/24135/files
  - new: https://git.openjdk.org/jdk/pull/24135/files/dfc6aa5d..16f9d58e

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

  Stats: 40720 lines in 1249 files changed: 22188 ins; 12180 del; 6352 mod
  Patch: https://git.openjdk.org/jdk/pull/24135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24135/head:pull/24135

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

From liach at openjdk.org  Wed Jul  2 23:21:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:21:39 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
Message-ID: <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>

On Wed, 2 Jul 2025 21:18:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Documentation
>
> src/hotspot/share/classfile/classFileParser.cpp line 5171:
> 
>> 5169:       InstanceKlass* intf = _transitive_interfaces->at(i);
>> 5170:       if (intf->class_initializer() != nullptr) {
>> 5171:         if (!intf->has_aot_safe_initializer()) {
> 
> I think this is better, so you don't need to annotate a supertypes that have no `<clinit>`
> 
> 
> if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) {

Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181136140

From sparasa at openjdk.org  Wed Jul  2 23:32:41 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 2 Jul 2025 23:32:41 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
 <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
 <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
Message-ID: <Xyigm3QyWQf9-oqkmC28lb51YRAK4f3PZikl73RJEN8=.956a50ab-8b5e-4138-81f1-69ec0f458fa7@github.com>

On Wed, 2 Jul 2025 17:44:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker ...
>> 
>> Using the suggested code as a base, Vamsi and I tinkered with the idea some more! Here is what we came up with. This also tracks the correct order of registers being pushed/poped.. (haven't compiled it, so might have some syntax bugs).
>> 
>> @dholmes-ora would you mind sharing your opinion? We seem to be making things more complicated, but hopefully in a good way?
>> 
>> Also included a sample usage in a stub.
>> 
>> 
>> #define __ _masm->
>> 
>> class PushPopTracker {
>>    private:
>>       int _counter;
>>       MacroAssembler *_masm;
>>       const int REGS = 32; // Increase as needed
>>       int regs[REGS];
>>    public:
>>       PushPopTracker(MacroAssembler *_masm) : _counter(0), _masm(_masm) {}
>>       ~PushPopTracker() {
>>          assert(_counter == 0, "Push/pop pair mismatch");
>>       }
>> 
>>       void push(Register reg) {
>>          assert(_counter<REGS, "Push/pop overflow");
>>          regs[_counter++] = reg.encoding();
>>          if (VM_Version::supports_apx_f()) {
>>             __ pushp(reg);
>>          } else {
>>             __ push(reg);
>>          }
>>       }
>>       void pop(Register reg) {
>>          assert(_counter>0, "Push/pop underflow");
>>          assert(regs[_counter] == reg.encoding(), "Push/pop pair mismatch: %d != %d", regs[_counter], reg.encoding());
>>          _counter--;
>>          if (VM_Version::supports_apx_f()) {
>>             __ popp(reg);
>>          } else {
>>             __ pop(reg);
>>          }
>>       }
>> }
>> 
>> address StubGenerator::generate_intpoly_montgomeryMult_P256() {
>>   __ align(CodeEntryAlignment);
>>   /*...*/
>>   address start = __ pc();
>>   __ enter();
>>   PushPopTracker s(_masm);
>>   s.push(r12); //1
>>   s.push(r13); //2
>>   s.push(r14); //3
>>   #ifdef _WIN64
>>   s.push(rsi); //4
>>   s.push(rdi); //5
>>   #endif
>>   s.push(rbp); //6
>>   __ movq(rbp, rsp);
>>   __ andq(rsp, -32);
>>   __ subptr(rsp, 32);
>>   // Register Map
>>   const Register aLimbs  = c_rarg0; // c_rarg0: rdi | rcx
>>   const Register bLimbs  = rsi;     // c_rarg1: rsi | rdx
>>   const Register rLimbs  = r8;      // c_rarg2: rdx | r8
>>   const Register tmp1    = r9;
>>   const Register tmp2    = r10;
>>   /*...*/
>>   __ movq(rsp, rbp);
>>   s.pop(rbp); //5
>>   #ifdef _WIN64
>>   s.pop(rdi); //4
>>   s.pop(rsi); //3
>>   #endif
>>   s.pop(r14); //2
>>   s.pop(r13); //1
>>   s.pop(r12); //0
>>   __ leave();
>>   __ ret(0);
>>   return start;
>> }
>
> @vamsi-parasa, It's better to make this as a subclass of MacroAssembler in src/hotspot/cpu/x86/macroAssembler_x86.hpp and pass Tracker as an argument to push / pop for a cleaner interface.

Hi Jatin (@jatin-bhateja) and Vlad (@vpaprotsk),

There's one more issue to be considered. The C++ PushPopTracker code will be run during the stub generation time. There are code bocks which do a single push onto the stack but due to multiple exit paths, there will be multiple pops as illustrated below. Will this reference counting approach not fail in such a scenario as the stub code is generated all at once during the stub generation phase?


#begin stack frame
push(r21)

#exit condition 1
pop(r21)

# exit condition 2
pop(r21)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2181146890

From amenkov at openjdk.org  Wed Jul  2 23:34:42 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 2 Jul 2025 23:34:42 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors
In-Reply-To: <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com>
Message-ID: <x0fhICUTD_TN51hdziXSHbYuOS0mbhFv-3IGMP-v_Yo=.081a3a00-aab3-4b4b-86c1-0f430644a4b6@github.com>

On Wed, 2 Jul 2025 07:16:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not very familiar with these aspects of C++ but this seems to be a very complex solution to what sounds in JBS to be a pretty straight-forward problem.

Straight-forward solution would be to add copy ctor for Iterator class which clones GrowableArray (allocates new instance and copies all elements).
But I'm not quite happy with the current implementation of AgentList and its iterator, so prefer to update it to keep entries in the original order (and iterator becomes much simpler).
Changes in the callers are required as they used `const JvmtiAgentList::Iterator` and const `next` method is removed.

> src/hotspot/share/prims/jvmtiAgentList.cpp line 35:
> 
>> 33: 
>> 34: JvmtiAgent* JvmtiAgentList::_head = nullptr;
>> 35: JvmtiAgent** JvmtiAgentList::_tail = nullptr;
> 
> Why is the tail a pointer to a pointer? Sorry I'm not understanding how your list is being managed here.
> 
> I'm trying to work out where you need acquire/release because I'm pretty sure it is missing where needed, but again I can't understand how you are actually constructing and using the list.

pointer to pointer because it contains not the pointer to the last agent in the list, but address of the `JvmtiAgent::_next` field.
`_tail` is for faster adding at the end of the list. Performance is not important here and number of agents is always low, so I think `_tail` can be removed to make the logic simpler. Will update the fix after testing completes

> src/hotspot/share/prims/jvmtiAgentList.cpp line 105:
> 
>> 103:   while (true) {
>> 104:     // set _tail to address of agent->_next
>> 105:     JvmtiAgent** tail = Atomic::load_acquire(&_tail);
> 
> You don't need acquire semantics here as you are not doing anything with the `_tail` pointer value other than use it in relation to cmpxchg which provides fully memory barriers.

ok, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3029654109
PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181149878
PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181149860

From iklam at openjdk.org  Thu Jul  3 00:11:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 00:11:39 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
 <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
Message-ID: <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>

On Wed, 2 Jul 2025 23:18:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 5171:
>> 
>>> 5169:       InstanceKlass* intf = _transitive_interfaces->at(i);
>>> 5170:       if (intf->class_initializer() != nullptr) {
>>> 5171:         if (!intf->has_aot_safe_initializer()) {
>> 
>> I think this is better, so you don't need to annotate a supertypes that have no `<clinit>`
>> 
>> 
>> if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) {
>
> Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`?

local_interfaces is fine, because the interfaces implemented by the super classes would have been checked when the super classes were loaded.

BTW, the error message should include the name of both this class and the supertype:


classfile_parse_error("AOTSafeClassInitlaizer annotation is required for supertype %s of %s", ...


And the checks can be refactored in a separate function to avoid repetition.


if (_super_klass != nullptr) {
  check_aot_safe_initializer(ik, _super_klass, CHECK);
}
int len = _local_interfaces->length();
for (int i = 0; i < len; i++) {
  check_aot_safe_initializer(ik, _local_interfaces->at(i), CHECK);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181197886

From iklam at openjdk.org  Thu Jul  3 00:14:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 00:14:39 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
Message-ID: <GXiSwpPB8Kfv053HunyiwKSRCLouHzoWo_K86jWiEV0=.a78c4783-aed5-4d0c-badf-3be939cec490@github.com>

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Documentation

src/hotspot/share/classfile/classFileParser.cpp line 2684:

> 2682:     if (name != vmSymbols::runtimeSetup() || signature != vmSymbols::void_method_signature() ||
> 2683:         !access_flags.is_private() || !access_flags.is_static()) {
> 2684:       classfile_parse_error("Incorrect runtimeSetup method declaration in class file %s", CHECK_NULL);

Error message should be more specific:

"AOTRuntimeSetup annotation requires the method to be static private void runtimeSetup() for class %s"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181200542

From haosun at openjdk.org  Thu Jul  3 00:17:43 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 3 Jul 2025 00:17:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <bovYqrJ61tTxcrXitVCTEo9kva41LwyQkjf2A1A6zec=.1cc050f3-ae75-405e-8a0e-711de95487af@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

> @shqking I hope the arm build will now work ok.

Thanks for your fix. Yes. It works now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3029773525

From haosun at openjdk.org  Thu Jul  3 00:17:44 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 3 Jul 2025 00:17:44 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
Message-ID: <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>

On Wed, 2 Jul 2025 10:37:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - fix inconsistent stub declarations

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Intel Corporation. All rights reserved.

nit: Incorrect format. One comma is missing. Should be `2025,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2181192848

From amenkov at openjdk.org  Thu Jul  3 01:17:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 01:17:56 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v2]
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26083/files
  - new: https://git.openjdk.org/jdk/pull/26083/files/c93b598f..994ffddc

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

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

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

From kbarrett at openjdk.org  Thu Jul  3 01:32:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:32:53 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
Message-ID: <fN-YSbHIJgK0sJ_O9fEtRgXSPyzrVT10D7_Cds5zvn0=.9a06b83c-984c-4f87-bce8-46639c458e4f@github.com>

On Wed, 2 Jul 2025 13:51:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
>> 
>> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
>> 
>> Tested in tiers 1-3 and GHA.
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:
> 
>> 934:     __builtin_unreachable();
>> 935:   }
>> 936: #endif
> 
> I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
> function.

Although I wonder why the assert in Thread::current() isn't sufficient? Maybe non-null info isn't
propagating through the cast to JavaThread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181311538

From kbarrett at openjdk.org  Thu Jul  3 01:52:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:52:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <SPURRbg_QDlnGackOfs8p6LKFH3f9AdHgRZu_s_bUkA=.183c6e9d-48be-4bf4-8f85-9923da9da039@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

make/hotspot/lib/CompileJvm.gmk line 199:

> 197:     DISABLED_WARNINGS_gcc_macroAssembler_ppc_sha.cpp := unused-const-variable, \
> 198:     DISABLED_WARNINGS_gcc_postaloc.cpp := address, \
> 199:     DISABLED_WARNINGS_gcc_shenandoahLock.cpp := stringop-overflow, \

What about this one in shenandoahLock.cpp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181357398

From sspitsyn at openjdk.org  Thu Jul  3 02:04:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 02:04:46 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v2]
In-Reply-To: <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>
Message-ID: <X9nYvDfFkr6SYTJ798nK3lQPGwaMJpnWSNbr2Sc81_E=.a8e91e55-3797-44a1-9c29-41159542b84b@github.com>

On Thu, 3 Jul 2025 01:17:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Changes requested by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiAgentList.hpp line 30:

> 28: //#include "nmt/memTag.hpp"
> 29: #include "prims/jvmtiAgent.hpp"
> 30: //#include "utilities/growableArray.hpp"

Nit: You might want to remove unneeded headers. :)

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

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2981271238
PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181383291

From sspitsyn at openjdk.org  Thu Jul  3 02:16:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 02:16:43 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v2]
In-Reply-To: <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>
Message-ID: <ZVvRkBV5sq8u0ANJWbckJpdWQeg2ZhWVPvJyQtnL2DE=.c2b9d2fd-da5e-4896-b0cb-b8909d6221b7@github.com>

On Thu, 3 Jul 2025 01:17:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

The updated version without `_tail` looks better. :)
You have some trailing spaces to fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3030287828

From amenkov at openjdk.org  Thu Jul  3 03:01:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 03:01:52 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v3]
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <aYbfM1NbE997TEr2b8W3i1PSG88bdWDOUGiEXKzYg-c=.a39004b7-7e3b-4fc1-8e75-3d0b9a6c6566@github.com>

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed commented includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26083/files
  - new: https://git.openjdk.org/jdk/pull/26083/files/994ffddc..aeb2b26c

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

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

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

From amenkov at openjdk.org  Thu Jul  3 03:08:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 03:08:26 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v4]
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26083/files
  - new: https://git.openjdk.org/jdk/pull/26083/files/aeb2b26c..bf91aef2

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

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

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

From amenkov at openjdk.org  Thu Jul  3 03:13:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 03:13:39 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v2]
In-Reply-To: <X9nYvDfFkr6SYTJ798nK3lQPGwaMJpnWSNbr2Sc81_E=.a8e91e55-3797-44a1-9c29-41159542b84b@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <Wvdxsw33QxKnHlr68K5JbcghzflFOG2HMUfkwZjYZ78=.005efeea-48a4-4422-888b-fc3bbd09aca6@github.com>
 <X9nYvDfFkr6SYTJ798nK3lQPGwaMJpnWSNbr2Sc81_E=.a8e91e55-3797-44a1-9c29-41159542b84b@github.com>
Message-ID: <r99vVG_xIDedbraiGITL7NFGfDroKs4idGbmS3U8sXE=.8ac7f0d9-94e2-45cd-a9b3-f182414479d3@github.com>

On Thu, 3 Jul 2025 02:00:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/hotspot/share/prims/jvmtiAgentList.hpp line 30:
> 
>> 28: //#include "nmt/memTag.hpp"
>> 29: #include "prims/jvmtiAgent.hpp"
>> 30: //#include "utilities/growableArray.hpp"
> 
> Nit: You might want to remove unneeded headers. :)

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181490591

From dholmes at openjdk.org  Thu Jul  3 04:29:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 04:29:38 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v4]
In-Reply-To: <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>
Message-ID: <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com>

On Thu, 3 Jul 2025 03:08:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

Okay - still took me a little while to understand the double-indirection of the "tail ptr" in `add`, but I get it now. So looking at the acquire/release requirements:
- all additions are done with `cmpxchg` which is effectively a release-store
- when you iterate the list all loads of the "next" agent must be a load-acquire, this means
  - when you create the iterator you need a load-acquire (which you have when you pass `head()` )
  - In `Iterator::next()` you need a load-acquire on each read of the `_next` field which is most simply done by defining `JvmtiAgent::next()` as a load-acquire and using that in the iterator code instead of direct field access. 
- `JvmtiAgent::set_next` should be a release-store though as far as I can see it is not used.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2981588585

From dholmes at openjdk.org  Thu Jul  3 04:34:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 04:34:39 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v2]
In-Reply-To: <zdER4mrK6z-WYYGCPngMMN3uVZIZcwsHtIZaAFhudqU=.4551b2b6-c2cd-4d78-82b9-dc312bdb5c19@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
 <zdER4mrK6z-WYYGCPngMMN3uVZIZcwsHtIZaAFhudqU=.4551b2b6-c2cd-4d78-82b9-dc312bdb5c19@github.com>
Message-ID: <gkYTLWmYot2LQVn3tWgyDAB1TVbZruGX0uxTGolhYlc=.b3397e54-5d15-4744-98ec-7f9e0a5598c3@github.com>

On Wed, 2 Jul 2025 16:54:55 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>>       |          (void*)
>> 1 error generated.
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>>    43 |     memset(this, 0, sizeof(*this));
>>       |            ^
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning
>>    43 |     memset(this, 0, sizeof(*this));
>>       |            ^
>>       |            (void*)
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall]
>>    48 |     memset(this, 0, sizeof(*this));
>>       |            ^
>> src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning
>>    48 |     memset(this, 0, sizeof(*this));
>>       |            ^
>>       |            (void*)
>> 2 errors generated.
>
> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "8361288: Fix build of JTReg: wget exited with exit code 4"
>    
>    This reverts commit 6e6b8f6a26f8e555f1e70544546b92bbafcae6cc.
>  - 8361288: Fix build of JTReg: wget exited with exit code 4

@jankratochvil  please provide a PR description that actually describes the code changes in the PR, not just the errors that motivated the PR to be created. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26098#issuecomment-3030656108

From dholmes at openjdk.org  Thu Jul  3 04:55:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 04:55:39 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <EU4y_XmwWNwv71_jdB9gAFGMYeU7917l7g722XNlOg8=.c1500814-65f5-460a-88d6-35a677294ebd@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <EU4y_XmwWNwv71_jdB9gAFGMYeU7917l7g722XNlOg8=.c1500814-65f5-460a-88d6-35a677294ebd@github.com>
Message-ID: <VkcQ9wveSzWc_zYGOhnZcSiBk_kUk-A3u2MrKMg-AVU=.03077fce-a8d2-4368-9191-0f6d412ba5af@github.com>

On Thu, 19 Jun 2025 06:39:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Just a drive-by comment as this isn't code I normally have much to do with but to me it would look a lot cleaner to define `push_paired`/`pop_paired` (maybe abbreviating directly to `pushp`/`popp`?) rather than passing the boolean.

> @dholmes-ora would you mind sharing your opinion? We seem to be making things more complicated, but hopefully in a good way?

Seems very complicated to me. Really this is for compiler folk to discuss. And as noted above this "tracker" class only helps where the push/pop are paired in the same scope. Personally I think a "pushp" that is defined to be a "push-paired" when available, else a regular "push", would suffice in terms of API design. But again this is for compiler folk to determine.

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

PR Comment: https://git.openjdk.org/jdk/pull/25889#issuecomment-3030744652

From ccheung at openjdk.org  Thu Jul  3 05:27:27 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 05:27:27 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt
Message-ID: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>

After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.

Testing: passed tiers 1 - 5.

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

Commit messages:
 - 8361325: Refactor ClassLoaderExt

Changes: https://git.openjdk.org/jdk/pull/26110/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361325
  Stats: 228 lines in 15 files changed: 59 ins; 165 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26110/head:pull/26110

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

From kbarrett at openjdk.org  Thu Jul  3 05:36:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 05:36:42 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

My suggestion of using assertions instead doesn't seem to work, still getting
bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses
__atomic_load. That is mysteriously weird. The noreturn reporting function
should be roughly equivalent to calling an ordinary function with an
"unreachable" following it. But then, this whole issue is mysteriously weird.

But that's okay; I wasn't really all that keen on adding assertions to
suppress bogus compiler warnings anyway.

At this point I think this change should just not be made. It's a compiler
bug. The existing suppression of the warnings is fine with me.

I think what's really needed is for someone to file a gcc bug.  It's too bad
nobody did that when the issue was first noticed.  There's already a bug that
is similar, and might even be the same, even though it involves sanitizers and
ours doesn't:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3030839463

From sspitsyn at openjdk.org  Thu Jul  3 06:12:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 06:12:13 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown
 for reasons other than a native method
Message-ID: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>

It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
This impacts the following JVMTI functions:
  - `PopFrame`
  - `NotifyFramePop`
  - `ForceEarlyReturn<Type>`

A related CSR is going to be filed for this spec update.

Testing:
 - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

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

Commit messages:
 - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

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

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

From asemenov at openjdk.org  Thu Jul  3 07:03:44 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 3 Jul 2025 07:03:44 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>
 <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com>
Message-ID: <WU7Dp438HOw5_2NLjlLS6lupqIO76EXdm0cpF-OOEhY=.c8dbe8de-7fad-4795-9531-2ba767b54943@github.com>

On Tue, 1 Jul 2025 00:31:25 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed if tu assert
>
> Marked as reviewed by amenkov (Reviewer).

@alexmenkov @plummercj @dholmes-ora do you mind the integration?

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3031112862

From jsjolen at openjdk.org  Thu Jul  3 07:33:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 3 Jul 2025 07:33:40 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
Message-ID: <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>

On Mon, 26 May 2025 08:56:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
> 
> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
> 
> Testing
>  - new test
>  - Tiers 1-4 (sanity)

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25444#pullrequestreview-2982067633

From duke at openjdk.org  Thu Jul  3 07:47:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 07:47:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
Message-ID: <YunUc3j5XRipL9egR5B7dqs0ANTJ6ETSL2udnFcBXDY=.ea2ee97d-caf9-4a06-b02a-f63aebe00f8a@github.com>

On Thu, 3 Jul 2025 05:34:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> My suggestion of using assertions instead doesn't seem to work, still getting bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses __atomic_load. That is mysteriously weird. The noreturn reporting function should be roughly equivalent to calling an ordinary function with an "unreachable" following it. But then, this whole issue is mysteriously weird.
> 
> But that's okay; I wasn't really all that keen on adding assertions to suppress bogus compiler warnings anyway.
> 
> At this point I think this change should just not be made. It's a compiler bug. The existing suppression of the warnings is fine with me.
> 
> I think what's really needed is for someone to file a gcc bug. It's too bad nobody did that when the issue was first noticed. There's already a bug that is similar, and might even be the same, even though it involves sanitizers and ours doesn't: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

Thanks @kimbarrett, after looking at your findings I agree that it looks like a GCC bug, and therefore we should not do this change. I will try to make the smallest reproducible example and submit a bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3031232698

From adinn at openjdk.org  Thu Jul  3 08:40:32 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 08:40:32 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v4]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <myEltdp_Fa6ouP17dm6KdCaDHT16ToRW0t_SkAHH7l8=.c127d22d-1334-4642-b961-4482622093f5@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  fix format for copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/e42ec698..6d4eee55

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

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

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

From alanb at openjdk.org  Thu Jul  3 09:00:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:00:47 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>

On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI functions:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
> 
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

src/hotspot/share/prims/jvmti.xml line 3082:

> 3080:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 3081:           The implementation is unable to provide this functionality on this frame
> 3082:           (e.g. the frame at <code>depth</code> is executing a native method).

It might be better to say "unable to generate a FramePop event for the frame" rather than "unable to provide this functionality on this frame".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2182246125

From adinn at openjdk.org  Thu Jul  3 09:38:48 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 09:38:48 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
 <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>
Message-ID: <FCLuK2shoeZi3d4uHtZAVzs8paahKtxdNPfT5M-gxY0=.853ecd61-fc6a-45de-bcab-19d74011b4e1@github.com>

On Thu, 3 Jul 2025 00:05:17 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - fix inconsistent stub declarations
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Intel Corporation. All rights reserved.
> 
> nit: Incorrect format. One comma is missing. Should be `2025,`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2182328732

From duke at openjdk.org  Thu Jul  3 12:04:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 12:04:44 GMT
Subject: Withdrawn: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <ifHIvUSdpFXevUEdGdw4H2NlTNegBILudXcalRwNBpQ=.7f952342-0bcb-4ba4-be49-6618d4b6755d@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Thu Jul  3 12:10:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 12:10:42 GMT
Subject: RFR: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
 <w7vQUXXc-vl7ftD658Cxya47RE1nAC0A67U8q9F3WwE=.913fdbe7-8ed2-4f22-a1e6-69da6c10b9ce@github.com>
Message-ID: <IMmZiYES2zlKmTb1XrdZHTKEvlcYN7GybYy7kOlgXSs=.1e08a30e-a723-4ac5-b518-70c36f378409@github.com>

On Thu, 3 Jul 2025 07:31:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
>> 
>> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
>> 
>> Testing
>>  - new test
>>  - Tiers 1-4 (sanity)
>
> LGTM

Thanks for the review @jdksjolen !

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

PR Comment: https://git.openjdk.org/jdk/pull/25444#issuecomment-3032027659

From shade at openjdk.org  Thu Jul  3 12:37:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 12:37:44 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added [v4]
In-Reply-To: <GrAnNsFwx7gPs3ek-pzexinbFEPpG6hTAKDxJhyCiqw=.ed8d04b1-d93f-44aa-acf5-5c926b1ed4a9@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <GrAnNsFwx7gPs3ek-pzexinbFEPpG6hTAKDxJhyCiqw=.ed8d04b1-d93f-44aa-acf5-5c926b1ed4a9@github.com>
Message-ID: <63g6Wu2xF4iZeUPfaM1Q2iwtTMQS8W7NlzVs4QguDHY=.ef3690d9-3c2e-4191-acf7-7285a3239d1d@github.com>

On Wed, 2 Jul 2025 16:02:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleep comments

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25816#pullrequestreview-2982995488

From coleenp at openjdk.org  Thu Jul  3 13:02:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 13:02:38 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt
In-Reply-To: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
Message-ID: <UFY9MDafN5IpceVsjPblCD3wDA5LysYRFC3MzhCu_-c=.10b9083c-60a6-4520-bd18-6ee1ce4661d0@github.com>

On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.
> 
> Testing: passed tiers 1 - 5.

This looks great. I never liked the Ext name.  I had a tiny comment.

src/hotspot/share/classfile/modules.cpp line 671:

> 669:   // list[3] = ""
> 670:   // list[4] = ""
> 671:   list.sort(Modules::compare_module_names);

Does compare _module_names have to be an external function?

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2983066152
PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2182718450

From adinn at openjdk.org  Thu Jul  3 13:19:32 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 13:19:32 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - save blobs using blob ids
 - make arg in declaration consistent with definition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/6d4eee55..776cbe90

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

  Stats: 81 lines in 12 files changed: 52 ins; 0 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/26004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26004/head:pull/26004

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

From liach at openjdk.org  Thu Jul  3 14:26:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 14:26:42 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v8]
In-Reply-To: <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
 <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
 <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>
Message-ID: <_33LVgbvoF-SWOlZNwVbaxNxhGWc7HmZf8sW4qd3gww=.66d0a41b-3c26-4a05-9f4d-0fddb2ac4a72@github.com>

On Thu, 3 Jul 2025 00:09:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`?
>
> local_interfaces is fine, because the interfaces implemented by the super classes would have been checked when the super classes were loaded.
> 
> BTW, the error message should include the name of both this class and the supertype:
> 
> 
> classfile_parse_error("AOTSafeClassInitlaizer annotation is required for supertype %s of %s", ...
> 
> 
> And the checks can be refactored in a separate function to avoid repetition.
> 
> 
> if (_super_klass != nullptr) {
>   check_aot_safe_initializer(ik, _super_klass, CHECK);
> }
> int len = _local_interfaces->length();
> for (int i = 0; i < len; i++) {
>   check_aot_safe_initializer(ik, _local_interfaces->at(i), CHECK);
> }

I don't want to introduce a new declaration in the header for this function - to shrink the size, I think I can use `guarantee_property` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2182930135

From adinn at openjdk.org  Thu Jul  3 14:43:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 14:43:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

@ashu-mehra Could you please review this PR. In particular, can you check the modifications I just made to the aotCodeCache blob save/load API. We need to save the blob using a blob id rather than a stub id.

n.b. I had to re-enable the AOTStubCaching flag to test these latest changes (currently, it is always disabled in aotCodeCache.cpp). None of the blob save/restore functionality is exercised without that override.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3032528784

From sspitsyn at openjdk.org  Thu Jul  3 15:13:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 15:13:39 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt
In-Reply-To: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
Message-ID: <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>

On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.
> 
> Testing: passed tiers 1 - 5.

It looks good to me. I like this simplification.
But I'm curious what was the original reason to have the `classLoaderExt`?

src/hotspot/share/cds/classListParser.cpp line 33:

> 31: #include "cds/metaspaceShared.hpp"
> 32: #include "cds/unregisteredClasses.hpp"
> 33: #include "classfile/classLoader.hpp"

Nit: I wonder if the line #33 is really needed and can be removed.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2983562923
PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183031189

From vpaprotski at openjdk.org  Thu Jul  3 15:14:42 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 3 Jul 2025 15:14:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs
In-Reply-To: <Xyigm3QyWQf9-oqkmC28lb51YRAK4f3PZikl73RJEN8=.956a50ab-8b5e-4138-81f1-69ec0f458fa7@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
 <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
 <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
 <Xyigm3QyWQf9-oqkmC28lb51YRAK4f3PZikl73RJEN8=.956a50ab-8b5e-4138-81f1-69ec0f458fa7@github.com>
Message-ID: <3R2flcCvwCbIMgCJqOVnrUXgAZJsi9Ja2r4is2tCnLg=.cab9d74a-7998-466c-9d24-8672f3f8883b@github.com>

On Wed, 2 Jul 2025 23:28:42 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> @vamsi-parasa, It's better to make this as a subclass of MacroAssembler in src/hotspot/cpu/x86/macroAssembler_x86.hpp and pass Tracker as an argument to push / pop for a cleaner interface.
>
> Hi Jatin (@jatin-bhateja) and Vlad (@vpaprotsk),
> 
> There's one more issue to be considered. The C++ PushPopTracker code will be run during the stub generation time. There are code bocks which do a single push onto the stack but due to multiple exit paths, there will be multiple pops as illustrated below. Will this reference counting approach not fail in such a scenario as the stub code is generated all at once during the stub generation phase?
> 
> 
> #begin stack frame
> push(r21)
> 
> #exit condition 1
> pop(r21)
> 
> # exit condition 2
> pop(r21)

Now that I had my fun writing an array-backed stack.. (and with David's comment too..) I can admit that the point of the entire C++ Tracker class is to 'just' add an assert; doesn't actually functionally add to the original code, but does add better JIT/stub compile-time checking.

@vamsi-parasa you are right.. if there are ifs and multiple exit paths in the assembler itself.. the Tracker wont be able to catch it (multiple exits paths in the generator are just fine though); I was thinking about this problem too last night... a hack/'solution' would be to disable such checking with a default flag in the constructor... 'fairly trivial' but just adds to the complexity even more. And the assert was the point of the class to begin with... I do think such stubs are rare?

There is some value in improved checking, but enough? Writing stubs is already an 'you should know assembler very well' thing so those checks only improve things marginally overall? As David says, its for the compiler folks to decide :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2183043350

From sspitsyn at openjdk.org  Thu Jul  3 15:24:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 15:24:39 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v4]
In-Reply-To: <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>
Message-ID: <cDBiy9liSM74sFQqIWXhCJa_-7e6TfuxkzTLO7D8D98=.816f2c48-f594-4ba1-a492-181be65e1553@github.com>

On Thu, 3 Jul 2025 03:08:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

This looks good to me.
I hope, David will sort out where the `Atomic::` operations are needed.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2983633781

From sspitsyn at openjdk.org  Thu Jul  3 15:33:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 3 Jul 2025 15:33:41 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>
Message-ID: <FZwQjYWg-ZsVK1Yr2YQikAZy7fVyqExxB8gZq87xUE0=.dbb94e97-5ddd-4db6-9c32-c5dbc13d4d98@github.com>

On Thu, 3 Jul 2025 08:57:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI functions:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>> 
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> src/hotspot/share/prims/jvmti.xml line 3082:
> 
>> 3080:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 3081:           The implementation is unable to provide this functionality on this frame
>> 3082:           (e.g. the frame at <code>depth</code> is executing a native method).
> 
> It might be better to say "unable to generate a FramePop event for the frame" rather than "unable to provide this functionality on this frame".

Good suggestion, thanks.
`NotifyFramePop` does not generate the `FramePop` events by itself it is just sets or enables events.
Then should we say this way: "unable to set a `FramePop` event for the frame" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183102777

From iklam at openjdk.org  Thu Jul  3 15:34:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 15:34:55 GMT
Subject: RFR: 8358680: AOT cache creation fails: no strings should have
 been added
In-Reply-To: <1NT3dmBpabeSJ0HMglupev2ONGKaMH9XuMKZYiBwqZw=.32eb98c0-2ed1-46ef-b4b1-166e7d3f791d@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
 <1NT3dmBpabeSJ0HMglupev2ONGKaMH9XuMKZYiBwqZw=.32eb98c0-2ed1-46ef-b4b1-166e7d3f791d@github.com>
Message-ID: <gz0ouz8aT05Ivc-M16g0vXk-0W0g9OWm-yin48dOZao=.0aa6eb93-99d5-4298-9c48-a69cdd78bddb@github.com>

On Wed, 18 Jun 2025 17:27:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Background: when writing the string table in the AOT cache, we do this:
>> 
>> 1. Find out the number of strings in the interned string table
>> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
>> 3. Enter safepoint
>> 4. Copy the strings into the arrays
>> 
>> This bug happened because:
>> 
>> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
>> - JIT compiler threads may create more interned strings after step 1
>> 
>> This PR attempts to fix both issues.
>
> I still dislike hooking up to compiler infrastructure to figure out if something is adding interned strings. I really, really dislike the divergence we would introduce with JDK 25 -> JDK 26 once a variant of [JDK-8357473](https://bugs.openjdk.org/browse/JDK-8357473) lands in mainline. I cannot yet think of better solution though, let me think about it some more. At very least we need to get the sequencing of patches right...

Thanks @shipilev @coleenp for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25816#issuecomment-3032716174

From iklam at openjdk.org  Thu Jul  3 15:34:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 15:34:55 GMT
Subject: Integrated: 8358680: AOT cache creation fails: no strings should have
 been added
In-Reply-To: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
References: <AawKTXOA2jAULdTj3N5Y94S_TotrgAlxmhbj_V9ALf4=.963bdb9d-1672-46d5-beef-3d6497b59bf5@github.com>
Message-ID: <B4Ic9waR90br9CYqz44wU-acK9q4pU7lVo1vWKc6Pk8=.c78b96f4-a498-40a5-8ac0-b255dcac83eb@github.com>

On Mon, 16 Jun 2025 03:30:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Background: when writing the string table in the AOT cache, we do this:
> 
> 1. Find out the number of strings in the interned string table
> 2. Allocate Java object arrays that are large enough to store these strings. These arrays are used by `StringTable::lookup_shared()` in the production run.
> 3. Enter safepoint
> 4. Copy the strings into the arrays
> 
> This bug happened because:
> 
> - Step 1 is not thread safe, so it may be reading a stale version of `_items_count`
> - JIT compiler threads may create more interned strings after step 1
> 
> This PR attempts to fix both issues.

This pull request has now been integrated.

Changeset: 3daa03c3
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3daa03c30f8e6ab9c498edb7d59346ce0b30450f
Stats:     65 lines in 8 files changed: 47 ins; 2 del; 16 mod

8358680: AOT cache creation fails: no strings should have been added

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: coleenp, shade

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

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

From asmehra at openjdk.org  Thu Jul  3 15:38:46 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 15:38:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
 <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>
Message-ID: <trlKMVPHfX78lIbqVc2ArlhdZ65wNDVL5T-9MrrXgp8=.28384fee-bcd9-45d7-a712-a4b6d83db2fc@github.com>

On Thu, 3 Jul 2025 14:41:27 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>
> @ashu-mehra Could you please review this PR. In particular, can you check the modifications I just made to the aotCodeCache blob save/load API. We need to save the blob using a blob id rather than a stub id.
> 
> n.b. I had to re-enable the AOTStubCaching flag to test these latest changes (currently, it is always disabled in aotCodeCache.cpp). None of the blob save/restore functionality is exercised without that override.

@adinn yes, I have been reviewing it. Slowly making my way through the code :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3032731124

From sparasa at openjdk.org  Thu Jul  3 15:45:41 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 3 Jul 2025 15:45:41 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
 <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>
Message-ID: <xYBTl1H9ZImgNVL4p1IXaOQp673dnNmQzJ1jCSPepr4=.c31eb9cd-4f1c-449a-8a52-9ed0889fde9d@github.com>

On Wed, 2 Jul 2025 15:27:02 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Submitted testing for commit 2 / v01 :)
>
Hi Emanuel (@eme64), 
If the testing has passed, could you pls let me know?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3032750246

From liach at openjdk.org  Thu Jul  3 16:53:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 16:53:25 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v9]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <aDKxT2BNBfinqhaWg24t2vANW8GTxogAZPlu39iXqJ0=.9095018b-c3f4-496e-9447-8d06a006a898@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/9f6bbd9c..47c5affa

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

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

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

From iklam at openjdk.org  Thu Jul  3 16:55:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 16:55:45 GMT
Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2]
In-Reply-To: <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
 <OtGisXjjDeWnvHa0c8faNZ0Bx-NTd8u6tQvBapsZi5c=.5eafbaf0-f6fd-41f5-9d1f-70540bd99280@github.com>
 <ZDpGtEPKiX9ABvT2DVwM3EbindU67prj_rfEIf1szUQ=.e557edf9-b673-46dd-887d-a33297cd28c8@github.com>
Message-ID: <7t8AhNKgTL2MU_ba0F3rCllEqaodLFmshj_9QvGwY00=.1ba3ff82-905d-4b7a-8b4a-6944f5b22b5e@github.com>

On Wed, 2 Jul 2025 19:02:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comments
>
> Marked as reviewed by coleenp (Reviewer).

Thanks @coleenp @calvinccheung @sspitsyn for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26102#issuecomment-3032931506

From iklam at openjdk.org  Thu Jul  3 16:55:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Jul 2025 16:55:46 GMT
Subject: Integrated: 8361292: Rename ModuleEntry::module() to module_oop()
In-Reply-To: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
References: <fevM1KWdtEw7RJ6RpoA9IZBq5wB5zT_YFoE6NCqHa9Y=.481c6e48-11d1-48bd-908d-0381fbfafe69@github.com>
Message-ID: <fXTbvFMYMe66iLraa3BsajA01nJEjlG-7x5AF-n9UcE=.c1e291d9-ed1d-4ca8-bd3b-8917f838f55b@github.com>

On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> A module has both a Java and a C++ representation
> 
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
> 
> In C++, we have the following two methods
> 
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
> 
> This can lead to confusing code like this:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module()
> 
> 
> Proposal:
> 
> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()`
> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable:
> 
> 
> InstanceKlass* ik = ...;
> oop module = ik->module()->module_oop()

This pull request has now been integrated.

Changeset: 66836d40
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66836d40b80f9c5482c1322d1d07f078ad9dcc02
Stats:     35 lines in 12 files changed: 0 ins; 0 del; 35 mod

8361292: Rename ModuleEntry::module() to module_oop()

Reviewed-by: coleenp, ccheung, sspitsyn

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

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

From ccheung at openjdk.org  Thu Jul  3 17:12:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 17:12:55 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>
Message-ID: <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>

On Thu, 3 Jul 2025 15:10:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the `classLoaderExt`?

I think it was created during the first revision of AppCDS back in JDK 8u.

> src/hotspot/share/cds/classListParser.cpp line 33:
> 
>> 31: #include "cds/metaspaceShared.hpp"
>> 32: #include "cds/unregisteredClasses.hpp"
>> 33: #include "classfile/classLoader.hpp"
> 
> Nit: I wonder if the line #33 is really needed and can be removed.

It is needed or else I got compilation error:

open/src/hotspot/share/cds/classListParser.cpp:561:29: error: 'ClassLoader' has not been declared
  561 |   const char* source_path = ClassLoader::uri_to_path(_source);
      |                             ^~~~~~~~~~~

It worked before because classLoaderExt.hpp includes classLoader.hpp.

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

PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3032983136
PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183292645

From ccheung at openjdk.org  Thu Jul  3 17:12:56 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 17:12:56 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <UFY9MDafN5IpceVsjPblCD3wDA5LysYRFC3MzhCu_-c=.10b9083c-60a6-4520-bd18-6ee1ce4661d0@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <UFY9MDafN5IpceVsjPblCD3wDA5LysYRFC3MzhCu_-c=.10b9083c-60a6-4520-bd18-6ee1ce4661d0@github.com>
Message-ID: <OrNZytonao1qGD6Ui-HWiqp_YdRszwArMzX8jwauGQ4=.8be52f42-5240-49fe-91c1-2cd6a6e7f56b@github.com>

On Thu, 3 Jul 2025 12:56:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @coleenp comment
>
> src/hotspot/share/classfile/modules.cpp line 671:
> 
>> 669:   // list[3] = ""
>> 670:   // list[4] = ""
>> 671:   list.sort(Modules::compare_module_names);
> 
> Does compare _module_names have to be an external function?

I've changed it to a static function in modules.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183286022

From ccheung at openjdk.org  Thu Jul  3 17:12:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 17:12:55 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
Message-ID: <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com>

> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.
> 
> Testing: passed tiers 1 - 5.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @coleenp comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26110/files
  - new: https://git.openjdk.org/jdk/pull/26110/files/19942e19..4cbd71fc

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

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

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

From coleenp at openjdk.org  Thu Jul  3 17:29:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 17:29:39 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com>
Message-ID: <QFua90FMm3lOslIvrzCsgzUN0B0O0W85_c5-O7xJpYc=.46951d4b-f76b-4618-88a6-064b88921d57@github.com>

On Thu, 3 Jul 2025 17:12:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.
>> 
>> Testing: passed tiers 1 - 5.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comment

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2984015341

From coleenp at openjdk.org  Thu Jul  3 17:29:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 17:29:40 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>
 <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>
Message-ID: <jJerCrNco7mK9cA7xb04D35Z-ILz55FHPvVbVTt45FM=.abe5cc67-f56e-44a7-b7cd-d7e427fd3352@github.com>

On Thu, 3 Jul 2025 17:10:03 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the classLoaderExt?

I think it was from before we settled on the Shared suffix for CDS methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3033021163

From cjplummer at openjdk.org  Thu Jul  3 18:52:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 3 Jul 2025 18:52:39 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>

On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI functions:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
> 
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

src/hotspot/share/prims/jvmti.xml line 2991:

> 2989:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 2990:           The implementation is unable to pop this frame
> 2991:           (e.g. called or calling method is a native method).

Directly below we have special OPAQUE_FRAME language for virtual threads. Do we want to get rid of it since it is now covered by the above language? Note there is also language directly above that discusses suspended virtual threads.

src/hotspot/share/prims/jvmti.xml line 3191:

> 3189:       <errors>
> 3190:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 3191:           The implementation is unable to force current frame to return

Suggestion:

          The implementation is unable to force the current frame to return

src/hotspot/share/prims/jvmti.xml line 3194:

> 3192:           (e.g. current frame is executing a native method).
> 3193:         </error>
> 3194:         <error id="JVMTI_ERROR_OPAQUE_FRAME">

Do we still need this section? Same question for repeated sections below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183507709
PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183513041
PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183515227

From cjplummer at openjdk.org  Thu Jul  3 18:52:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 3 Jul 2025 18:52:39 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
Message-ID: <C8G8kMI--vdkKzq4F6NCw--mmPILtALSXvK7ObKQm1M=.db567f36-e5a5-408f-89b2-7da9099b9f6f@github.com>

On Thu, 3 Jul 2025 18:43:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI functions:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>> 
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> src/hotspot/share/prims/jvmti.xml line 3191:
> 
>> 3189:       <errors>
>> 3190:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 3191:           The implementation is unable to force current frame to return
> 
> Suggestion:
> 
>           The implementation is unable to force the current frame to return

Note this error repeats a few times below. I only tagged this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183517279

From amenkov at openjdk.org  Thu Jul  3 19:13:24 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 19:13:24 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v5]
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <dooBxSgz7TAeXd5Pt7sfPtVVVAE-zWS8iWMCJb_LZPE=.c01c997d-98a2-48c9-a6b8-bd1fe1ebed8e@github.com>

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  David's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26083/files
  - new: https://git.openjdk.org/jdk/pull/26083/files/bf91aef2..b1b2dc3f

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

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

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

From amenkov at openjdk.org  Thu Jul  3 19:15:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 19:15:40 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v4]
In-Reply-To: <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <QMNLQ1mzqWm_EB0gxLbdPvqFNYBZr82QJ5-6_yBsnpo=.09fe199d-6b13-4fa1-9a8c-48f4c916fcd6@github.com>
 <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com>
Message-ID: <VUUH-mAaaesloaz4wKyTmrvvFqAfGStasMSufKYBYwY=.7fe45cba-0570-472e-abe3-1975eb53efac@github.com>

On Thu, 3 Jul 2025 04:27:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay - still took me a little while to understand the double-indirection of the "tail ptr" in `add`, but I get it now. So looking at the acquire/release requirements:
> 
>     * all additions are done with `cmpxchg` which is effectively a release-store
> 
>     * when you iterate the list all loads of the "next" agent must be a load-acquire, this means
>       
>       * when you create the iterator you need a load-acquire (which you have when you pass `head()` )
>       * In `Iterator::next()` you need a load-acquire on each read of the `_next` field which is most simply done by defining `JvmtiAgent::next()` as a load-acquire and using that in the iterator code instead of direct field access.
> 
>     * `JvmtiAgent::set_next` should be a release-store though as far as I can see it is not used.

Thank you for the detailed analysis.
Updated as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3033349842

From asmehra at openjdk.org  Thu Jul  3 19:30:46 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 19:30:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

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

> 974:   // try to reuse an existing stub
> 975:   {
> 976:     StubId stub_id = static_cast<StubId>(_stub_id);

`static_cast` can be avoided if `_stub_id` type is changed from `int` to `StubId`. And there is a similar `static_cast` in output.cpp as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2183613368

From asmehra at openjdk.org  Thu Jul  3 19:34:43 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 19:34:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <ZPlMR3aLsfThYqwbKzFndV2MttxnYi40r-vE0YmRioY=.a7acaf93-fc4f-4f82-a2dd-75fbb1424960@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

Marked as reviewed by asmehra (Committer).

Looks good to me. I have just a minor comment. Thanks for these changes. This should help in simplifying the AOTCodeAddressTable.

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

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2984447568
PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3033390099

From ccheung at openjdk.org  Thu Jul  3 19:42:42 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 19:42:42 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <jJerCrNco7mK9cA7xb04D35Z-ILz55FHPvVbVTt45FM=.abe5cc67-f56e-44a7-b7cd-d7e427fd3352@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>
 <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>
 <jJerCrNco7mK9cA7xb04D35Z-ILz55FHPvVbVTt45FM=.abe5cc67-f56e-44a7-b7cd-d7e427fd3352@github.com>
Message-ID: <yDIhl-hzB4Ah3y_Ll4m-9IyYlIFGZ0-PTSPONL0a98k=.08c28e54-8cf5-4488-9f62-438de2f24ebf@github.com>

On Thu, 3 Jul 2025 17:26:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the `classLoaderExt`?
>> 
>> I think it was created during the first revision of AppCDS back in JDK 8u.
>
>> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the classLoaderExt?
> 
> I think it was from before we settled on the Shared suffix for CDS methods.

Thanks @coleenp @sspitsyn for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3033406876

From ccheung at openjdk.org  Thu Jul  3 19:42:43 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 3 Jul 2025 19:42:43 GMT
Subject: Integrated: 8361325: Refactor ClassLoaderExt
In-Reply-To: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
Message-ID: <xkSXtwb4aoObYuuQNmy7x-DjZuucqWku1V7jUUKDw7Q=.fcd748db-4fb9-41be-bbf6-ffa9b6244cae@github.com>

On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated.
> 
> Testing: passed tiers 1 - 5.

This pull request has now been integrated.

Changeset: 003be0de
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/003be0dee2f6c190697ec0a923546362c50cc0e5
Stats:     228 lines in 14 files changed: 59 ins; 165 del; 4 mod

8361325: Refactor ClassLoaderExt

Reviewed-by: coleenp, sspitsyn

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

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

From amenkov at openjdk.org  Thu Jul  3 19:58:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 19:58:52 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread
Message-ID: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>

The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.

Testing: tier1..5

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

Commit messages:
 - Merge branch 'master' into tlh_stack_trace
 - fix

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

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

From kvn at openjdk.org  Thu Jul  3 19:58:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 3 Jul 2025 19:58:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

> @vnkozlov Could you please rereview this?

This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3033448504

From amenkov at openjdk.org  Thu Jul  3 20:03:06 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 20:03:06 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
Message-ID: <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>

> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
> 
> Testing: tier1..5

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update javaClasses.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26119/files
  - new: https://git.openjdk.org/jdk/pull/26119/files/fa20e584..f4932e4c

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

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

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

From amenkov at openjdk.org  Thu Jul  3 20:21:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 3 Jul 2025 20:21:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
Message-ID: <8V_RMuDb8LuGqkCk6mqH7M9ZrTjzYBBu-yKx8VTtvfA=.c7ab7581-1579-4d9f-8548-21e05fd4f653@github.com>

On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the text of assert

I'm fine with the fix, the only question if it helps with the analysis tool.

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3033515986

From cjplummer at openjdk.org  Thu Jul  3 20:31:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 3 Jul 2025 20:31:41 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v4]
In-Reply-To: <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <x3IKfYyK4PH1b7LcRA4CbZvc4b2XcBUK5_g1xsYr0hk=.402cc1fe-6980-4049-8784-48f031d189c0@github.com>
Message-ID: <xJrlt0k5sxz_xGyn8b7fghr7c_nHwuyM_xujgw0DEIY=.de61df69-ee1b-4f5b-83a6-80a21b2bc81b@github.com>

On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the text of assert

Same here. I just don't want to see the CR refiled if the analysis tool still complains.

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

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3033543386

From dlong at openjdk.org  Thu Jul  3 20:33:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Jul 2025 20:33:51 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints
Message-ID: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>

The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

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

Commit messages:
 - allow Thread::print_on() from JRT_LEAF
 - tighten VerifyStack constraints

Changes: https://git.openjdk.org/jdk/pull/26121/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278874
  Stats: 171 lines in 4 files changed: 84 ins; 50 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

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

From dholmes at openjdk.org  Thu Jul  3 21:05:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 21:05:47 GMT
Subject: Integrated: 8357601: Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
In-Reply-To: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
References: <Zg4Zabq290iG7P02xAkGT_fHXEsur-GE-w4-piJYc0E=.e0c38720-75bd-4b2a-9d6f-a225749b5a29@github.com>
Message-ID: <O1bMDjfI3XGbj1peRdAqcKjdO1Hi90BdevtNdA8Udxk=.1ffd6b86-125c-4c70-93aa-df2cff97c8ae@github.com>

On Mon, 26 May 2025 08:56:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The checked version of `Get`/`Release<type>ArrayElements` uses `GuardedMemory` to perform error checking. When releasing the array the code needs to check for the known array tags from the other JNI APIs and report an error.
> 
> We also expand `GuardedMemory` to allow for a second tag word so that we can discriminate additional allocation sites i.e. identifying use of `Get`/`SetPrimitiveArrayCritical`. And add further robustness to guard verification by using `SafeFetch`.
> 
> Testing
>  - new test
>  - Tiers 1-4 (sanity)

This pull request has now been integrated.

Changeset: da0a51ce
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69
Stats:     343 lines in 6 files changed: 321 ins; 6 del; 16 mod

8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays

Reviewed-by: coleenp, jsjolen

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

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

From dholmes at openjdk.org  Thu Jul  3 22:20:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 22:20:32 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
Message-ID: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>

In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.

The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.

Testing:
 - new regression test
 - tiers 1-4

Thanks

PS. The diff is much smaller if you disable whitespace differences.

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

Commit messages:
 - regression test
 - 8356942: invokeinterface Throws AbstractMethodError Instead of IncompatibleClassChangeError

Changes: https://git.openjdk.org/jdk/pull/26122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356942
  Stats: 128 lines in 6 files changed: 83 ins; 6 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/26122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26122/head:pull/26122

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

From dholmes at openjdk.org  Thu Jul  3 23:03:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Jul 2025 23:03:30 GMT
Subject: [jdk25] RFR: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
Message-ID: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>

Hi all,

This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.

Thanks!

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

Commit messages:
 - Backport da0a51ce97453a47b2c7d11e5206774232309e69

Changes: https://git.openjdk.org/jdk/pull/26123/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26123&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357601
  Stats: 343 lines in 6 files changed: 321 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26123.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26123/head:pull/26123

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

From ccheung at openjdk.org  Fri Jul  4 00:29:39 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 4 Jul 2025 00:29:39 GMT
Subject: [jdk25] RFR: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
References: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
Message-ID: <I9CBlbSTxb4ZEqcFk1NB3BuGn_-f-SNKSSh6ru0QjNY=.d438085c-9f9d-4917-8edb-b822d8e1a590@github.com>

On Thu, 3 Jul 2025 22:58:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.
> 
> Thanks!

Looks identical to the original fix.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26123#pullrequestreview-2985003230

From dholmes at openjdk.org  Fri Jul  4 00:56:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Jul 2025 00:56:40 GMT
Subject: [jdk25] RFR: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <I9CBlbSTxb4ZEqcFk1NB3BuGn_-f-SNKSSh6ru0QjNY=.d438085c-9f9d-4917-8edb-b822d8e1a590@github.com>
References: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
 <I9CBlbSTxb4ZEqcFk1NB3BuGn_-f-SNKSSh6ru0QjNY=.d438085c-9f9d-4917-8edb-b822d8e1a590@github.com>
Message-ID: <aHYLs9ubkDztLNnpi-lrsabDH2_wS9ZzPsp-m9wBdXs=.0dbe11ad-0524-47d9-9507-f985e98b5ebd@github.com>

On Fri, 4 Jul 2025 00:26:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.
>> 
>> Thanks!
>
> Looks identical to the original fix.

Thanks for the review @calvinccheung !

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

PR Comment: https://git.openjdk.org/jdk/pull/26123#issuecomment-3034059655

From dholmes at openjdk.org  Fri Jul  4 01:30:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Jul 2025 01:30:41 GMT
Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors [v5]
In-Reply-To: <dooBxSgz7TAeXd5Pt7sfPtVVVAE-zWS8iWMCJb_LZPE=.c01c997d-98a2-48c9-a6b8-bd1fe1ebed8e@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
 <dooBxSgz7TAeXd5Pt7sfPtVVVAE-zWS8iWMCJb_LZPE=.c01c997d-98a2-48c9-a6b8-bd1fe1ebed8e@github.com>
Message-ID: <9P6FzQv_JcweZlUxC53Sc6w4IWfTm5e6uKJIUEtIkYw=.8b11c478-86e4-4f61-8002-acaec28501a4@github.com>

On Thu, 3 Jul 2025 19:13:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
>> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
>> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
>> 
>> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
>> Iterator now needs only single pointer to next agent.
>> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's feedback

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2985155397

From dholmes at openjdk.org  Fri Jul  4 01:49:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Jul 2025 01:49:38 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
Message-ID: <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>

On Thu, 3 Jul 2025 20:03:06 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javaClasses.cpp

Generally looks good. A couple of minor nits/queries.

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 1896:

> 1894:       return nullptr;
> 1895:     }
> 1896:     java_thread = java_lang_Thread::thread(carrier_thread);

Won't `java_thread` already have been set correctly by `cv_internal_thread_to_JavaThread`?

src/hotspot/share/classfile/javaClasses.cpp line 1899:

> 1897:   }
> 1898:   if (java_thread == nullptr) {
> 1899:     // terminated platform thread or unmounted virtual thread

Wasn't the unmounted virtual thread case already handled by the return at line 1894?

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

PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-2985170142
PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2184115254
PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2184116032

From dlong at openjdk.org  Fri Jul  4 02:33:33 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 4 Jul 2025 02:33:33 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  fix optimized build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/a2694ede..5b7d4bca

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

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

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

From fyang at openjdk.org  Fri Jul  4 05:53:39 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 4 Jul 2025 05:53:39 GMT
Subject: RFR: 8360000: RISC-V: implement aot
In-Reply-To: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
Message-ID: <x0q4eWzTDgHoINsvMs3MB0HmFAHljmHmmBn08Va0WtI=.f889c3c4-7111-473b-9f3b-f06f793fbd88@github.com>

On Wed, 2 Jul 2025 17:14:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
> 
> Riscv should support these features and resolve relative issues.
> 
> ## Test
> 
> ### jtreg
> 
> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
> 
> ### Performance
> 
> perf command to run the simplest Hello world java program:
> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
> 
> perf data:
> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
> 
> Thanks

Hi, Thanks for working on enabling this feature.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 766:

> 764:   BLOCK_COMMENT(str);
> 765:   illegal_instruction(Assembler::csr::time);
> 766:   emit_int64((uintptr_t)str);

I noticed that our aarch64 counterpart puts the address of msg into `r0` in https://github.com/openjdk/jdk/pull/24740.

  // load msg into r0 so we can access it from the signal handler
  // ExternalAddress enables saving and restoring via the code cache
  lea(c_rarg0, ExternalAddress((address) str));


And fetches the address from `r0` in `PosixSignals::pd_hotspot_signal_handler`:

        // A pointer to the message will have been placed in `r0`
        const char *detail_msg = (const char *)(uc->uc_mcontext.regs[0]);


I am not sure but I guess this is needed for the correct working of aot? Maybe we should do similar things.

src/hotspot/share/code/aotCodeCache.cpp line 131:

> 129: // and does final AOT state and flags settings.
> 130: void AOTCodeCache::initialize() {
> 131: #if defined(ZERO) || !(defined(AMD64) || defined(AARCH64) || defined(RISCV64))

Nit: You might want to mention `RISCV64` in code comment for the corresponding #endif at L199.
`#endif // defined(AMD64) || defined(AARCH64)`

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

PR Review: https://git.openjdk.org/jdk/pull/26101#pullrequestreview-2981131967
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2184472508
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2181291531

From alanb at openjdk.org  Fri Jul  4 06:18:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Jul 2025 06:18:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <FZwQjYWg-ZsVK1Yr2YQikAZy7fVyqExxB8gZq87xUE0=.dbb94e97-5ddd-4db6-9c32-c5dbc13d4d98@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>
 <FZwQjYWg-ZsVK1Yr2YQikAZy7fVyqExxB8gZq87xUE0=.dbb94e97-5ddd-4db6-9c32-c5dbc13d4d98@github.com>
Message-ID: <T2jD2fR71aA1qcF_uHlMNAHPbc4kMxjV8TMLblykv5Y=.779947bb-3db5-44d5-ae18-ae0e0b9b8746@github.com>

On Thu, 3 Jul 2025 15:31:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Then should we say this way: "unable to set a `FramePop` event for the frame" ?

The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2184504203

From epeter at openjdk.org  Fri Jul  4 06:19:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Our internal testing passes. Fix looks reasonable. Thanks for the work!

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2985721144

From duke at openjdk.org  Fri Jul  4 06:19:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <DJUNLWT0eOOLd5Y0TqI_-ZUH69dzW5HYP_U6MMA-l4Q=.ca766898-6be4-4500-b295-7a5dd0be94a9@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

@vamsi-parasa 
Your change (at version de7c373f49b14bfb759b6498b7b81a8d0b39a213) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3034667366

From sparasa at openjdk.org  Fri Jul  4 06:19:51 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>
Message-ID: <h-goFbX22rJZwnGu5Fy0R71HhpKvElbQ6xKPaF4HcMs=.6b2a2a5e-85e8-4fda-818e-a1adfa87d769@github.com>

On Fri, 4 Jul 2025 06:14:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Our internal testing passes. Fix looks reasonable. Thanks for the work!

Thank you, Emanuel! :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3034666181

From mhaessig at openjdk.org  Fri Jul  4 13:09:43 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 4 Jul 2025 13:09:43 GMT
Subject: RFR: 8361253: CommandLineOptionTest library should report observed
 values on failure
In-Reply-To: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <B50VrFF4cosZr3-q5epTDQUfy5jUu6xAc10_SMuZGvE=.e5048402-b44e-43c7-abfe-891a9c1141f1@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of 
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value
> 
> 
> a mismatch in the `CICompilerCount` will now print
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'.
> 
> 
> Testing:
>  - [x] Github Actions
>  - [x] tier1 through tier3 plus Oracle internal testing

Thank you for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26092#issuecomment-3036225388

From mhaessig at openjdk.org  Fri Jul  4 13:09:44 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 4 Jul 2025 13:09:44 GMT
Subject: Integrated: 8361253: CommandLineOptionTest library should report
 observed values on failure
In-Reply-To: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <oqmJs3clVaLgoT4gTT3pk3nRp6EybIbvzIctSkyM2ZI=.03539e5f-a6aa-4d14-ba43-c26703a65f9f@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of 
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value
> 
> 
> a mismatch in the `CICompilerCount` will now print
> 
> 
> java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'.
> 
> 
> Testing:
>  - [x] Github Actions
>  - [x] tier1 through tier3 plus Oracle internal testing

This pull request has now been integrated.

Changeset: f153e415
Author:    Manuel H?ssig <mhaessig at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f153e415d740f4ede272929171e9bb3e73ddbe1c
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8361253: CommandLineOptionTest library should report observed values on failure

Reviewed-by: dholmes, shade

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

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

From mli at openjdk.org  Fri Jul  4 13:50:05 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 4 Jul 2025 13:50:05 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
Message-ID: <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>

> Hi,
> Can you help to review this patch?
> 
> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
> 
> Riscv should support these features and resolve relative issues.
> 
> ## Test
> 
> ### jtreg
> 
> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
> 
> ### Performance
> 
> perf command to run the simplest Hello world java program:
> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
> 
> perf data:
> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
> 
> Thanks

Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:

 - pass msg via a0 in stop
 - comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26101/files
  - new: https://git.openjdk.org/jdk/pull/26101/files/b70493e2..bc05a32f

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

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

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

From mli at openjdk.org  Fri Jul  4 13:50:05 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 4 Jul 2025 13:50:05 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <x0q4eWzTDgHoINsvMs3MB0HmFAHljmHmmBn08Va0WtI=.f889c3c4-7111-473b-9f3b-f06f793fbd88@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <x0q4eWzTDgHoINsvMs3MB0HmFAHljmHmmBn08Va0WtI=.f889c3c4-7111-473b-9f3b-f06f793fbd88@github.com>
Message-ID: <olC9uMW3nk2GRuUQECACixstf6Ot5YhdlCOREg1_s1A=.2190fb5d-278a-4ec1-ac7c-deb9cc639750@github.com>

On Fri, 4 Jul 2025 05:48:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - pass msg via a0 in stop
>>  - comment
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 766:
> 
>> 764:   BLOCK_COMMENT(str);
>> 765:   illegal_instruction(Assembler::csr::time);
>> 766:   emit_int64((uintptr_t)str);
> 
> I noticed that our aarch64 counterpart puts the address of msg into `r0` in https://github.com/openjdk/jdk/pull/24740.
> 
>   // load msg into r0 so we can access it from the signal handler
>   // ExternalAddress enables saving and restoring via the code cache
>   lea(c_rarg0, ExternalAddress((address) str));
> 
> 
> And fetches the address from `r0` in `PosixSignals::pd_hotspot_signal_handler`:
> 
>         // A pointer to the message will have been placed in `r0`
>         const char *detail_msg = (const char *)(uc->uc_mcontext.regs[0]);
> 
> 
> I am not sure but I guess this is needed for the correct working of aot? Maybe we should do similar things.

My test shows that it's fine to keep the current way to pass the stop message to sig handler, in both dump and use time. Seems currently both ways work.
But to keep the consistency with other platforms, I'll change it too.

> src/hotspot/share/code/aotCodeCache.cpp line 131:
> 
>> 129: // and does final AOT state and flags settings.
>> 130: void AOTCodeCache::initialize() {
>> 131: #if defined(ZERO) || !(defined(AMD64) || defined(AARCH64) || defined(RISCV64))
> 
> Nit: You might want to mention `RISCV64` in code comment for the corresponding #endif at L199.
> `#endif // defined(AMD64) || defined(AARCH64)`

fixed, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2185419585
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2185425398

From sparasa at openjdk.org  Fri Jul  4 15:11:47 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 4 Jul 2025 15:11:47 GMT
Subject: Integrated: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
Message-ID: <EW0wIarX2r97PhyyWdgpvb3IIYBFe6lfFl3jX4umNKU=.78d6deb0-5986-46f6-a02a-3440bfcf35c0@github.com>

On Fri, 27 Jun 2025 00:02:08 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
> 
> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
> 
> Both the issues are fixed in this PR.

This pull request has now been integrated.

Changeset: 1c560727
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee
Stats:     41 lines in 2 files changed: 40 ins; 0 del; 1 mod

8360775: Fix Shenandoah GC test failures when APX is enabled

Reviewed-by: sviswanathan, jbhateja, epeter

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

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

From iwalulya at openjdk.org  Fri Jul  4 15:28:20 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 4 Jul 2025 15:28:20 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - Albert suggestions
 - Improve comment
 - Thomas Review
 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - Thomas Review
 - Reviews
 - Albert suggestions
 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - remove unrequired changes - kim
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f153e415...5c388d54

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

Changes: https://git.openjdk.org/jdk/pull/25832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=10
  Stats: 618 lines in 16 files changed: 395 ins; 89 del; 134 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From mdoerr at openjdk.org  Sat Jul  5 12:50:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 5 Jul 2025 12:50:39 GMT
Subject: [jdk25] RFR: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
References: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
Message-ID: <LT0I_s5IUJaTDUjRWmytOeNT1iOfw0xVOAOE1palthc=.8bd276db-ccf5-4550-9d05-bb97fc23bef5@github.com>

On Thu, 3 Jul 2025 22:58:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.
> 
> Thanks!

The change breaks Big Endian and platforms which don't support unaligned accesses. See related issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26123#issuecomment-3038890134

From dholmes at openjdk.org  Sun Jul  6 12:02:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 12:02:51 GMT
Subject: [jdk25] RFR: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
References: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
Message-ID: <Zae0Aacdg90VNsqzeLI9asJqA0B_PCfQNDD7mGGVxoU=.bc4ded6b-3822-4d6f-b3d0-2cb44cf668f9@github.com>

On Thu, 3 Jul 2025 22:58:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.
> 
> Thanks!

This PR is cancelled as the fix in mainline is flawed and being backed out.

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

PR Comment: https://git.openjdk.org/jdk/pull/26123#issuecomment-3041379942

From dholmes at openjdk.org  Sun Jul  6 12:02:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 12:02:52 GMT
Subject: [jdk25] Withdrawn: 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
References: <Hg_Dq-2glzzlfHAxqHRJCX4c_2io9KflQ07y1tC-x_8=.03cf5f26-c5df-440a-9f7f-2b3bb8252802@github.com>
Message-ID: <JGePKKZTGt6H4TTNRWDb36u_uK-nSQBPsvgOxdPqEWk=.d831f14a-7428-42ad-b2fe-3b7fea492dfd@github.com>

On Thu, 3 Jul 2025 22:58:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [da0a51ce](https://github.com/openjdk/jdk/commit/da0a51ce97453a47b2c7d11e5206774232309e69) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 3 Jul 2025 and was reviewed by Coleen Phillimore and Johan Sj?len.
> 
> Thanks!

This pull request has been closed without being integrated.

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

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

From adinn at openjdk.org  Sun Jul  6 15:25:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 15:25:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v6]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <M4YJwJGbjdQuwyMyG20wRdw45wz-5-7n_B2I3_uXxTA=.7d89c719-9054-4238-a076-63cab8a8ccfe@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  store stub id for opto stub Compile instances as a StubId

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/776cbe90..59479dce

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

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

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

From adinn at openjdk.org  Sun Jul  6 15:25:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 15:25:47 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
 <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>
Message-ID: <NfgEHEUEWTGAVjH8usTNoMPRQ3Y4AnCuYeWW0B9IRiA=.b66c99c5-a6e0-4bc5-9c55-61bdb232f7d7@github.com>

On Thu, 3 Jul 2025 19:27:05 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>
> src/hotspot/share/opto/compile.cpp line 976:
> 
>> 974:   // try to reuse an existing stub
>> 975:   {
>> 976:     StubId stub_id = static_cast<StubId>(_stub_id);
> 
> `static_cast` can be avoided if `_stub_id` type is changed from `int` to `StubId`. And there is a similar `static_cast` in output.cpp as well.

I think this conversion to int was done to avoid a problem with include dependencies. It is certainly not an issue now that StubId is statically generated in a header already included in all affected files. I have pushed a fix to remove the int casts and use StubId instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2188392663

From adinn at openjdk.org  Sun Jul  6 16:57:12 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 16:57:12 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn 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 18 additional commits since the last revision:

 - Merge branch 'master' into enumerate_entries
 - store stub id for opto stub Compile instances as a StubId
 - save blobs using blob ids
 - make arg in declaration consistent with definition
 - fix format for copyright
 - update copyrights
 - fix inconsistent stub declarations
 - fix formatting issues
 - remove redundant doc comments
 - fix copy paste errors in riscv
 - ... and 8 more: https://git.openjdk.org/jdk/compare/8aa42991...dbc8394a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/59479dce..dbc8394a

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

  Stats: 25634 lines in 968 files changed: 12312 ins; 8365 del; 4957 mod
  Patch: https://git.openjdk.org/jdk/pull/26004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26004/head:pull/26004

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

From adinn at openjdk.org  Sun Jul  6 16:57:12 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 16:57:12 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
Message-ID: <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>

On Thu, 3 Jul 2025 19:56:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I submitted testing.
>
>> @vnkozlov Could you please rereview this?
> 
> This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.

@vnkozlov 
> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3042206980

From zgu at openjdk.org  Sun Jul  6 20:17:44 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
Message-ID: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>

On Wed, 18 Jun 2025 09:00:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

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

> 69:   // True in product build, since tests using debug build often stress GC
> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);

Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:

> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
> 380: 
> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {

I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.

What benefits do you get?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160152953
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160163706

From zgu at openjdk.org  Sun Jul  6 20:17:44 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
Message-ID: <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>

On Mon, 19 May 2025 11:05:59 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> The one inside the safepoint will print sth `log_info(gc)("GCOverheadLimitThreshold ...`. There can be multiple concurrent mutators reaching here; printing here is undesirable.
>> 
>> I don't think throwing OOM, from gc's perspective, is an "error".
>
>> I don't think throwing OOM, from gc's perspective, is an "error".
> 
> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.

Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.

I wonder if you can improve this situtation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2181262727

From zgu at openjdk.org  Sun Jul  6 20:17:46 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 6 Jul 2025 20:17:46 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
Message-ID: <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>

On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> 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/psParallelCompact.cpp line 898:

> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
> 898:                                    + SpaceAlignment;

Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188503009

From ayang at openjdk.org  Sun Jul  6 21:10:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
Message-ID: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>

On Sat, 21 Jun 2025 20:56:37 GMT, Zhengyu Gu <zgu 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 pull request now contains 19 commits:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - Merge branch 'master' into pgc-size-policy
>>  - revert-aliases
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - merge-fix
>>  - merge
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363
>
> src/hotspot/share/gc/parallel/parallelArguments.cpp line 71:
> 
>> 69:   // True in product build, since tests using debug build often stress GC
>> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
>> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);
> 
> Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`

It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...".

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:
> 
>> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
>> 380: 
>> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
> 
> I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.
> 
> What benefits do you get?

I don't see how I changed the semantics.

On baseline, from `mem_allocate_work`:


if (result != nullptr) {
  return result;
}

// If certain conditions hold, try allocating from the old gen.
if (!is_tlab) {
  result = mem_allocate_old_gen(size);
  if (result != nullptr) {
    return result;
  }
}


and


HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
  if (!should_alloc_in_eden(size)) {
    // Size is too big for eden.
    return allocate_old_gen_and_record(size);
  }

  return nullptr;
}


The original logic is essentially:


if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
  // allocate in old-gen
}

which is the same as I put here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188594599
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604946

From ayang at openjdk.org  Sun Jul  6 21:10:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
Message-ID: <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>

On Thu, 3 Jul 2025 00:52:56 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>>> I don't think throwing OOM, from gc's perspective, is an "error".
>> 
>> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.
>
> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.
> 
> I wonder if you can improve this situtation.

Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot.

Is my understanding correct?

(Seems that baseline resets the condition and can encounter the same problem as well.)


        if (limit_exceeded && softrefs_clear) {
          *gc_overhead_limit_was_exceeded = true;
          size_policy()->set_gc_overhead_limit_exceeded(false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604729

From ayang at openjdk.org  Sun Jul  6 21:10:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 6 Jul 2025 21:10:45 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
 <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
Message-ID: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>

On Sun, 6 Jul 2025 18:03:14 GMT, Zhengyu Gu <zgu 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/parallel/psParallelCompact.cpp line 898:
> 
>> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
>> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
>> 898:                                    + SpaceAlignment;
> 
> Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?

The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188611386

From dholmes at openjdk.org  Sun Jul  6 21:21:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 21:21:21 GMT
Subject: RFR: 8361439: [BACKOUT] 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
Message-ID: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>

Revert "8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays"

This reverts commit da0a51ce97453a47b2c7d11e5206774232309e69.

Thanks

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

Commit messages:
 - Revert "8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays"

Changes: https://git.openjdk.org/jdk/pull/26146/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26146&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361439
  Stats: 343 lines in 6 files changed: 6 ins; 321 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26146/head:pull/26146

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

From lmesnik at openjdk.org  Sun Jul  6 21:42:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 6 Jul 2025 21:42:41 GMT
Subject: RFR: 8361439: [BACKOUT] 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>
References: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>
Message-ID: <32bZKAPwmqagVG7q2KQ_IfTfFlDRcZ3VG8rAF7lzUaU=.3a4581f2-dd99-49f1-85ed-40e0de7b385a@github.com>

On Sun, 6 Jul 2025 21:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays"
> 
> This reverts commit da0a51ce97453a47b2c7d11e5206774232309e69.
> 
> Thanks

Assuming that it is a clean backout, it looks good and trivial.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26146#pullrequestreview-2991727256

From dholmes at openjdk.org  Sun Jul  6 21:47:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 21:47:42 GMT
Subject: RFR: 8361439: [BACKOUT] 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <32bZKAPwmqagVG7q2KQ_IfTfFlDRcZ3VG8rAF7lzUaU=.3a4581f2-dd99-49f1-85ed-40e0de7b385a@github.com>
References: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>
 <32bZKAPwmqagVG7q2KQ_IfTfFlDRcZ3VG8rAF7lzUaU=.3a4581f2-dd99-49f1-85ed-40e0de7b385a@github.com>
Message-ID: <BvNkvkJL_SVp8r44Cng07bNc6zfOtLbeG2-dOmYJ2r4=.ae159b1f-ff19-4af2-a207-938cab5330b4@github.com>

On Sun, 6 Jul 2025 21:40:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Revert "8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays"
>> 
>> This reverts commit da0a51ce97453a47b2c7d11e5206774232309e69.
>> 
>> Thanks
>
> Assuming that it is a clean backout, it looks good and trivial.

Thanks @lmesnik !

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

PR Comment: https://git.openjdk.org/jdk/pull/26146#issuecomment-3042789589

From dholmes at openjdk.org  Sun Jul  6 21:47:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 6 Jul 2025 21:47:42 GMT
Subject: Integrated: 8361439: [BACKOUT] 8357601: Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>
References: <0D3Zz2GgVpzNef_sfGWxi3WM9GAkGf-GLdq_cUdHonA=.e443ba75-0e24-40e0-9985-c61abaf1ce22@github.com>
Message-ID: <WRhvhyGdm2-td-P0S7gnH4XrDIpUlS3NU9Vf7iwV-60=.d3036977-de84-4542-9695-7617949643b6@github.com>

On Sun, 6 Jul 2025 21:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays"
> 
> This reverts commit da0a51ce97453a47b2c7d11e5206774232309e69.
> 
> Thanks

This pull request has now been integrated.

Changeset: 3bcbcc57
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bcbcc5747f9402796a1d9443d7a27d37acee9e0
Stats:     343 lines in 6 files changed: 6 ins; 321 del; 16 mod

8361439: [BACKOUT] 8357601: Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays

Reviewed-by: lmesnik

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

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

From iklam at openjdk.org  Sun Jul  6 23:07:20 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 6 Jul 2025 23:07:20 GMT
Subject: [jdk25] RFR: 8358680: AOT cache creation fails: no strings should have
 been added
Message-ID: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>

Hi all,

This pull request contains a backport of commit [3daa03c3](https://github.com/openjdk/jdk/commit/3daa03c30f8e6ab9c498edb7d59346ce0b30450f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Ioi Lam on 3 Jul 2025 and was reviewed by Coleen Phillimore and Aleksey Shipilev.

Thanks!

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

Commit messages:
 - Backport 3daa03c30f8e6ab9c498edb7d59346ce0b30450f

Changes: https://git.openjdk.org/jdk/pull/26147/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26147&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358680
  Stats: 65 lines in 8 files changed: 47 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26147/head:pull/26147

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

From zgu at openjdk.org  Mon Jul  7 00:42:41 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:42:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
Message-ID: <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>

On Sun, 6 Jul 2025 20:59:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.
>> 
>> I wonder if you can improve this situtation.
>
> Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot.
> 
> Is my understanding correct?
> 
> (Seems that baseline resets the condition and can encounter the same problem as well.)
> 
> 
>         if (limit_exceeded && softrefs_clear) {
>           *gc_overhead_limit_was_exceeded = true;
>           size_policy()->set_gc_overhead_limit_exceeded(false);

Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered  this problem in real production system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761699

From zgu at openjdk.org  Mon Jul  7 00:42:41 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:42:41 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
 <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
Message-ID: <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@github.com>

On Sun, 6 Jul 2025 21:00:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381:
>> 
>>> 379:   HeapWord* result = young_gen()->expand_and_allocate(size);
>>> 380: 
>>> 381:   if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>> 
>> I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen.
>> 
>> What benefits do you get?
>
> I don't see how I changed the semantics.
> 
> On baseline, from `mem_allocate_work`:
> 
> 
> if (result != nullptr) {
>   return result;
> }
> 
> // If certain conditions hold, try allocating from the old gen.
> if (!is_tlab) {
>   result = mem_allocate_old_gen(size);
>   if (result != nullptr) {
>     return result;
>   }
> }
> 
> 
> and
> 
> 
> HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>   if (!should_alloc_in_eden(size)) {
>     // Size is too big for eden.
>     return allocate_old_gen_and_record(size);
>   }
> 
>   return nullptr;
> }
> 
> 
> The original logic is essentially:
> 
> 
> if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>   // allocate in old-gen
> }
> 
> which is the same as I put here.

Ah, okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761974

From zgu at openjdk.org  Mon Jul  7 00:47:43 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 00:47:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>
 <eZpadHAAUfGWXv-sVCeisWIwNA4_WhAMg9lcepI_Q5Q=.40e62fce-378d-4eef-929f-d2338cfe1286@github.com>
 <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com>
Message-ID: <--1bClROkHGNgp0ZOioqohKNJU41qoL_k66W285wP70=.298c6a26-9f05-401e-96d6-afa2dacc1356@github.com>

On Sun, 6 Jul 2025 21:07:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898:
>> 
>>> 896:       size_t target_capacity_bytes = total_live_words * HeapWordSize
>>> 897:                                    + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0)
>>> 898:                                    + SpaceAlignment;
>> 
>> Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`?
>
> The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc.

After [JDK-8328744](https://bugs.openjdk.org/browse/JDK-8328744),  it no longer uses old-gen capacity, but max old-gen size to estimate if promotion can succeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188764546

From xgong at openjdk.org  Mon Jul  7 02:07:50 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 7 Jul 2025 02:07:50 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
 <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
Message-ID: <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>

On Wed, 2 Jul 2025 08:24:22 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> Agree with Paul, these are minor regressions. Let us proceed with this patch.
>> 
>> Thanks so much for your review @sviswa7 !
>
> @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h.

Hi @eme64 , may I ask how the testing is going on? Can we move on and integrate this patch now? Thanks a lot!

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3043273111

From duke at openjdk.org  Mon Jul  7 02:57:13 2025
From: duke at openjdk.org (guanqiang han)
Date: Mon, 7 Jul 2025 02:57:13 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42 support
Message-ID: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>

Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
The above code causes the ptest instruction to be invoked.
The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
all of these above cause this issue.
i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

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

Commit messages:
 - 8358592: Assert in Assembler::ptest due to missing SSE42 support

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

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

From missa at openjdk.org  Mon Jul  7 03:10:15 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 03:10:15 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
Message-ID: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>

The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.

The command to run all range specific micro-benchmarks is posted below.

`make test TEST="micro:SinhPerf.SinhPerfRanges"`

The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.

For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.

| Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
| :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
| [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
| [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
| [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
| [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
| (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |

Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

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

Commit messages:
 - x86_64 intrinsic for sinh using libm

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

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

From amitkumar at openjdk.org  Mon Jul  7 04:26:43 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 7 Jul 2025 04:26:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
Message-ID: <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>

On Sun, 6 Jul 2025 16:54:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> @vnkozlov Could you please rereview this?
>> 
>> This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.
>
> @vnkozlov 
>> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.
> 
> Done.

Hi @adinn, 

could you add these changes fixing test failure on s390: 


diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
index 10e5abe9ce8..687fb764bd8 100644
--- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
+++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
@@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
 
       // Save non-volatile registers to ABI of caller frame.
       BLOCK_COMMENT("save registers, push frame {");
-      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
-      __ z_std(Z_F8, 96, Z_SP);
-      __ z_std(Z_F9, 104, Z_SP);
-      __ z_std(Z_F10, 112, Z_SP);
-      __ z_std(Z_F11, 120, Z_SP);
-      __ z_std(Z_F12, 128, Z_SP);
-      __ z_std(Z_F13, 136, Z_SP);
-      __ z_std(Z_F14, 144, Z_SP);
-      __ z_std(Z_F15, 152, Z_SP);
+      __ save_return_pc();
+      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
+      __ z_std(Z_F8, 88, Z_SP);
+      __ z_std(Z_F9, 96, Z_SP);
+      __ z_std(Z_F10, 104, Z_SP);
+      __ z_std(Z_F11, 112, Z_SP);
+      __ z_std(Z_F12, 120, Z_SP);
+      __ z_std(Z_F13, 128, Z_SP);
+      __ z_std(Z_F14, 136, Z_SP);
+      __ z_std(Z_F15, 144, Z_SP);
 
       //
       // Push ENTRY_FRAME including arguments:
@@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
       __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
 
       // Restore non-volatiles.
-      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
-      __ z_ld(Z_F8, 96, Z_SP);
-      __ z_ld(Z_F9, 104, Z_SP);
-      __ z_ld(Z_F10, 112, Z_SP);
-      __ z_ld(Z_F11, 120, Z_SP);
-      __ z_ld(Z_F12, 128, Z_SP);
-      __ z_ld(Z_F13, 136, Z_SP);
-      __ z_ld(Z_F14, 144, Z_SP);
-      __ z_ld(Z_F15, 152, Z_SP);
+      __ restore_return_pc();
+      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
+      __ z_ld(Z_F8, 88, Z_SP);
+      __ z_ld(Z_F9, 96, Z_SP);
+      __ z_ld(Z_F10, 104, Z_SP);
+      __ z_ld(Z_F11, 112, Z_SP);
+      __ z_ld(Z_F12, 120, Z_SP);
+      __ z_ld(Z_F13, 128, Z_SP);
+      __ z_ld(Z_F14, 136, Z_SP);
+      __ z_ld(Z_F15, 144, Z_SP);
       BLOCK_COMMENT("} restore");
 
       //

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3043435063

From fweimer at openjdk.org  Mon Jul  7 04:50:37 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Mon, 7 Jul 2025 04:50:37 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3043465393

From epeter at openjdk.org  Mon Jul  7 06:04:45 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 7 Jul 2025 06:04:45 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <NU_HOObJ9KM0ZPI7xd1DcwxCDKe4-dC9cIjb05W5Pv4=.5dd9c192-cee8-4ad6-b8d2-0f33350b434a@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
>> 
>> Two key areas require improvement:
>> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
>> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
>> 
>> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
>> 
>> Main changes:
>> 1. Java-side API refactoring:
>>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>>      architectures like AArch64.
>> 2. C2 compiler IR refactoring:
>>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
>> 3. Backend changes:
>>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
>> 
>> Performance:
>> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
>> 
>> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
>> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.31...
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Address review comments
>  - Merge 'jdk:master' into JDK-8355563
>  - 8355563: VectorAPI: Refactor current implementation of subword gather load API

@XiaohongGong Thanks for putting in the work!

Tests pass, and patch looks reasonable.

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2992282121

From asemenov at openjdk.org  Mon Jul  7 06:14:45 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 7 Jul 2025 06:14:45 GMT
Subject: Integrated: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object()
In-Reply-To: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
Message-ID: <bfjfpy_6G1e7rl_-13ng9zeVfMhizfJChBS3Z6RbYcI=.86fed11d-f9df-460b-ab17-d19b4e7103bc@github.com>

On Thu, 26 Jun 2025 13:24:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.

This pull request has now been integrated.

Changeset: e9a43416
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9a434165a6ec07cde0429c7f9823bbc5dab7857
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Artem Semenov <savoptik at altlinux.org>.

Reviewed-by: sspitsyn, amenkov, cjplummer

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

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

From lliu at openjdk.org  Mon Jul  7 06:21:24 2025
From: lliu at openjdk.org (Liming Liu)
Date: Mon, 7 Jul 2025 06:21:24 GMT
Subject: RFR: 8358032: Use crypto pmull for CRC32(C) on Ampere CPU and
 improve for short inputs [v5]
In-Reply-To: <wOv8ZdTAm9-Krf90U16D5us21UbITIyg4Y6ujvABnFY=.e34a5cc9-d6ea-4de1-a539-e7f31559f291@github.com>
References: <wOv8ZdTAm9-Krf90U16D5us21UbITIyg4Y6ujvABnFY=.e34a5cc9-d6ea-4de1-a539-e7f31559f291@github.com>
Message-ID: <VH-vgYI_OKfcQTVVrnakT_Zis6dGSHtWZg1Z_nRGwa8=.8761a86e-9bed-43f7-a8b3-20c169bc0f62@github.com>

> This PR is to enable the use of crypto pmull for CRC32/CRC32C intrinsics on Ampere CPU. There is an option UseCryptoPmullForCRC32 that can enable crypto pmull, but directly enabling it on Ampere CPU will cause the following problems.
> 
> 1. There will be regressions (-14% ~ -8%) on Ampere1 when the length is 64. When <= 128, both kernel_crc32_using_crc32 and kernel_crc32_using_crypto_pmull use the loop labeled as CRC_by32_loop, but their implements are a little different, and the loop in kernel_crc32_using_crc32 is better at hiding latency on Ampere1. So this PR takes the loop in kernel_crc32_using_crc32 to kernel_crc32_using_crypto_pmull, and does the same for CRC32C intrinsic.
> 
> 2. The intrinsics only use crypto pmull when the length is higher than 383, while the loop in kernel_crc32_common_fold_using_crypto_pmull looks able to handle 256, and if it handles 256 on Ampere1, the improvements can be as high as 110% compared with kernel_crc32_using_crc32/kernel_crc32c_using_crc32c. However, there are regressions (~-6%) on Neoverse V1 when the length is 256. So this PR introduces a new option named CryptoPmullForCRC32LowLimit. It defaults to 256 since the code could handle 256, while it is set to 384 for V1/V2 to keep the old behavior on these platforms.
> 
> The performance regressions and improvements were measured with the following microbenchmarks:
> org.openjdk.bench.java.util.TestCRC32.testCRC32Update
> org.openjdk.bench.java.util.TestCRC32C.testCRC32CUpdate
> 
> Ran the following JTReg tests on Ampere1 and did not find problems:
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java

Liming Liu has updated the pull request incrementally with one additional commit since the last revision:

  Briefly explain the requirement of the option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25609/files
  - new: https://git.openjdk.org/jdk/pull/25609/files/df9f920a..1641d700

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

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

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

From xgong at openjdk.org  Mon Jul  7 06:55:46 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 7 Jul 2025 06:55:46 GMT
Subject: RFR: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API [v2]
In-Reply-To: <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
 <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
 <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>
Message-ID: <bKwajvXZFu-D6bLQG39IgAgYq3QggUV-aPVRVs5h5X0=.0928f80e-2552-48cb-a659-7ffe8714f2e4@github.com>

On Mon, 7 Jul 2025 02:05:06 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h.
>
> Hi @eme64 , may I ask how the testing is going on? Can we move on and integrate this patch now? Thanks a lot!

> @XiaohongGong Thanks for putting in the work!
> 
> Tests pass, and patch looks reasonable.

Thanks so much for your review and test!

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

PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3043679621

From xgong at openjdk.org  Mon Jul  7 06:55:47 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 7 Jul 2025 06:55:47 GMT
Subject: Integrated: 8355563: VectorAPI: Refactor current implementation of
 subword gather load API
In-Reply-To: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <XjmOn7QfH9R0A9aKHatn9SN4XDHrEi_o3uN1j0JtPRw=.81ccd8fb-55d0-49e3-abb8-cc9092745ad9@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]).
> 
> Two key areas require improvement:
> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance.
> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types  increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance.
> 
> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures.
> 
> Main changes:
> 1. Java-side API refactoring:
>    - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on
>      architectures like AArch64.
> 2. C2 compiler IR refactoring:
>    - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types.
> 3. Backend changes:
>    - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level.
> 
> Performance:
> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below:
> 
> Benchmark                                                 Mode   Cnt Unit    SIZE    Before      After    Gain
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  64    53682.012   52650.325  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  256   14484.252   14255.156  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  1024   3664.900    3595.615  0.98
> GatherOperationsBenchmark.microByteGather128              thrpt  30  ops/ms  4096    908.312     935.269  1.02
> GatherOperationsBenchmark.micr...

This pull request has now been integrated.

Changeset: d75ea7e6
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d75ea7e67951275fe27f1e137c961f39d779a046
Stats:     450 lines in 15 files changed: 109 ins; 176 del; 165 mod

8355563: VectorAPI: Refactor current implementation of subword gather load API

Reviewed-by: epeter, psandoz, sviswanathan, jbhateja

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

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

From ayang at openjdk.org  Mon Jul  7 07:57:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 07:57:32 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=19
  Stats: 4361 lines in 31 files changed: 505 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Mon Jul  7 07:57:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 07:57:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
Message-ID: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>

On Mon, 7 Jul 2025 00:39:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> but OOM and heap dump have to be, in a sense of atomic

I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189268507

From fyang at openjdk.org  Mon Jul  7 07:59:44 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 7 Jul 2025 07:59:44 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
Message-ID: <Xk8pi5GoYYqXVsbYT5Tvt5xz8VxeFEa3g6LL2qjMnyo=.59d5fc9b-83d2-48ea-aa5a-9d1f2362521a@github.com>

On Fri, 4 Jul 2025 13:50:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
>> 
>> Riscv should support these features and resolve relative issues.
>> 
>> ## Test
>> 
>> ### jtreg
>> 
>> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
>> 
>> ### Performance
>> 
>> perf command to run the simplest Hello world java program:
>> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
>> 
>> perf data:
>> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
>> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - pass msg via a0 in stop
>  - comment

Thanks for the update. Several minor comments remain after more closer look.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 800:

> 798:   push_reg(RegSet::of(t1, xmethod), sp);   // push << t1 & xmethod >> to sp
> 799:   movptr(t1, RuntimeAddress(entry_point), t0);
> 800:   jalr(t1);

This movptr + jalr sequence could be further simplified into `rt_call(entry_point)`, which could help save one add instruction.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4930:

> 4928:   push_reg(saved_regs, sp);
> 4929: 
> 4930:   movptr(t1, ExternalAddress(CAST_FROM_FN_PTR(address, Thread::current)));

It will be more consistent with other places in riscv-specific code where we move an ExternalAddress into a register if we do: `la(t1, ExternalAddress(CAST_FROM_FN_PTR(address, Thread::current)))`.

src/hotspot/cpu/riscv/runtime_riscv.cpp line 63:

> 61: UncommonTrapBlob* OptoRuntime::generate_uncommon_trap_blob() {
> 62:   // Allocate space for the code
> 63:   ResourceMark rm;

Seems more reasonable to move this `ResourceMark rm;` closer to its user `CodeBuffer buffer(name, 2048, 1024);`.
Similar for other changes in this file and src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp.

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

PR Review: https://git.openjdk.org/jdk/pull/26101#pullrequestreview-2992544544
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2189220673
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2189240643
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2189274053

From lliu at openjdk.org  Mon Jul  7 08:00:46 2025
From: lliu at openjdk.org (Liming Liu)
Date: Mon, 7 Jul 2025 08:00:46 GMT
Subject: RFR: 8358032: Use crypto pmull for CRC32(C) on Ampere CPU and
 improve for short inputs [v4]
In-Reply-To: <OHnqvp9dAVEuYFxM-D7-5TMho4rJBgWoB5kYVIbACYI=.7f1f55c7-d96f-4b2d-bc2b-3b4a87277c93@github.com>
References: <wOv8ZdTAm9-Krf90U16D5us21UbITIyg4Y6ujvABnFY=.e34a5cc9-d6ea-4de1-a539-e7f31559f291@github.com>
 <32uuLeizjdx7p5TeOzMvoyj0Smmra-DV4qhPZy7z-bE=.78485dd1-cc6f-4fbf-88a3-a4f78c164b0c@github.com>
 <qkp72MttRpSYCQi17EsOpD3EsG3ddHBcPCHg25wLPMA=.bb2c3a6f-8515-4931-9ead-ebc2a797fba6@github.com>
 <OHnqvp9dAVEuYFxM-D7-5TMho4rJBgWoB5kYVIbACYI=.7f1f55c7-d96f-4b2d-bc2b-3b4a87277c93@github.com>
Message-ID: <kQZTrP0pGstkH7dkTEzi5H5nkNvrE1KT-DjS_8GluAc=.7f7b9231-255c-4912-b302-90454976a3f3@github.com>

On Mon, 23 Jun 2025 05:54:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 92:
>> 
>>> 90:   product(bool, UseCryptoPmullForCRC32, false,                          \
>>> 91:           "Use Crypto PMULL instructions for CRC32 computation")        \
>>> 92:   product(uint, CryptoPmullForCRC32LowLimit, 256, DIAGNOSTIC,           \
>> 
>> Can you please add a test that uses this flag, and sets it to some selected values, and maybe even a random value?
>
> Is there already an IR test that checks for the presence of the crypto pmull? That could be good to ensure it occurs as expected and only when expected :)

Hi @eme64, what's your opinion? Personally, I think the two tests are enough for internal testing. This patch does not introduce the presence of crypto pmull. It just improves the existed instrinsics on Ampere CPU and enables it by default for Ampere, so the two tests already cover this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25609#discussion_r2189280162

From ayang at openjdk.org  Mon Jul  7 08:02:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 08:02:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
 <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
Message-ID: <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMFrNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>

On Mon, 7 Jul 2025 07:53:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered  this problem in real production system.
>
>> but OOM and heap dump have to be, in a sense of atomic
> 
> I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.

Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189284517

From adinn at openjdk.org  Mon Jul  7 08:06:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Jul 2025 08:06:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
 <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
Message-ID: <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>

On Mon, 7 Jul 2025 04:24:20 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @vnkozlov 
>>> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.
>> 
>> Done.
>
> Hi @adinn, 
> 
> could you add these changes fixing test failure on s390: 
> 
> 
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index 10e5abe9ce8..687fb764bd8 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
>  
>        // Save non-volatile registers to ABI of caller frame.
>        BLOCK_COMMENT("save registers, push frame {");
> -      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
> -      __ z_std(Z_F8, 96, Z_SP);
> -      __ z_std(Z_F9, 104, Z_SP);
> -      __ z_std(Z_F10, 112, Z_SP);
> -      __ z_std(Z_F11, 120, Z_SP);
> -      __ z_std(Z_F12, 128, Z_SP);
> -      __ z_std(Z_F13, 136, Z_SP);
> -      __ z_std(Z_F14, 144, Z_SP);
> -      __ z_std(Z_F15, 152, Z_SP);
> +      __ save_return_pc();
> +      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
> +      __ z_std(Z_F8, 88, Z_SP);
> +      __ z_std(Z_F9, 96, Z_SP);
> +      __ z_std(Z_F10, 104, Z_SP);
> +      __ z_std(Z_F11, 112, Z_SP);
> +      __ z_std(Z_F12, 120, Z_SP);
> +      __ z_std(Z_F13, 128, Z_SP);
> +      __ z_std(Z_F14, 136, Z_SP);
> +      __ z_std(Z_F15, 144, Z_SP);
>  
>        //
>        // Push ENTRY_FRAME including arguments:
> @@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
>        __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
>  
>        // Restore non-volatiles.
> -      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
> -      __ z_ld(Z_F8, 96, Z_SP);
> -      __ z_ld(Z_F9, 104, Z_SP);
> -      __ z_ld(Z_F10, 112, Z_SP);
> -      __ z_ld(Z_F11, 120, Z_SP);
> -      __ z_ld(Z_F12, 128, Z_SP);
> -      __ z_ld(Z_F13, 136, Z_SP);
> -      __ z_ld(Z_F14, 144, Z_SP);
> -      __ z_ld(Z_F15, 152, Z_SP);
> +      __ restore_return_pc();
> +      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
> +      __ z_ld(Z_F8, 88, Z_SP);
> +      __ z_ld(Z_F9, 96, Z_SP);
> +      __ z_ld(Z_F10, 104, Z_SP);
> +      __ z_ld(Z_F11, 112, Z_SP);
> +      __ z_ld(Z_F12, 120, Z_SP);
> +      __ z_ld(Z_F13, 128, Z_SP);
> +      __ z_ld(Z_F14, 136, Z_SP);
> +      __ z_ld(Z_F15, 144, Z_SP);
>        BLOCK_COMMENT("} restore");
>  
>        //

@offamitkumar
> could you add these changes fixing test failure on s390:

I think these need to be included in a separate PR. Your patch fixes a problem that is independent from the current change (it was already there but only manifested after this change).

Separating these issues is important because we may decide to backport your patch (say, to jdk25) and the changes in this PR definitely should not be backported. It also matters because it avoids confusing maintainers over the purpose and scope of these two sets of changes -- this one is meant to be a removal of technical debt with no visible changes to functionality, whereas your patch is remedying a functional defect.

So, please raise a new JIRA indicating what problem the above patch fixes and then create a new PR for the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3043894384

From shade at openjdk.org  Mon Jul  7 08:11:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 08:11:44 GMT
Subject: [jdk25] RFR: 8358680: AOT cache creation fails: no strings should
 have been added
In-Reply-To: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
References: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
Message-ID: <53a5UFFV7am-TCoBH3eyLsZMxTLp-8uRBowWViEvEmo=.3648d1cc-6412-4ab8-ad7d-2318afd42742@github.com>

On Sun, 6 Jul 2025 23:02:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [3daa03c3](https://github.com/openjdk/jdk/commit/3daa03c30f8e6ab9c498edb7d59346ce0b30450f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 3 Jul 2025 and was reviewed by Coleen Phillimore and Aleksey Shipilev.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26147#pullrequestreview-2992678318

From duke at openjdk.org  Mon Jul  7 09:16:44 2025
From: duke at openjdk.org (Manjunath S Matti.)
Date: Mon, 7 Jul 2025 09:16:44 GMT
Subject: RFR: 8359114: [s390x] Add z17 detection code [v2]
In-Reply-To: <_fiM-Nhm3q5S2hCxa3quxpodBRmeIsCIBcA7AB4Hmcc=.2005b23d-fc05-4821-90b4-cf22a8d2442e@github.com>
References: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
 <_fiM-Nhm3q5S2hCxa3quxpodBRmeIsCIBcA7AB4Hmcc=.2005b23d-fc05-4821-90b4-cf22a8d2442e@github.com>
Message-ID: <MUTrxue9uAI1bGHOi5AaOsiWOYNdcbJcKmVMujTjoSI=.77fc2ee2-de8e-405f-9f70-760334987f30@github.com>

On Wed, 11 Jun 2025 13:09:45 GMT, Manjunath S Matti. <duke at openjdk.org> wrote:

>> Add support to detect the new generation of Z machine (z17).
>
> Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct the comments for the bits covered in DW[2] and DW[3].

@RealLucy or @theRealAph please provide the 2nd review

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

PR Comment: https://git.openjdk.org/jdk/pull/25718#issuecomment-3044117259

From gli at openjdk.org  Mon Jul  7 10:02:05 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 7 Jul 2025 10:02:05 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
Message-ID: <rUfbOFKXnmhEtvfydubkdKWLMTYMa5n-PP7HgBRTlaY=.48ed6ee5-6b44-4485-a0e0-7a993002eaa0@github.com>

On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

Marked as reviewed by gli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993059953

From adinn at openjdk.org  Mon Jul  7 11:15:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Jul 2025 11:15:40 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <olC9uMW3nk2GRuUQECACixstf6Ot5YhdlCOREg1_s1A=.2190fb5d-278a-4ec1-ac7c-deb9cc639750@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <x0q4eWzTDgHoINsvMs3MB0HmFAHljmHmmBn08Va0WtI=.f889c3c4-7111-473b-9f3b-f06f793fbd88@github.com>
 <olC9uMW3nk2GRuUQECACixstf6Ot5YhdlCOREg1_s1A=.2190fb5d-278a-4ec1-ac7c-deb9cc639750@github.com>
Message-ID: <Owx7wgunFqDeypT9gQIS5j_FJgazG_b7FH8PbXSQ4p8=.f4f8d46f-26ba-4c17-b3d8-a3242bec1531@github.com>

On Fri, 4 Jul 2025 13:45:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 766:
>> 
>>> 764:   BLOCK_COMMENT(str);
>>> 765:   illegal_instruction(Assembler::csr::time);
>>> 766:   emit_int64((uintptr_t)str);
>> 
>> I noticed that our aarch64 counterpart puts the address of msg into `r0` in https://github.com/openjdk/jdk/pull/24740.
>> 
>>   // load msg into r0 so we can access it from the signal handler
>>   // ExternalAddress enables saving and restoring via the code cache
>>   lea(c_rarg0, ExternalAddress((address) str));
>> 
>> 
>> And fetches the address from `r0` in `PosixSignals::pd_hotspot_signal_handler`:
>> 
>>         // A pointer to the message will have been placed in `r0`
>>         const char *detail_msg = (const char *)(uc->uc_mcontext.regs[0]);
>> 
>> 
>> I am not sure but I guess this is needed for the correct working of aot? Maybe we should do similar things.
>
> My test shows that it's fine to keep the current way to pass the stop message to sig handler, in both dump and use time. Seems currently both ways work.
> But to keep the consistency with other platforms, I'll change it too.

You do need to make this change consistent with how it was done for AArch64. The old compiler code embedded the address of the string into the instruction stream immediately after illegal instruction without a relocation. The signal handler used the faulting PC as a way to identify the location of the pointer. That won't work if the code gets saved and loaded as the string may not be at the same address. The new code marks the lea instruction as relocatable and adds the string address to the AOT external constants table. This allows the target of the lea to be relocated when the code is reloaded from the AOT cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2189746675

From adinn at openjdk.org  Mon Jul  7 12:32:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Jul 2025 12:32:42 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
Message-ID: <2wMV3f3LhAT16le7lOvo1G4HMuGBHMVMg56257cf3qw=.10dfc519-b499-4cb6-8a6c-ecfe23e8879c@github.com>

On Fri, 4 Jul 2025 13:50:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
>> 
>> Riscv should support these features and resolve relative issues.
>> 
>> ## Test
>> 
>> ### jtreg
>> 
>> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
>> 
>> ### Performance
>> 
>> perf command to run the simplest Hello world java program:
>> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
>> 
>> perf data:
>> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
>> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - pass msg via a0 in stop
>  - comment

@Hamlin-Li @RealFYang I think it might be better to discuss this with on the leyden-dev mailing list before trying to implement the changes needed to match what has been done for AArch64 and x86_64. One good reason for caution is that the Leyden premain project is planning to add further code save/restore capabilities to mainline that have already been prototyped in the Leyden premain branch. So, if you enable AOT code cache initialization for RISCV then you will need to be able/ready to provide all the other parts of the implementation when they arrive.

It might be safer to implement what is needed in premain (or in a downstream clone) after discussing both what is needed and why it is needed with the Leyden devs. It would also help if you were to use the testing and benchmark programs that the project is using to check that the aot code cache is working correctly and actually boosting performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/26101#issuecomment-3044850283

From tschatzl at openjdk.org  Mon Jul  7 12:36:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 12:36:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>

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

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

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=40
  Stats: 7121 lines in 112 files changed: 2585 ins; 3590 del; 946 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From zgu at openjdk.org  Mon Jul  7 13:32:56 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:56 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20]
In-Reply-To: <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <YQcv7tYG8XHbkH8CEKPztlIE8KsLGvITefASN78AfWg=.9b1feeab-dce5-4e11-881e-9f7236ac62f4@github.com>
Message-ID: <zPyY-uHKb2yN-6a7_mwPEMnpniVJ-T-AqgtIUqvXJQ0=.3312829e-7868-47a8-b641-3ccba94247ab@github.com>

On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993906888

From zgu at openjdk.org  Mon Jul  7 13:32:58 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
 <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
Message-ID: <YS4qYlS4Wg7wr8_vq0SNb4S--mFBFPDh3OI7T8nnaqo=.f4037a89-ec38-451b-9f8e-766fee8fc270@github.com>

On Sun, 6 Jul 2025 20:47:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelArguments.cpp line 71:
>> 
>>> 69:   // True in product build, since tests using debug build often stress GC
>>> 70:   if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) {
>>> 71:     FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct);
>> 
>> Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp`
>
> It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...".

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190120397

From zgu at openjdk.org  Mon Jul  7 13:32:59 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Jul 2025 13:32:59 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMFrNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <ttWnZz90Lh8oyhyaYoNNwVC1zWqtPMicSgaxFKR_FG8=.f42361b5-5d99-40cf-bac9-341bf538b932@github.com>
 <zuNmkUKMUu4Jbx0O-HSVivX0Rp4bnVoBfVce0_-FH-Y=.9ab22c45-5a93-4003-90c9-4eb5c6fbba29@github.com>
 <mB13PVnk5dinRomz7AAsWDhj-zvrHM70VCPXDKkhunc=.ae96bc4e-1500-47a1-bf6d-03586ca239c5@github.com>
 <wiSiJ7ZbyzXrY2FF78Z-HxFF8M6saGGDtGHr3IvK5aQ=.a8e7d737-62f6-46f8-951a-7f82a47c96e9@github.com>
 <L2r8AX_VNvne-6hsTBQCUfn4c2seAEeXpXTPO8YtNfY=.b244845b-6fc8-4ae9-8b6a-48f17cd7a8a0@github.com>
 <EkIupmVHLm2mobNyNBSVYfW_Gw5PVaXXukJWH-LnPKc=.5f633907-eb1d-4e18-bfb8-f248990528a1@github.com>
 <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com>
 <tSmjzdgYHVLvtLde3VTSTYmUPf9fUZfbJMF
 rNKfaBW0=.a6b46172-e442-48c1-a3e9-39751ad600f5@github.com>
Message-ID: <kor33oeaR3oZDaBU7gU14WHcN_lGL3hbXsZBk1pY4JA=.f68f0632-95f0-4bba-a36c-f24ab3be9476@github.com>

On Mon, 7 Jul 2025 07:59:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> but OOM and heap dump have to be, in a sense of atomic
>> 
>> I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR.
>
> Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind?

Yes. Sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190117730

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From sspitsyn at openjdk.org  Mon Jul  7 17:55:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 17:55:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <T2jD2fR71aA1qcF_uHlMNAHPbc4kMxjV8TMLblykv5Y=.779947bb-3db5-44d5-ae18-ae0e0b9b8746@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>
 <FZwQjYWg-ZsVK1Yr2YQikAZy7fVyqExxB8gZq87xUE0=.dbb94e97-5ddd-4db6-9c32-c5dbc13d4d98@github.com>
 <T2jD2fR71aA1qcF_uHlMNAHPbc4kMxjV8TMLblykv5Y=.779947bb-3db5-44d5-ae18-ae0e0b9b8746@github.com>
Message-ID: <B5lvTnC8BtX91M2nvLpeS1xrF7rrNCL5o69mUMz6WpA=.012720ac-e63e-4abc-8cdb-56af2b83e579@github.com>

On Fri, 4 Jul 2025 06:15:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Good suggestion, thanks.
>> `NotifyFramePop` does not generate the `FramePop` events by itself it is just sets or enables events.
>> Then should we say this way: "unable to set a `FramePop` event for the frame" ?
>
>> Then should we say this way: "unable to set a `FramePop` event for the frame" ?
> 
> The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events.

Right, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190726907

From sspitsyn at openjdk.org  Mon Jul  7 18:02:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 18:02:34 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v2]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <mjb32I5oECcDTyqXcJjfOcHqbposTdFuBnLbQsS23-w=.3ec30557-2dfc-42b5-bf3d-4ba392065d4f@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI functions:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
> 
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweak OPAQUE_FRAME clarification for NotifyFramePop function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/1d017ea8..c2cbd0d3

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

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

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

From darcy at openjdk.org  Mon Jul  7 18:03:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Jul 2025 18:03:40 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046086649

From darcy at openjdk.org  Mon Jul  7 18:06:39 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Jul 2025 18:06:39 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation.

What is the expected distribution of arguments to sinh?

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046093111

From sspitsyn at openjdk.org  Mon Jul  7 18:13:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 18:13:19 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI functions:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
> 
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/c2cbd0d3..0c6ef896

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

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

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

From sspitsyn at openjdk.org  Mon Jul  7 18:13:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 18:13:19 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <C8G8kMI--vdkKzq4F6NCw--mmPILtALSXvK7ObKQm1M=.db567f36-e5a5-408f-89b2-7da9099b9f6f@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
 <C8G8kMI--vdkKzq4F6NCw--mmPILtALSXvK7ObKQm1M=.db567f36-e5a5-408f-89b2-7da9099b9f6f@github.com>
Message-ID: <oHRRlw_Eg0XnIBu4CO0LlVFThBYvBt2ibvsBlpy51jE=.7cef038f-b747-49ed-9653-a3e8ca1243df@github.com>

On Thu, 3 Jul 2025 18:45:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 3191:
>> 
>>> 3189:       <errors>
>>> 3190:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>>> 3191:           The implementation is unable to force current frame to return
>> 
>> Suggestion:
>> 
>>           The implementation is unable to force the current frame to return
>
> Note this error repeats a few times below. I only tagged this one.

Thanks! Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190751011

From cjplummer at openjdk.org  Mon Jul  7 18:33:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 18:33:39 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <B5lvTnC8BtX91M2nvLpeS1xrF7rrNCL5o69mUMz6WpA=.012720ac-e63e-4abc-8cdb-56af2b83e579@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <nLDLQ5olCbG3rDW2ei1C4H9gN9irRO0-OJsch7wp9kk=.9e209fe5-e0f9-445a-ac22-17c8c8660cc1@github.com>
 <FZwQjYWg-ZsVK1Yr2YQikAZy7fVyqExxB8gZq87xUE0=.dbb94e97-5ddd-4db6-9c32-c5dbc13d4d98@github.com>
 <T2jD2fR71aA1qcF_uHlMNAHPbc4kMxjV8TMLblykv5Y=.779947bb-3db5-44d5-ae18-ae0e0b9b8746@github.com>
 <B5lvTnC8BtX91M2nvLpeS1xrF7rrNCL5o69mUMz6WpA=.012720ac-e63e-4abc-8cdb-56af2b83e579@github.com>
Message-ID: <shmK2j312iYUGu2gMJpHPUyOCStxM-v93MH2GIyV1xk=.a4fdcf4b-c632-4a0a-ad32-dcceec7b349c@github.com>

On Mon, 7 Jul 2025 17:53:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> Then should we say this way: "unable to set a `FramePop` event for the frame" ?
>> 
>> The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events.
>
> Right, thanks! Fixed now.

I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190788001

From sspitsyn at openjdk.org  Mon Jul  7 18:43:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 18:43:48 GMT
Subject: RFR: 8361325: Refactor ClassLoaderExt [v2]
In-Reply-To: <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>
References: <oW4u_WDmU_ndWcC9kHkCEPYjHOEPMDU20hDUj-1igC4=.906be14d-6d6a-419c-b743-f113fa50824f@github.com>
 <n4DiUuY3B2hdBfRVJ6WZjGg2i4W8KxNPyUB9Jah_Uqw=.1773a489-d84b-4c19-8a6b-ee50331f04a1@github.com>
 <eyd6p8x1v0PAthp74Pe5ncD6uWZJavZsIQhVy6Zdq7I=.0813eb31-0b54-4665-bd4b-04c215aa44d9@github.com>
Message-ID: <YVId0qW_n05Fo8SEaoWsQVhoEq4NjsMp-PKDmQxLtJc=.4541f7ea-fb9e-461b-b187-f4e08d894fe1@github.com>

On Thu, 3 Jul 2025 17:08:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/cds/classListParser.cpp line 33:
>> 
>>> 31: #include "cds/metaspaceShared.hpp"
>>> 32: #include "cds/unregisteredClasses.hpp"
>>> 33: #include "classfile/classLoader.hpp"
>> 
>> Nit: I wonder if the line #33 is really needed and can be removed.
>
> It is needed or else I got compilation error:
> 
> open/src/hotspot/share/cds/classListParser.cpp:561:29: error: 'ClassLoader' has not been declared
>   561 |   const char* source_path = ClassLoader::uri_to_path(_source);
>       |                             ^~~~~~~~~~~
> 
> It worked before because classLoaderExt.hpp includes classLoader.hpp.

Okay, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2190802836

From cjplummer at openjdk.org  Mon Jul  7 18:46:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 18:46:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
Message-ID: <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>

On Mon, 7 Jul 2025 18:13:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI functions:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>> 
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions

src/hotspot/share/prims/jvmti.xml line 3082:

> 3080:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 3081:           The implementation is unable to set a <eventlink id="FramePop"></eventlink> event for the frame
> 3082:           (e.g. the frame at <code>depth</code> is executing a native method).

I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190807109

From amenkov at openjdk.org  Mon Jul  7 19:36:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 7 Jul 2025 19:36:22 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
Message-ID: <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>

> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
> 
> Testing: tier1..5

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26119/files
  - new: https://git.openjdk.org/jdk/pull/26119/files/f4932e4c..04b2a383

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

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

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

From amenkov at openjdk.org  Mon Jul  7 19:40:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 7 Jul 2025 19:40:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
Message-ID: <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>

On Fri, 4 Jul 2025 01:42:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update javaClasses.cpp
>
> src/hotspot/share/classfile/javaClasses.cpp line 1896:
> 
>> 1894:       return nullptr;
>> 1895:     }
>> 1896:     java_thread = java_lang_Thread::thread(carrier_thread);
> 
> Won't `java_thread` already have been set correctly by `cv_internal_thread_to_JavaThread`?

No. This is for virtual thread. We need to get JavaThread from the carrier

> src/hotspot/share/classfile/javaClasses.cpp line 1899:
> 
>> 1897:   }
>> 1898:   if (java_thread == nullptr) {
>> 1899:     // terminated platform thread or unmounted virtual thread
> 
> Wasn't the unmounted virtual thread case already handled by the return at line 1894?

Yes, right.
Removed the comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2190882884
PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2190883998

From kvn at openjdk.org  Mon Jul  7 20:26:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 20:26:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
 <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
 <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>
Message-ID: <KAKLp1nNsaAAg58SdqxkdmmaKOz7foUuoW1vu1yLIGo=.b7fa3adf-a339-4e77-a513-808f05ef5da8@github.com>

On Mon, 7 Jul 2025 08:03:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Hi @adinn, 
>> 
>> could you add these changes fixing test failure on s390: 
>> 
>> 
>> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> index 10e5abe9ce8..687fb764bd8 100644
>> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> @@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
>>  
>>        // Save non-volatile registers to ABI of caller frame.
>>        BLOCK_COMMENT("save registers, push frame {");
>> -      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
>> -      __ z_std(Z_F8, 96, Z_SP);
>> -      __ z_std(Z_F9, 104, Z_SP);
>> -      __ z_std(Z_F10, 112, Z_SP);
>> -      __ z_std(Z_F11, 120, Z_SP);
>> -      __ z_std(Z_F12, 128, Z_SP);
>> -      __ z_std(Z_F13, 136, Z_SP);
>> -      __ z_std(Z_F14, 144, Z_SP);
>> -      __ z_std(Z_F15, 152, Z_SP);
>> +      __ save_return_pc();
>> +      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
>> +      __ z_std(Z_F8, 88, Z_SP);
>> +      __ z_std(Z_F9, 96, Z_SP);
>> +      __ z_std(Z_F10, 104, Z_SP);
>> +      __ z_std(Z_F11, 112, Z_SP);
>> +      __ z_std(Z_F12, 120, Z_SP);
>> +      __ z_std(Z_F13, 128, Z_SP);
>> +      __ z_std(Z_F14, 136, Z_SP);
>> +      __ z_std(Z_F15, 144, Z_SP);
>>  
>>        //
>>        // Push ENTRY_FRAME including arguments:
>> @@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
>>        __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
>>  
>>        // Restore non-volatiles.
>> -      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
>> -      __ z_ld(Z_F8, 96, Z_SP);
>> -      __ z_ld(Z_F9, 104, Z_SP);
>> -      __ z_ld(Z_F10, 112, Z_SP);
>> -      __ z_ld(Z_F11, 120, Z_SP);
>> -      __ z_ld(Z_F12, 128, Z_SP);
>> -      __ z_ld(Z_F13, 136, Z_SP);
>> -      __ z_ld(Z_F14, 144, Z_SP);
>> -      __ z_ld(Z_F15, 152, Z_SP);
>> +      __ restore_return_pc();
>> +      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
>> +      __ z_ld(Z_F8, 88, Z_SP);
>> +      __ z_ld(Z_F9, 96, Z_SP);
>> +      __ z_ld(Z_F10, 104, Z_SP);
>> +      __ z_ld(Z_F11, 112, Z_SP);
>> +      __ z_ld(Z_F12, 120, Z_SP);
>> +      __ z_ld(Z_F13, 128, Z_SP);
>> +      __ z_ld(Z_F14, 136, Z_SP);
>> +      __ z_ld(Z_F15, 144, Z_SP);
>>        BLOCK_COMMENT("} restore");
>>  
>>        //
>
> @offamitkumar
>> could you add these changes fixing test failure on s390:
> 
> I think these need to be included in a separate PR. Your patch fixes a problem that is independent from the current change (it was already there but only manifested after this change).
> 
> Separating these issues is important because we may decide to backport your patch (say, to jdk25) and the changes in this PR definitely should not be backported. It also matters because it avoids confusing maintainers over the purpose and scope of these two sets of changes -- this one is meant to be a removal of technical debt with no visible changes to functionality, whereas your patch is remedying a functional defect.
> 
> So, please raise a new JIRA indicating what problem the above patch fixes and then create a new PR for the patch.

Thank you @adinn  for merge. Unfortunately I was not able to enable Stubs caching for testing.
It failed my local testing. `runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java ` test failed on x86 for multiply reasons. Some are ease to fix and some may be not. I gave up after hitting relocation patching issue.

I submitted testing with AOTStubCaching disabled as in current code.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046421564

From sspitsyn at openjdk.org  Mon Jul  7 21:08:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 21:08:44 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
 <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>
Message-ID: <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com>

On Mon, 7 Jul 2025 18:44:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>
> src/hotspot/share/prims/jvmti.xml line 3082:
> 
>> 3080:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 3081:           The implementation is unable to set a <eventlink id="FramePop"></eventlink> event for the frame
>> 3082:           (e.g. the frame at <code>depth</code> is executing a native method).
> 
> I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame".

Thank you for the comment.
The `NotifyFramePop` is similar to `SetBreakpoint`. I'd even prefer it is named accordingly: `SetFramePop` instead of `NotifyFramePop`.  We enable any kinds of events with `SetEventNotoficationMode` but there cases where we need to be more specific in setting the events. The `SetBreakpoint` is to set a breakpoint at a specific method's bytecode. The `NotifyFramePop` is to set `FramePop` for a specific frame. So, I' prefer to keep the terminology similar for `Breakpoints` and `FramePop` events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2191012054

From sspitsyn at openjdk.org  Mon Jul  7 21:12:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Jul 2025 21:12:42 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
Message-ID: <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com>

On Thu, 3 Jul 2025 18:44:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>
> src/hotspot/share/prims/jvmti.xml line 3194:
> 
>> 3192:           (e.g. current frame is executing a native method).
>> 3193:         </error>
>> 3194:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 
> Do we still need this section? Same question for repeated sections below.

Thank you for suggestion. Let's think on this a little bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2191017166

From kvn at openjdk.org  Mon Jul  7 21:14:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 21:14:53 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
Message-ID: <xPU711hVpnxRooP9rp4cjfRR-WbvqkaXq8l8_A_w5sA=.70a8cfcc-8307-4f4f-a1e7-77a83c449f84@github.com>

On Sun, 6 Jul 2025 16:57:12 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into enumerate_entries
>  - store stub id for opto stub Compile instances as a StubId
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition
>  - fix format for copyright
>  - update copyrights
>  - fix inconsistent stub declarations
>  - fix formatting issues
>  - remove redundant doc comments
>  - fix copy paste errors in riscv
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/266fd59e...dbc8394a

I found the cause of my local testing failure. I built with ubsan and hit [JDK-8360942](https://bugs.openjdk.org/browse/JDK-8360942) which I am working on. After applying the fix the test passed. Here other changes you may consider to include because they fix stack overflow stub generation:


diff --git a/src/hotspot/share/code/aotCodeCache.cpp b/src/hotspot/share/code/aotCodeCache.cpp
index 08cd05a64ed..4c080b90acc 100644
--- a/src/hotspot/share/code/aotCodeCache.cpp
+++ b/src/hotspot/share/code/aotCodeCache.cpp
@@ -1298,6 +1314,7 @@ void AOTCodeAddressTable::init_extrs() {
     SET_ADDRESS(_extrs, SharedRuntime::resolve_opt_virtual_call_C);
     SET_ADDRESS(_extrs, SharedRuntime::resolve_virtual_call_C);
     SET_ADDRESS(_extrs, SharedRuntime::resolve_static_call_C);
+    SET_ADDRESS(_extrs, SharedRuntime::throw_StackOverflowError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_delayed_StackOverflowError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_AbstractMethodError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_IncompatibleClassChangeError);
diff --git a/src/hotspot/share/runtime/init.cpp b/src/hotspot/share/runtime/init.cpp
index b54afd9f735..37c13d90e04 100644
--- a/src/hotspot/share/runtime/init.cpp
+++ b/src/hotspot/share/runtime/init.cpp
@@ -147,9 +150,9 @@ jint init_globals() {
   AsyncLogWriter::initialize();

   initial_stubs_init();      // initial stub routines
+  AOTCodeCache::init_early_stubs_table();  // need this after initial_stubs and before generate_initial_stub
   // stack overflow exception blob is referenced by the interpreter
   SharedRuntime::generate_initial_stubs();
-  AOTCodeCache::init_early_stubs_table();  // need this after initial_stubs
   gc_barrier_stubs_init();   // depends on universe_init, must be before interpreter_init
   continuations_init();      // must precede continuation stub generation
   continuation_stubs_init(); // depends on continuations_init

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046535698

From kbarrett at openjdk.org  Mon Jul  7 22:04:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 7 Jul 2025 22:04:42 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
Message-ID: <ov6uqZnAEu8_sdMRzViK177VtAO5LI5Ow1qQSYxQNak=.f8b5aebf-f979-44af-8243-e837a129ee41@github.com>

On Fri, 4 Jul 2025 15:28:20 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - Albert suggestions
>  - Improve comment
>  - Thomas Review
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - Thomas Review
>  - Reviews
>  - Albert suggestions
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - remove unrequired changes - kim
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f153e415...5c388d54

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2995359702

From kbarrett at openjdk.org  Mon Jul  7 22:04:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 7 Jul 2025 22:04:43 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
 <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
 <9m4YNoOw_rp9t4ohninQDMbzc_-18rZBVQNvxMQCFSM=.c624e95c-39bf-4693-9331-a7a1f5d44484@github.com>
Message-ID: <DL5H3nrb0SiymYDR45Tjj8oH0cofkmGkJBDOQ5sHmQk=.d4ba763e-b99e-42f6-af5a-f31f624d15d8@github.com>

On Wed, 2 Jul 2025 07:00:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894:
>> 
>>> 892: 
>>> 893:   bool should_expand;
>>> 894:   size_t resize_bytes = _heap_sizing_policy->full_collection_resize_amount(should_expand, allocation_word_size);
>> 
>> pre-existing:  I wonder why this isn't a function that returns a `ptrdiff_t` delta on the current size,
>> removing the need for multiple values, one being returned via a by-reference out parameter.
>> Similarly for the young collection case. Or return the size & direction as a pair-like object.
>> (Personally, I find by-reference out parameters confusing to read, but maybe that's just me.)
>
> One potential reason: on 32 bit platforms `ptrdiff_t` is +- 2GB. Heap can be ~4GB on Linux, so `ptrdiff_t` could not represent all potential resize sizes.

Oh, right you are!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2191067844

From kvn at openjdk.org  Mon Jul  7 23:26:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 23:26:51 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
Message-ID: <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>

On Sun, 6 Jul 2025 16:57:12 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into enumerate_entries
>  - store stub id for opto stub Compile instances as a StubId
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition
>  - fix format for copyright
>  - update copyrights
>  - fix inconsistent stub declarations
>  - fix formatting issues
>  - remove redundant doc comments
>  - fix copy paste errors in riscv
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/7a32697c...dbc8394a

So far testing is fine. I see only failures caused by known AOT stubs caching bug: [JDK-8357593](https://bugs.openjdk.org/browse/JDK-8357593)

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046794427

From kvn at openjdk.org  Mon Jul  7 23:34:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 23:34:39 GMT
Subject: [jdk25] RFR: 8358680: AOT cache creation fails: no strings should
 have been added
In-Reply-To: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
References: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
Message-ID: <EXsB0Wuz_USibmrRXZwByQSEplgGJGKBgE7trv-T148=.28da4c95-366c-4e3f-84ec-d64347ea303f@github.com>

On Sun, 6 Jul 2025 23:02:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [3daa03c3](https://github.com/openjdk/jdk/commit/3daa03c30f8e6ab9c498edb7d59346ce0b30450f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 3 Jul 2025 and was reviewed by Coleen Phillimore and Aleksey Shipilev.
> 
> Thanks!

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26147#pullrequestreview-2995542342

From missa at openjdk.org  Mon Jul  7 23:36:39 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:36:39 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
Message-ID: <DhH0T1l6DljbZXq4tstMPUjmUeLSqE7HCDFCHyL-7A0=.d5b0e360-3f53-440b-9226-3d21e0619745@github.com>

On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation.
> 
> What is the expected distribution of arguments to sinh?

I don't know about an expected distribution of distribution of arguments to sinh. From glancing through research papers though, I get the sense that the [-2^(-28), 2^(-28)] range isn't used all that much. A couple of papers showing this are linked below.

1. [An Analysis of the Hyperbolic Bid Stacking Technique's Use in Modeling Power Prices](https://dl.acm.org/doi/10.1145/3640115.3640182)
2. [Experimental Validation of a 3GPP compliant 5G-based Positioning System](https://dl.acm.org/doi/10.1145/3636534.3697324)

I think the [-2^(-28), 2^(-28)] range isn't all that interesting for sinh anyway as it just returns the input itself. So, I doubt any applications are relying all that heavily on it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046818744

From missa at openjdk.org  Mon Jul  7 23:47:38 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:47:38 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
Message-ID: <Drup9Nkvcw7CHLGlJGtJmzSvYFQZd7dIU6qmnzBLXPQ=.940e6988-52d1-43fc-804c-30e87220a0a4@github.com>

On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh.

Yes, the intention is to have cosh as next math intrinsic.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046847281

From missa at openjdk.org  Mon Jul  7 23:55:39 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 7 Jul 2025 23:55:39 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
Message-ID: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>

On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks.

I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify?

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046866329

From dholmes at openjdk.org  Tue Jul  8 01:22:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:22:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
Message-ID: <z3cDwi4RUKo5WpxHnEUAI9Q6toDXBTWhSoW4j-qDyGg=.3fd2f748-926c-452f-9080-2fccc8886417@github.com>

On Mon, 7 Jul 2025 19:36:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comment

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-2995692697

From dholmes at openjdk.org  Tue Jul  8 01:22:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:22:40 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
 <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
Message-ID: <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>

On Mon, 7 Jul 2025 19:36:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1896:
>> 
>>> 1894:       return nullptr;
>>> 1895:     }
>>> 1896:     java_thread = java_lang_Thread::thread(carrier_thread);
>> 
>> Won't `java_thread` already have been set correctly by `cv_internal_thread_to_JavaThread`?
>
> No. This is for virtual thread. We need to get JavaThread from the carrier

Got it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2191284693

From dholmes at openjdk.org  Tue Jul  8 01:22:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:22:41 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
Message-ID: <8wE7u4WeAFyj8ix5GkXxXVnag6PgO6W_eOB5xahLEN8=.b79fc0e2-c406-4073-807c-abb59b34063c@github.com>

On Thu, 3 Jul 2025 20:03:06 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javaClasses.cpp

src/hotspot/share/classfile/javaClasses.cpp line 1899:

> 1897:   }
> 1898:   if (java_thread == nullptr) {
> 1899:     // terminated platform thread or unmounted virtual thread

You can leave the `// terminated platform thread` comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2191285973

From dholmes at openjdk.org  Tue Jul  8 01:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:32:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
 <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
 <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>
Message-ID: <A11anQUaMdwDAJ1-5VNTiPqlSTciQ0RhXerz_FwmYp8=.fc5ffb07-3b3e-497e-9c7f-f3f42daed00b@github.com>

On Tue, 8 Jul 2025 01:19:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No. This is for virtual thread. We need to get JavaThread from the carrier
>
> Got it.

Actually I think we need a further check here. If we get the carrier thread directly, we have not checked that it is actually protected by the TLH - that is normally done by `cv_internal_thread_to_JavaThread` but that doesn't know about virtual threads and carriers!). I need to check if we have to fix `cv_internal_thread_to_JavaThread` for the virtual thread case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2191295962

From dholmes at openjdk.org  Tue Jul  8 01:55:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 01:55:38 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
Message-ID: <tImCdxDdNg5PBFAAXPolE9DuepAmiMMuZt6paqMcS7o=.39c8647b-c049-4971-91c8-9bf8a9b5fb50@github.com>

On Mon, 7 Jul 2025 19:36:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comment

Revoking my approval as there may be further issues.

I'm also unclear if this code in the handshake is sufficient for dealing with the case where we have a mounted virtual thread initially, but it is unmounted before the handshake gets to execute:

    if (java_lang_VirtualThread::is_instance(_java_thread())) {
        // if (thread->vthread() != _java_thread()) // We might be inside a System.executeOnCarrierThread
        const ContinuationEntry* ce = thread->vthread_continuation();
        if (ce == nullptr || ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())) {
          return; // not mounted
        }
      }

The commented line seems an inaccurate characterization as we could be executing a completely different virtual thread on this carrier now - which is not related to `executeOnCarrierThread`.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26119#pullrequestreview-2995739261
PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3047089860

From dholmes at openjdk.org  Tue Jul  8 02:23:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 02:23:01 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI Release<type>ArrayElements
 needs to filter out known wrapped arrays
Message-ID: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>

The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).

Testing: tiers 1-4

Thanks

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

Commit messages:
 - 8361447: [REDO] Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays

Changes: https://git.openjdk.org/jdk/pull/26177/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361447
  Stats: 351 lines in 6 files changed: 325 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26177/head:pull/26177

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

From dholmes at openjdk.org  Tue Jul  8 02:23:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 02:23:01 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <-LMVVz6nmkGgqub_J0rVAWYp21JjGs4A2m3MrkBPRh8=.38a13c98-767d-4655-930a-49a06f6ef251@github.com>

On Tue, 8 Jul 2025 02:17:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

@MBaesken please run this through your testing - thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3047137340

From stuefe at openjdk.org  Tue Jul  8 05:04:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 05:04:38 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <ujE5oT9GQUOqQ3QJ_RH5e3Rq5h9QPT5QCUZt3pbGarU=.7edd4a67-d128-4b7c-850c-b66f16b42d5b@github.com>

On Tue, 8 Jul 2025 02:17:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

This looks good to me. Thank you for considering my suggestions.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26177#pullrequestreview-2995981340

From dholmes at openjdk.org  Tue Jul  8 05:08:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 05:08:40 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <ujE5oT9GQUOqQ3QJ_RH5e3Rq5h9QPT5QCUZt3pbGarU=.7edd4a67-d128-4b7c-850c-b66f16b42d5b@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <ujE5oT9GQUOqQ3QJ_RH5e3Rq5h9QPT5QCUZt3pbGarU=.7edd4a67-d128-4b7c-850c-b66f16b42d5b@github.com>
Message-ID: <xQF9PNHUvXjXaed1t7yfm-6cM-Ax7Tlo1nqqFJZjll8=.3a681d5a-29d7-4f64-82b8-bd81d94fa18d@github.com>

On Tue, 8 Jul 2025 05:01:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
>> 
>> Testing: tiers 1-4
>> 
>> Thanks
>
> This looks good to me. Thank you for considering my suggestions.

Thanks for the review @tstuefe !

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3047372852

From dholmes at openjdk.org  Tue Jul  8 07:10:24 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 07:10:24 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - new regression test
>  - tiers 1-4
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
  test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
  cause the test to pass by mistake.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26122/files
  - new: https://git.openjdk.org/jdk/pull/26122/files/5e49c497..29883542

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

  Stats: 185 lines in 6 files changed: 8 ins; 154 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26122/head:pull/26122

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

From adinn at openjdk.org  Tue Jul  8 10:59:30 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Jul 2025 10:59:30 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
 - add missing C++ method to AOT cache address table

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/dbc8394a..a14c9821

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

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

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

From adinn at openjdk.org  Tue Jul  8 10:59:34 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Jul 2025 10:59:34 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
 <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>
Message-ID: <P4dbKQM4Cl8v8uOkrDUbhvR5lIXNrwSl5pIdzbJ6xTY=.c4e95704-c57c-439c-b7b6-597a1fe378e5@github.com>

On Mon, 7 Jul 2025 23:24:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn 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 18 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into enumerate_entries
>>  - store stub id for opto stub Compile instances as a StubId
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>>  - fix format for copyright
>>  - update copyrights
>>  - fix inconsistent stub declarations
>>  - fix formatting issues
>>  - remove redundant doc comments
>>  - fix copy paste errors in riscv
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/e06700a6...dbc8394a
>
> So far testing is fine. I see only failures caused by known AOT stubs caching bug: [JDK-8357593](https://bugs.openjdk.org/browse/JDK-8357593)

@vnkozlov I've pushed the two changes you provided (on the assumption that we are not going to need to backport them to jdk25).
Is there any need for more testing, assuming the latest push passes GHA?
Is there anything I can do to help with JDK-8357593?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3048407148

From sgehwolf at openjdk.org  Tue Jul  8 11:05:40 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 8 Jul 2025 11:05:40 GMT
Subject: RFR: 8360651: Create OSContainer API for memory limit
In-Reply-To: <ZT7duPbrERu_WjvkopjoHBipQF0JpTHnx_pGI6CutoM=.485552b9-efe0-408c-a4aa-863d58811a51@github.com>
References: <ZT7duPbrERu_WjvkopjoHBipQF0JpTHnx_pGI6CutoM=.485552b9-efe0-408c-a4aa-863d58811a51@github.com>
Message-ID: <dIWSPPLk-yTvcfz9aJ0PA_veOKnRukBF2Y9Zb9x1oHc=.8f659d5c-8a13-463a-b226-18d19461cc42@github.com>

On Fri, 27 Jun 2025 14:47:34 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch.
> 
> Testing:
> - [x] GHA
> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests).
> 
> Thoughts?

Anyone willing to review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3048431702

From mli at openjdk.org  Tue Jul  8 11:19:43 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Jul 2025 11:19:43 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <2wMV3f3LhAT16le7lOvo1G4HMuGBHMVMg56257cf3qw=.10dfc519-b499-4cb6-8a6c-ecfe23e8879c@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
 <2wMV3f3LhAT16le7lOvo1G4HMuGBHMVMg56257cf3qw=.10dfc519-b499-4cb6-8a6c-ecfe23e8879c@github.com>
Message-ID: <Eor02L9UvjDyfZyhLPjLhXjBZy3oXLWGBAWR5xtNAUk=.4322a3d1-46f8-4146-bd42-aa4ac7fdacf9@github.com>

On Mon, 7 Jul 2025 12:29:44 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - pass msg via a0 in stop
>>  - comment
>
> @Hamlin-Li @RealFYang I think it might be better to discuss this with on the leyden-dev mailing list before trying to implement the changes needed to match what has been done for AArch64 and x86_64. One good reason for caution is that the Leyden premain project is planning to add further code save/restore capabilities to mainline that have already been prototyped in the Leyden premain branch. So, if you enable AOT code cache initialization for RISCV then you will need to be able/ready to provide all the other parts of the implementation when they arrive.
> 
> It might be safer to implement what is needed in premain (or in a downstream clone) after discussing both what is needed and why it is needed with the Leyden devs. It would also help if you were to use the testing and benchmark programs that the project is using to check that the aot code cache is working correctly and actually boosting performance.

@adinn Thank you for the suggestion, I'll check the premain in leyden.

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

PR Comment: https://git.openjdk.org/jdk/pull/26101#issuecomment-3048484926

From coleenp at openjdk.org  Tue Jul  8 11:57:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 11:57:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
Message-ID: <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>

On Tue, 8 Jul 2025 07:10:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>   cause the test to pass by mistake.

test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:

> 84:      * TEST: C c = new C(); c.m() ==> ICCE
> 85:      * TEST: I c = new C(); c.m() ==> ICCE
> 86:      * TEST: J c = new C(); c.m() ==> ICCE

So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.

And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192297473

From dholmes at openjdk.org  Tue Jul  8 12:19:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 12:19:41 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <a9zjRTMFu1eSi02KzbJrCbFxq3DG3u76fesPNxB9t1s=.0c155f80-7c52-4eec-99f5-970543ec72cd@github.com>
Message-ID: <-c65aEhmouyig7RWwCWBJxkhPXNnzL0-Wf-BTppYdVI=.e77dad5f-def7-43c1-87f1-44e969a1b1bf@github.com>

On Tue, 8 Jul 2025 11:55:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:
> 
>> 84:      * TEST: C c = new C(); c.m() ==> ICCE
>> 85:      * TEST: I c = new C(); c.m() ==> ICCE
>> 86:      * TEST: J c = new C(); c.m() ==> ICCE
> 
> So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.
> 
> And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?

I'm not aware of any checked in generated tests. I added the new tests here and they run.

Why should the test for loader-constraints fail? I fixed that issue just in a different way to the original fix. Hence the test passes as it should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192351727

From coleenp at openjdk.org  Tue Jul  8 12:24:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 12:24:39 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
Message-ID: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>

On Tue, 8 Jul 2025 07:10:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>   cause the test to pass by mistake.

Still so many questions...

src/hotspot/share/oops/klassVtable.cpp line 1185:

> 1183:       // Do not check loader constraints for overpass methods because overpass
> 1184:       // methods are created by the jvm to throw exceptions.
> 1185:       if (!target->is_overpass()) {

Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.

What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.

src/hotspot/share/oops/klassVtable.cpp line 1342:

> 1340:     if (target == nullptr || !target->is_public() || target->is_abstract()) {
> 1341:       // Entry does not resolve. Leave it empty for AbstractMethodError or other error.
> 1342:       if (!(target == nullptr) && !target->is_public()) {

Since you're here, can you fix this line to be target != nullptr ?  This part makes sense.  The reason to have overpass methods is to participate in resolution and selection.

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

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-2997364151
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192364443
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2192339867

From dbriemann at openjdk.org  Tue Jul  8 13:27:20 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 8 Jul 2025 13:27:20 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires
Message-ID: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>

Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

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

Commit messages:
 - 8361599: [PPC64] enable missing tests via jtreg requires

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

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

From dbriemann at openjdk.org  Tue Jul  8 14:17:21 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 8 Jul 2025 14:17:21 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
Message-ID: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>

> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  adapt copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26184/files
  - new: https://git.openjdk.org/jdk/pull/26184/files/d0a1efa1..f79e2895

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

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

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

From mdoerr at openjdk.org  Tue Jul  8 14:26:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 14:26:41 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <5JXgG6JiUbQ4tvgG_bN_KoZ65M3Y8so4259bmvJufWY=.22c34a1a-dbbe-4bb2-961f-d90097077d5b@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Looks good and trivial.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26184#pullrequestreview-2997902196

From mdoerr at openjdk.org  Tue Jul  8 14:28:42 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 14:28:42 GMT
Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers
 [v3]
In-Reply-To: <4flgwHZndQpyKANuyMhhYxVw9vxNbZoghJSjAqU_t1E=.5f5fb6f7-147c-49d7-9a21-653bf18384db@github.com>
References: <nhVMSoJ6ndIh5AUfK_GOpqfJjmcdVpLXaJJSCwkXcjg=.f80f80fd-cfe3-4899-aa99-90d4b4e5b6bb@github.com>
 <4flgwHZndQpyKANuyMhhYxVw9vxNbZoghJSjAqU_t1E=.5f5fb6f7-147c-49d7-9a21-653bf18384db@github.com>
Message-ID: <lJV9CLGsxubjiLwC-4FBkA1cW6FgHBhRRUWgdiL6YFw=.bbe6f102-3eef-454d-949c-24da3e9baedc@github.com>

On Wed, 2 Jul 2025 22:32:01 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - 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

We'll probably get back to this after [JDK-8360540](https://bugs.openjdk.org/browse/JDK-8360540) is resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3049185284

From mdoerr at openjdk.org  Tue Jul  8 15:41:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 15:41:39 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <JFV7PILyFnzpg-I70nsacnOq_Feg7AGNt8zlzR-QHps=.fe9d0d64-38a8-4878-89de-6156f7b79da5@github.com>

On Tue, 8 Jul 2025 02:17:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

I think this looks good. Let's see what the tests and UBSan say (Matthias is testing).

src/hotspot/share/memory/guardedMemory.hpp line 157:

> 155:     void* get_tag2() const { return _tag2; }
> 156: 
> 157: 

Maybe remove extra empty lines?

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

PR Review: https://git.openjdk.org/jdk/pull/26177#pullrequestreview-2998191810
PR Review Comment: https://git.openjdk.org/jdk/pull/26177#discussion_r2192857313

From yzheng at openjdk.org  Tue Jul  8 16:03:50 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 16:03:50 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile
Message-ID: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>

In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

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

Commit messages:
 - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

Changes: https://git.openjdk.org/jdk/pull/26192/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361569
  Stats: 65 lines in 10 files changed: 35 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26192/head:pull/26192

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

From liach at openjdk.org  Tue Jul  8 17:20:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 17:20:34 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v10]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Reviews
 - Documentation
 - Don't fail for patching tests
 - Remove design document from code
 - Some more from reviews
 - Reviewed the diff on github
 - Stage
 - Missed comment updates
 - Mark AbstractMap due to CHM
 - ... and 13 more: https://git.openjdk.org/jdk/compare/85331943...574273a6

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

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=09
  Stats: 453 lines in 38 files changed: 280 ins; 150 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

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

From iklam at openjdk.org  Tue Jul  8 17:25:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Jul 2025 17:25:41 GMT
Subject: RFR: 8360163: Create annotations to mark dumping method handles
 and runtime setup required classes [v10]
In-Reply-To: <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>
Message-ID: <j3Dh34dJHg7713HCdvhsflN0nvwrylyMaxO-th3NfN0=.cd1465ba-01ca-49e4-8876-b7437db7ade9@github.com>

On Tue, 8 Jul 2025 17:20:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - Some more from reviews
>  - Reviewed the diff on github
>  - Stage
>  - Missed comment updates
>  - Mark AbstractMap due to CHM
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/85331943...574273a6

LGTM.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2998513542

From cjplummer at openjdk.org  Tue Jul  8 18:03:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Jul 2025 18:03:17 GMT
Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR enabled
 due to unknown thread type JfrRecorderThread
Message-ID: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>

Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25.

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

Commit messages:
 - Backport 712d866b72b43c839c57c3303dfb215f94c0db3b

Changes: https://git.openjdk.org/jdk/pull/26198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360312
  Stats: 25 lines in 5 files changed: 13 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26198/head:pull/26198

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

From kevinw at openjdk.org  Tue Jul  8 18:19:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Jul 2025 18:19:38 GMT
Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR
 enabled due to unknown thread type JfrRecorderThread
In-Reply-To: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
References: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
Message-ID: <SFm45RDA09uxj7wG1wEDIG23fbbJOCRkoo0Jw_SC4C4=.c904b764-075a-478d-97dc-48d85af4d073@github.com>

On Tue, 8 Jul 2025 17:57:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25.
> 
> Tier5 ci testing in progress.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26198#pullrequestreview-2998666738

From amenkov at openjdk.org  Tue Jul  8 18:47:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 18:47:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <tImCdxDdNg5PBFAAXPolE9DuepAmiMMuZt6paqMcS7o=.39c8647b-c049-4971-91c8-9bf8a9b5fb50@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
 <tImCdxDdNg5PBFAAXPolE9DuepAmiMMuZt6paqMcS7o=.39c8647b-c049-4971-91c8-9bf8a9b5fb50@github.com>
Message-ID: <6GH5AhAEIIF-HE1b-uICTq-joGU511W1vWn5s8aQFI0=.fb0cd3b4-7788-4851-8bac-782c2f310aac@github.com>

On Tue, 8 Jul 2025 01:52:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm also unclear if this code in the handshake is sufficient for dealing with the case where we have a mounted virtual thread initially, but it is unmounted before the handshake gets to execute:
> 
> ```
>     if (java_lang_VirtualThread::is_instance(_java_thread())) {
>         // if (thread->vthread() != _java_thread()) // We might be inside a System.executeOnCarrierThread
>         const ContinuationEntry* ce = thread->vthread_continuation();
>         if (ce == nullptr || ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())) {
>           return; // not mounted
>         }
>       }
> ```
> 
> The commented line seems an inaccurate characterization as we could be executing a completely different virtual thread on this carrier now - which is not related to `executeOnCarrierThread`.

I suppose the comment is obsolete. I don't see `executeOnCarrierThread` in the current codebase.
The condition checks if there were some changes in vthread/carrier:
`ce == nullptr` - the carries has no mounted vthread now (i.e. the vthread has been unmounted);
`ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())` - the carrier has other vthread mounted;
Even if there were unmount/mount the same vthread on the carrier, it's fine (we need vthread stack trace and we are in handshake with its carrier)

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3049959218

From iklam at openjdk.org  Tue Jul  8 19:05:43 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Jul 2025 19:05:43 GMT
Subject: [jdk25] Integrated: 8358680: AOT cache creation fails: no strings
 should have been added
In-Reply-To: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
References: <Ejev6ejZmm4ISrKXqf2acFCDc5AwdH4OWgFCvqWyyDI=.34dd191b-6668-46c3-b703-ead8ff93c216@github.com>
Message-ID: <D3SC_e3x6ulaxP-s0--rWJg5UTnMXkg8cmywZ8qLS_U=.f5558ae5-42a5-4657-8235-65abfb70804f@github.com>

On Sun, 6 Jul 2025 23:02:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [3daa03c3](https://github.com/openjdk/jdk/commit/3daa03c30f8e6ab9c498edb7d59346ce0b30450f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 3 Jul 2025 and was reviewed by Coleen Phillimore and Aleksey Shipilev.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 1e985168
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e985168d674d7087727f0dea11c2d50446f3977
Stats:     65 lines in 8 files changed: 47 ins; 2 del; 16 mod

8358680: AOT cache creation fails: no strings should have been added

Reviewed-by: shade, kvn
Backport-of: 3daa03c30f8e6ab9c498edb7d59346ce0b30450f

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

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

From yzheng at openjdk.org  Tue Jul  8 19:23:31 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 19:23:31 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v2]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  restore HotSpotNmethod constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/53c9279d..b17efc69

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

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

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

From amenkov at openjdk.org  Tue Jul  8 19:32:48 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 19:32:48 GMT
Subject: Integrated: 8355960: JvmtiAgentList::Iterator dtor double free with
 -fno-elide-constructors
In-Reply-To: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
References: <ZNYfDwvFh_fOWSXOzb2FBxBbooPskgdGYwFSlMo6L50=.fcfac575-2c03-4a0f-bb30-40f661913f4c@github.com>
Message-ID: <noeSqZfZSmX-swK-Fj-uOGTnDExK6jGAuSp5m0SCRQo=.8baa8443-eea4-4d5f-85af-e27311f3d7c0@github.com>

On Wed, 2 Jul 2025 01:47:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list).
> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap.
> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice.
> 
> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail.
> Iterator now needs only single pointer to next agent.
> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator).
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: 03526e25
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03526e250dfb9ac61f50f482b5dfb330e7fec1bf
Stats:     83 lines in 6 files changed: 23 ins; 35 del; 25 mod

8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors

Reviewed-by: dholmes, sspitsyn

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

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

From kvn at openjdk.org  Tue Jul  8 19:35:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Jul 2025 19:35:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <BpQyVhtMBFbk9P_ezpQWZPduk6_ost5Up5wlIHijPxk=.7517cff4-7d93-4373-997d-5f270fb324c9@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

My testing passed without new failures

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2998887858

From dnsimon at openjdk.org  Tue Jul  8 19:52:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 8 Jul 2025 19:52:41 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v2]
In-Reply-To: <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <s7HwZc0l4IfiaXWKiAxGmAdKOB08l87ON3N815GtJkc=.e9489f7d-c419-4102-89e1-761685383b22@github.com>
Message-ID: <qoiWbiOxTJRcJhYiK8usTd2NchcoJJhSOA5FPbwA5mc=.578d314d-3eb4-4d56-820d-3e76211b2191@github.com>

On Tue, 8 Jul 2025 19:23:31 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HotSpotNmethod constructor

Looks good to me.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-2998930031

From coleenp at openjdk.org  Tue Jul  8 20:25:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 20:25:39 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <GaEbTUVyzSM6Ty7Ibjo7pqwxw76We2l9HILClhBfvbs=.9fba90e3-f288-4cd4-9be6-bad6d7a53352@github.com>

On Tue, 8 Jul 2025 02:17:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

This looks good.  is_readable_range avoids unaligned SafeFetch32, right?

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26177#pullrequestreview-2999007489

From mdoerr at openjdk.org  Tue Jul  8 20:29:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 20:29:40 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <GaEbTUVyzSM6Ty7Ibjo7pqwxw76We2l9HILClhBfvbs=.9fba90e3-f288-4cd4-9be6-bad6d7a53352@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <GaEbTUVyzSM6Ty7Ibjo7pqwxw76We2l9HILClhBfvbs=.9fba90e3-f288-4cd4-9be6-bad6d7a53352@github.com>
Message-ID: <VM-TVAEV7pNnWgJIOVsT1q50Y3zj85mH-MxVzATNJx8=.7d11a4ca-d759-4346-b6c7-b34432d578ec@github.com>

On Tue, 8 Jul 2025 20:23:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good. is_readable_range avoids unaligned SafeFetch32, right?

Right. It aligns down to `min_page_size` which fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3050212901

From yzheng at openjdk.org  Tue Jul  8 20:36:19 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 8 Jul 2025 20:36:19 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimiztaion profile [v3]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <HSCGUK540U-viHG3dLVaFqWs6VW49WKBl4uRe4-C_SQ=.59b0a7a7-4981-407e-b4c0-4b0c383f2a28@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/b17efc69..c0afd3c1

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

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

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

From dholmes at openjdk.org  Tue Jul  8 21:22:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:22:44 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
Message-ID: <qgXzh3EB8S2kJ1gPQtwzV0r9AzOQwUglDQ99fJIjPX0=.f90c32e5-600d-42b1-a40d-0384568fe4ee@github.com>

On Tue, 8 Jul 2025 12:11:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> src/hotspot/share/oops/klassVtable.cpp line 1342:
> 
>> 1340:     if (target == nullptr || !target->is_public() || target->is_abstract()) {
>> 1341:       // Entry does not resolve. Leave it empty for AbstractMethodError or other error.
>> 1342:       if (!(target == nullptr) && !target->is_public()) {
> 
> Since you're here, can you fix this line to be target != nullptr ?  This part makes sense.  The reason to have overpass methods is to participate in resolution and selection.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193461830

From dholmes at openjdk.org  Tue Jul  8 21:25:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:25:56 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong thing to do. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - modified existing regression test
>  - tiers 1-4
> 
> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix weird logic - requested by Coleen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26122/files
  - new: https://git.openjdk.org/jdk/pull/26122/files/29883542..d12213e3

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

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

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

From mdoerr at openjdk.org  Tue Jul  8 21:27:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 21:27:40 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <orPjcR3bMIWArtp2E1LbMqsWXRGGo2hRx-i_-BSH_yQ=.566a1dbd-f4c4-4683-9903-5c0e2dfddf13@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Tests have passed on linux PPC64 Big Endian.

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3050341686

From dholmes at openjdk.org  Tue Jul  8 21:31:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 8 Jul 2025 21:31:39 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
Message-ID: <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>

On Tue, 8 Jul 2025 12:21:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced new test by updating existing defmeth case that was missing the invokeinterface variants of the
>>   test scenario. Also updated all tests therein to use `throwsExact` so that the wrong kind of ICCE does not
>>   cause the test to pass by mistake.
>
> src/hotspot/share/oops/klassVtable.cpp line 1185:
> 
>> 1183:       // Do not check loader constraints for overpass methods because overpass
>> 1184:       // methods are created by the jvm to throw exceptions.
>> 1185:       if (!target->is_overpass()) {
> 
> Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.
> 
> What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.

> Why are loader constraints not checked for overpass methods? In your description it says they are checked? 

I don't follow. They were checked prior to [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) but they should not be - you need to read [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) for the "why". I'm simply changing how we decide to skip them for overpass methods - using the same technique as is already applied to the vtable methods.

> What's confusing is that there are two check_constraints 

Yes one on the `klassVtable` and one on the `klassItable`. They do the same high-level job but are quite different in structure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193474205

From coleenp at openjdk.org  Tue Jul  8 22:40:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 22:40:49 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
Message-ID: <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>

On Tue, 8 Jul 2025 21:25:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix weird logic - requested by Coleen

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-2999252763

From coleenp at openjdk.org  Tue Jul  8 22:40:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Jul 2025 22:40:51 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v2]
In-Reply-To: <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <pOjAt2RD7YT6mRCalsFuSICmPZiGwU5WcvnIyLeuPzg=.421033ec-bb28-433d-ba2f-da5d9ded2a40@github.com>
 <sg2BaA5GbTmSv0xhlICIEuwWODgdoVIpXrXvrK5TFTQ=.e42c54a5-5dbf-4ea7-9ea1-2257df5ef96a@github.com>
 <4XY5qLg38mHt72XRKAxWQIFJHZF0hssJ0_xy61G3SSY=.fe38f7f4-8c49-4c1f-b858-9b58f012cded@github.com>
Message-ID: <GBMukQiS8N_ylAQCIULNr269aey4MYtqV6D6tK03iZ4=.c531a8d0-86a0-4804-8198-4e9d468cfbe9@github.com>

On Tue, 8 Jul 2025 21:28:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/klassVtable.cpp line 1185:
>> 
>>> 1183:       // Do not check loader constraints for overpass methods because overpass
>>> 1184:       // methods are created by the jvm to throw exceptions.
>>> 1185:       if (!target->is_overpass()) {
>> 
>> Why are loader constraints not checked for overpass methods?  In your description it says they _are_ checked?  But not here?  If the two methods that are duplicate on the inheritance path and should get ICCE have a loader constraint violation with one of their parameter or return type, they should get a LinkageError, but not ICCE.
>> 
>> What's confusing is that there are two check_constraints - I was looking at the wrong one that also has the !target->is_overpass() condition.  Are these mostly the same now?  Maybe after this change is backported they can be refactored so they share more code.
>
>> Why are loader constraints not checked for overpass methods? In your description it says they are checked? 
> 
> I don't follow. They were checked prior to [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) but they should not be - you need to read [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) for the "why". I'm simply changing how we decide to skip them for overpass methods - using the same technique as is already applied to the vtable methods.
> 
>> What's confusing is that there are two check_constraints 
> 
> Yes one on the `klassVtable` and one on the `klassItable`. They do the same high-level job but are quite different in structure.

Okay.  Now I see (thanks for the explanation).  The wrong thing to do wasn't skipping loader constraint checks, it was where we skip them.  Now that these methods look the same, the consistency is helpful for understanding this.

>> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java line 86:
>> 
>>> 84:      * TEST: C c = new C(); c.m() ==> ICCE
>>> 85:      * TEST: I c = new C(); c.m() ==> ICCE
>>> 86:      * TEST: J c = new C(); c.m() ==> ICCE
>> 
>> So this is the generator code that generates the defmeth tests, but iirc, the tests are regenerated and the generated tests were the ones checked in and run.
>> 
>> And shouldn't the test from commit 87e30fd80172c5bd6748f140ddf6cd19adb62764 now fail?
>
> I'm not aware of any checked in generated tests. I added the new tests here and they run.
> 
> Why should the test for loader-constraints fail? I fixed that issue just in a different way to the original fix. Hence the test passes as it should.

Got it now.

Thanks for verifying that the new tests run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193547047
PR Review Comment: https://git.openjdk.org/jdk/pull/26122#discussion_r2193547246

From sparasa at openjdk.org  Tue Jul  8 22:44:55 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 8 Jul 2025 22:44:55 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>

> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
> 
> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
> 
> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  rename to paired_push and paired_pop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25889/files
  - new: https://git.openjdk.org/jdk/pull/25889/files/8ea6d6ce..24e6da2c

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

  Stats: 370 lines in 23 files changed: 0 ins; 1 del; 369 mod
  Patch: https://git.openjdk.org/jdk/pull/25889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25889/head:pull/25889

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

From sparasa at openjdk.org  Tue Jul  8 22:44:55 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 8 Jul 2025 22:44:55 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <VkcQ9wveSzWc_zYGOhnZcSiBk_kUk-A3u2MrKMg-AVU=.03077fce-a8d2-4368-9191-0f6d412ba5af@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <EU4y_XmwWNwv71_jdB9gAFGMYeU7917l7g722XNlOg8=.c1500814-65f5-460a-88d6-35a677294ebd@github.com>
 <VkcQ9wveSzWc_zYGOhnZcSiBk_kUk-A3u2MrKMg-AVU=.03077fce-a8d2-4368-9191-0f6d412ba5af@github.com>
Message-ID: <1qCd44HFg1tS1jUP-FIuzjUX8ePGDR2ViSFmhHsc_yE=.82e01450-c341-4cfa-909e-91f7be1d70a3@github.com>

On Thu, 3 Jul 2025 04:53:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Just a drive-by comment as this isn't code I normally have much to do with but to me it would look a lot cleaner to define `push_paired`/`pop_paired` (maybe abbreviating directly to `pushp`/`popp`?) rather than passing the boolean.
>
>> @dholmes-ora would you mind sharing your opinion? We seem to be making things more complicated, but hopefully in a good way?
> 
> Seems very complicated to me. Really this is for compiler folk to discuss. And as noted above this "tracker" class only helps where the push/pop are paired in the same scope. Personally I think a "pushp" that is defined to be a "push-paired" when available, else a regular "push", would suffice in terms of API design. But again this is for compiler folk to determine.

> Like @dholmes-ora, I also prefer a new function (in MacroAssembler) instead of flags. Though I like the names `paired_push`/`paired_pop`..
>

Please see the updated code with `paired_push`/`paired_pop`. Thanks for the suggestions!

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

PR Comment: https://git.openjdk.org/jdk/pull/25889#issuecomment-3050476284

From dholmes at openjdk.org  Wed Jul  9 02:32:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Jul 2025 02:32:44 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <ZjW4fwH3DBFHOpoiWU_4ED9aKY5E6I1THX9cz1nNbxM=.174496dd-e70a-48be-bf4d-c5340a376b84@github.com>

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Review comment - remove extra blank lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26177/files
  - new: https://git.openjdk.org/jdk/pull/26177/files/87b5dd88..de418b1b

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

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

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

From dholmes at openjdk.org  Wed Jul  9 02:32:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Jul 2025 02:32:44 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <VM-TVAEV7pNnWgJIOVsT1q50Y3zj85mH-MxVzATNJx8=.7d11a4ca-d759-4346-b6c7-b34432d578ec@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <GaEbTUVyzSM6Ty7Ibjo7pqwxw76We2l9HILClhBfvbs=.9fba90e3-f288-4cd4-9be6-bad6d7a53352@github.com>
 <VM-TVAEV7pNnWgJIOVsT1q50Y3zj85mH-MxVzATNJx8=.7d11a4ca-d759-4346-b6c7-b34432d578ec@github.com>
Message-ID: <Siyfhnt8ZLfofibPkl5MeCQhHJv5Tyrq1Vwg2vQA7nY=.e2ff5e2f-fe5c-43e3-9263-978236341a58@github.com>

On Tue, 8 Jul 2025 20:26:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > This looks good. is_readable_range avoids unaligned SafeFetch32, right?
> 
> Right. It aligns down to `min_page_size` which is fine.

It also avoids the endian-ness issue of reading a byte from a 32-bit int.

Thanks for the review @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3050903852

From dholmes at openjdk.org  Wed Jul  9 02:32:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Jul 2025 02:32:45 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <JFV7PILyFnzpg-I70nsacnOq_Feg7AGNt8zlzR-QHps=.fe9d0d64-38a8-4878-89de-6156f7b79da5@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <JFV7PILyFnzpg-I70nsacnOq_Feg7AGNt8zlzR-QHps=.fe9d0d64-38a8-4878-89de-6156f7b79da5@github.com>
Message-ID: <VSOrEWsljWIfSuz0pFWMTI1VV0L6EOtbgJsWHAU5LcM=.92d7bf02-dd2e-46b0-86b7-669490f723a7@github.com>

On Tue, 8 Jul 2025 15:37:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment - remove extra blank lines
>
> src/hotspot/share/memory/guardedMemory.hpp line 157:
> 
>> 155:     void* get_tag2() const { return _tag2; }
>> 156: 
>> 157: 
> 
> Maybe remove extra empty lines?

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26177#discussion_r2193878131

From sspitsyn at openjdk.org  Wed Jul  9 04:15:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 04:15:20 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v4]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <ZWzpln7EHey2WMyp9nl5eqvLwtc8YYJSgIwYcLyElUE=.e40dbe5e-4303-4e96-b63b-9c9f2cc4d7ad@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI functions:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
> 
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/0c6ef896..da3f20a8

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

  Stats: 68 lines in 1 file changed: 5 ins; 48 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111

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

From sspitsyn at openjdk.org  Wed Jul  9 04:15:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 04:15:21 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v4]
In-Reply-To: <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
Message-ID: <zSzzQx-IwZ5LRna3FlvAAerx9AQMpIEQ9mSpAzXzLjA=.3dbb3823-e771-4bbb-8046-d33af115d758@github.com>

On Thu, 3 Jul 2025 18:41:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>
> src/hotspot/share/prims/jvmti.xml line 2991:
> 
>> 2989:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 2990:           The implementation is unable to pop this frame
>> 2991:           (e.g. called or calling method is a native method).
> 
> Directly below we have special OPAQUE_FRAME language for virtual threads. Do we want to get rid of it since it is now covered by the above language? Note there is also language directly above that discusses suspended virtual threads.

Thank you for the suggestion. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193968014

From sspitsyn at openjdk.org  Wed Jul  9 04:15:21 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 04:15:21 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v4]
In-Reply-To: <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <EDDWq2EUA9zQRyg5c0soGc4Qnd1xBADj1Rc3cjKNalQ=.10eae989-c44d-46a0-a090-dbe86fd9a567@github.com>
 <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com>
Message-ID: <jS43__azkfSbSsMXWrB5HfsCAnylc38TXGzSmdrqykc=.b01ef304-703e-4959-804a-300086b55338@github.com>

On Mon, 7 Jul 2025 21:10:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 3194:
>> 
>>> 3192:           (e.g. current frame is executing a native method).
>>> 3193:         </error>
>>> 3194:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 
>> Do we still need this section? Same question for repeated sections below.
>
> Thank you for suggestion. Let's think on this a little bit.

Thank you for the suggestion. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193968224

From sspitsyn at openjdk.org  Wed Jul  9 04:18:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 04:18:44 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
Message-ID: <8BMr_79RV7fedcZUNfyhxCbrWKCE8vyuBiskFOXs-hI=.9893949e-9c5a-4fe9-be19-6cca51ac0ac2@github.com>

On Mon, 7 Jul 2025 18:13:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI functions:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>> 
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions

I've decided to also unify the `OPAQUE_FRAME` clarifications of the `GetLocal/SetLocal` functions with the other `OPAQUE_FRAME` cases. It is fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26111#issuecomment-3051050715

From sspitsyn at openjdk.org  Wed Jul  9 04:18:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 04:18:45 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
 <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>
 <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com>
Message-ID: <f7CaGrceSQb4UrP6y0dkm1rxYP9eLtnFuq8r-_fouBc=.07e81d38-c47e-4d70-8cc9-0a115269e0fa@github.com>

On Mon, 7 Jul 2025 21:06:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 3082:
>> 
>>> 3080:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>>> 3081:           The implementation is unable to set a <eventlink id="FramePop"></eventlink> event for the frame
>>> 3082:           (e.g. the frame at <code>depth</code> is executing a native method).
>> 
>> I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame".
>
> Thank you for the comment.
> The `NotifyFramePop` is similar to `SetBreakpoint`. I'd even prefer it to be named accordingly: `SetFramePop` instead of `NotifyFramePop`.  Unfortunately, we can't easily rename API's by compatibility reasons.  We enable any kinds of events with `SetEventNotoficationMode` but these are two cases where we need to be precise in setting the events. The `SetBreakpoint` is to set a breakpoint notification at a specific method's bytecode. The `NotifyFramePop` is to set `FramePop` notification for a specific frame. So, I' prefer to keep the terminology similar for `Breakpoints` and `FramePop` events.

Chris, please, let me know if it is okay to keep this at is or you still want an update for the `NotifyFramePop`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193975815

From duke at openjdk.org  Wed Jul  9 04:32:46 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Wed, 9 Jul 2025 04:32:46 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v2]
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <uPqPptG072H04MEQOJ7YsEf3oAnXtOxxFNtEFwOBVJg=.34a6ba20-62dd-4bfe-b85a-3888cd98bdc4@github.com>

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

Guanqiang Han 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:

 - add regression test for JDK-8358592
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - 8358592: Assert in Assembler::ptest due to missing SSE42 support
   
   Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26151/files
  - new: https://git.openjdk.org/jdk/pull/26151/files/90bad7d6..0684264c

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

  Stats: 3048 lines in 159 files changed: 1515 ins; 714 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/26151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26151/head:pull/26151

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

From alanb at openjdk.org  Wed Jul  9 05:33:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Jul 2025 05:33:41 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <6GH5AhAEIIF-HE1b-uICTq-joGU511W1vWn5s8aQFI0=.fb0cd3b4-7788-4851-8bac-782c2f310aac@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
 <tImCdxDdNg5PBFAAXPolE9DuepAmiMMuZt6paqMcS7o=.39c8647b-c049-4971-91c8-9bf8a9b5fb50@github.com>
 <6GH5AhAEIIF-HE1b-uICTq-joGU511W1vWn5s8aQFI0=.fb0cd3b4-7788-4851-8bac-782c2f310aac@github.com>
Message-ID: <P6ScntNflH9DfrUlFjnqEGFN2ZQtWvlvp_msCeWBSzA=.3a58f5d9-a97a-46f1-9a31-659aa2bc87ec@github.com>

On Tue, 8 Jul 2025 18:44:43 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I suppose the comment is obsolete. I don't see `executeOnCarrierThread` in the current codebase. The condition checks if there were some changes in vthread/carrier: `ce == nullptr` - the carries has no mounted vthread now (i.e. the vthread has been unmounted); `ce->cont_oop(thread) != java_lang_VirtualThread::continuation(_java_thread())` - the carrier has other vthread mounted; Even if there were unmount/mount the same vthread on the carrier, it's fine (we need vthread stack trace and we are in handshake with its carrier)

I suspect it dates back to when there were temporary transitions and where the thread identity had to be temporarily changed to the carrier thread. We've been able to remove that complexity, which eliminates complexity from JVMTI, and maybe here too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3051177617

From iwalulya at openjdk.org  Wed Jul  9 05:47:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 9 Jul 2025 05:47:46 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v11]
In-Reply-To: <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <VbubVOEFJfbvyQfqlUQpx1bg0aVCYXJhO4uTacB9cs0=.ceb760e6-7b09-48a7-a6ea-635926cb22ec@github.com>
Message-ID: <pM3HQiqjxi0bEcBHzQKnfNDRHsnKDl8H6eNuoXse24A=.0ff26f2c-fe27-419f-9d78-d4213947e074@github.com>

On Fri, 4 Jul 2025 15:28:20 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - Albert suggestions
>  - Improve comment
>  - Thomas Review
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - Thomas Review
>  - Reviews
>  - Albert suggestions
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - remove unrequired changes - kim
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f153e415...5c388d54

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25832#issuecomment-3051200761

From iwalulya at openjdk.org  Wed Jul  9 05:47:46 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 9 Jul 2025 05:47:46 GMT
Subject: Integrated: 8238687: Investigate memory uncommit during young
 collections in G1
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <GSwg0kaThNVgfe9QNfcZU84493ZOkEXpBntXbI7MCTQ=.c9da7cb3-c864-45f6-b649-0aa50d7f9f55@github.com>

On Mon, 16 Jun 2025 14:05:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

This pull request has now been integrated.

Changeset: 47614796
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4761479608d5a8ecc504e343109900b0d0c77171
Stats:     618 lines in 16 files changed: 395 ins; 89 del; 134 mod

8238687: Investigate memory uncommit during young collections in G1
8247843: Reconsider G1 default GCTimeRatio value
8248324: G1: Remove resizing during Remark

Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Reviewed-by: kbarrett, tschatzl

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

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

From duke at openjdk.org  Wed Jul  9 06:17:59 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Wed, 9 Jul 2025 06:17:59 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v3]
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update Test8358592.java
  
  run on x86_64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26151/files
  - new: https://git.openjdk.org/jdk/pull/26151/files/0684264c..1fe904db

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

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

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

From mbaesken at openjdk.org  Wed Jul  9 06:47:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Jul 2025 06:47:38 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <-LMVVz6nmkGgqub_J0rVAWYp21JjGs4A2m3MrkBPRh8=.38a13c98-767d-4655-930a-49a06f6ef251@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <-LMVVz6nmkGgqub_J0rVAWYp21JjGs4A2m3MrkBPRh8=.38a13c98-767d-4655-930a-49a06f6ef251@github.com>
Message-ID: <r3WEPpy9dJcamh_XuKVlaIcD1peqN3m5yZIMWl9aZS0=.1450f9aa-1c24-4003-8be2-8cb608e9be3b@github.com>

On Tue, 8 Jul 2025 02:20:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> run this through your testing - thanks.

Hi David, the tests look good, I did not see issues related to your change !
(maybe the ubsan issue reported is still there but we do not test with ubsanized binaries daily;  but if it is still there we can address it separately)

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3051368554

From dbriemann at openjdk.org  Wed Jul  9 07:59:38 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 9 Jul 2025 07:59:38 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <gfK5mNGOiVapPLl8PHQ879-Wz-zmTvzv3PnPnzs28qs=.872affc6-f02c-49a8-be01-55fdacf26846@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Thanks for testing that!

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051576708

From duke at openjdk.org  Wed Jul  9 07:59:38 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Jul 2025 07:59:38 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <TFWJ0pfYtnTicO1u2_rJWFkL9u3UcxqCLP6rJF1NIe8=.2952ab6d-25f0-473a-aac8-c492b6f5f06b@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

@dbriemann 
Your change (at version f79e289564b527bad4e261e1db72d62b1a06e4c4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051578710

From mdoerr at openjdk.org  Wed Jul  9 08:00:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Jul 2025 08:00:44 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <ZjW4fwH3DBFHOpoiWU_4ED9aKY5E6I1THX9cz1nNbxM=.174496dd-e70a-48be-bf4d-c5340a376b84@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <ZjW4fwH3DBFHOpoiWU_4ED9aKY5E6I1THX9cz1nNbxM=.174496dd-e70a-48be-bf4d-c5340a376b84@github.com>
Message-ID: <gJFaVKr1nvLwbYOlUovKL1Ll901of6j2MCRZWRD-5Gc=.7dbd9d1d-0475-4431-ac11-81dbaedac269@github.com>

On Wed, 9 Jul 2025 02:32:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
>> 
>> Testing: tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment - remove extra blank lines

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26177#pullrequestreview-3000467937

From yzheng at openjdk.org  Wed Jul  9 08:01:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 08:01:52 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v4]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  fix compilation error in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/c0afd3c1..3f7b2362

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

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

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

From ayang at openjdk.org  Wed Jul  9 08:06:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:06:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v21]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <hcfjkZ-UhUTC3bppfRX14ywIdvRvSXoiXMpAZRfxfL4=.00d16c06-4b13-49d9-8fe5-3d0059fe2e56@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - ... and 22 more: https://git.openjdk.org/jdk/compare/117f0b40...0d5de9a2

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=20
  Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Wed Jul  9 08:06:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:06:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com>
 <sygncn4Bs6Ww0iOSU5q-jFvBYvZRx-aphVHNR8RsAPA=.90bc8572-4c32-4893-bdad-21f6991d3199@github.com>
 <eVepnCg32apDKXAn7rezipT5YRqLa8c-cjjARftsnoQ=.e90c58d3-ba06-41c1-9cd5-94ba49e322a2@github.com>
Message-ID: <-tg-l6DOtno0KEnAIgMPSuWLoHZLtJnTdj4BRLUnGpo=.be889c98-761f-416c-bd74-e2d3986db1b7@github.com>

On Mon, 7 Jul 2025 00:39:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I don't see how I changed the semantics.
>> 
>> On baseline, from `mem_allocate_work`:
>> 
>> 
>> if (result != nullptr) {
>>   return result;
>> }
>> 
>> // If certain conditions hold, try allocating from the old gen.
>> if (!is_tlab) {
>>   result = mem_allocate_old_gen(size);
>>   if (result != nullptr) {
>>     return result;
>>   }
>> }
>> 
>> 
>> and
>> 
>> 
>> HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>>   if (!should_alloc_in_eden(size)) {
>>     // Size is too big for eden.
>>     return allocate_old_gen_and_record(size);
>>   }
>> 
>>   return nullptr;
>> }
>> 
>> 
>> The original logic is essentially:
>> 
>> 
>> if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) {
>>   // allocate in old-gen
>> }
>> 
>> which is the same as I put here.
>
> Ah, okay.

I took another look at this and realized that there are to paths to do retry-allocation-in-old-gen-after-young-gen-failure.

1. In `mem_allocate_work`.


      HeapWord* result = young_gen()->allocate(size);
      if (result != nullptr) {
        return result;
      }

      // If certain conditions hold, try allocating from the old gen.
      if (!is_tlab && !should_alloc_in_eden(size)) {
        result = old_gen()->cas_allocate_noexpand(size);


This retry-allocation-in-old-gen is *pre-gc* -- the `should_alloc_in_eden` filter is there to ensure that a (young) gc should kick-in, instead of populating old-gen with many small objs.

2. In `satisfy_failed_allocation` -> `expand_heap_and_allocate`.


  HeapWord* result = young_gen()->expand_and_allocate(size);

  if (result == nullptr && !is_tlab) {
    result = old_gen()->expand_and_allocate(size);
  }


This retry-allocation-in-old-gen is *post-gc* -- we should not artificially introduce old-gen-allocation-failure, because that would mean the previous (young/full) gc was useless to this allocation-request.

Therefore, I believe the logic on master is more reasonable. Also, for back compatibility reasons, I have reverted this part and added a comment there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2194344731

From dnsimon at openjdk.org  Wed Jul  9 08:09:38 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 08:09:38 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v4]
In-Reply-To: <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <xbILPDRQ329SWqbJliW_WxlZT0qOeC_2P9DKY5S_EhA=.732a38fb-9ec2-47e0-92a4-f6d586bab9ae@github.com>
Message-ID: <3uFGBbe0KELpzdGDivwsEUR8DWZSoQhGXuT_t6qD_Bg=.1c4cc3f2-aa64-4901-bc4c-3639171feda4@github.com>

On Wed, 9 Jul 2025 08:01:52 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error in test

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3000496268

From dbriemann at openjdk.org  Wed Jul  9 08:30:48 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 9 Jul 2025 08:30:48 GMT
Subject: Integrated: 8361599: [PPC64] enable missing tests via jtreg requires
In-Reply-To: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
Message-ID: <tm55BWns2aAJ76F4KClRO2CIvqvXrBo5CKbk9vEcgDQ=.a23cdf78-65d5-49a4-ab8f-108cab8331be@github.com>

On Tue, 8 Jul 2025 13:19:35 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

This pull request has now been integrated.

Changeset: 83feb7a2
Author:    David Briemann <dbriemann at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83feb7a2388e33835b2071cfe0e51ba8b43e241f
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8361599: [PPC64] enable missing tests via jtreg requires

Reviewed-by: mdoerr

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

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

From ayang at openjdk.org  Wed Jul  9 08:33:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 08:33:15 GMT
Subject: RFR: 8361680: Use correct enum Claim value in
 VM_HeapWalkOperation::collect_simple_roots
Message-ID: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>

Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion.

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

Commit messages:
 - trivial

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

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

From shade at openjdk.org  Wed Jul  9 08:36:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 08:36:37 GMT
Subject: RFR: 8361680: Use correct enum Claim value in
 VM_HeapWalkOperation::collect_simple_roots
In-Reply-To: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
References: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
Message-ID: <1P2g9O_at3m1WbHsuLBZjpmDfq7SbDT0BBChzcs3FhQ=.2eb89b13-43fe-4481-8c6d-82a7a03318a2@github.com>

On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26214#pullrequestreview-3000579279

From adinn at openjdk.org  Wed Jul  9 08:47:45 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:47:45 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <erE4b8LOPtaN86RCIYcp598SYcFvvAdqcGzy_V_OO8o=.5713eff3-ead9-4173-b72e-2cd5a6e83540@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

@erikj79 This PR seems to be stuck at the integrate stage -- any ideas why?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3051731338

From adinn at openjdk.org  Wed Jul  9 08:51:49 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:51:49 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <tj-4vPSN7G-dtAW57xU16gfh6QcX-872-gzCObNZnxY=.a5a4a81e-6a0d-4d90-8b56-ff740d68bd57@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

@erikj79 Dunno what you did but that was quick ;-)
Ta!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3051744175

From adinn at openjdk.org  Wed Jul  9 08:51:51 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:51:51 GMT
Subject: Integrated: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <4FwaYZxJwOB98MPL7D8N8VTbnjiw_3L4Qf8Ehj4Hm-Y=.05774235-6bda-4ff8-9eff-a509c851982c@github.com>

On Thu, 26 Jun 2025 15:58:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

This pull request has now been integrated.

Changeset: b1fa1ecc
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b1fa1ecc988fb07f191892a459625c2c8f2de3b5
Stats:     4137 lines in 102 files changed: 2008 ins; 274 del; 1855 mod

8360707: Globally enumerate all blobs, stubs and entries

Reviewed-by: kvn, fyang, asmehra

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

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

From yzheng at openjdk.org  Wed Jul  9 10:53:20 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 10:53:20 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  fix compilation error, update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/3f7b2362..b67bd1bb

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

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

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

From gdub at openjdk.org  Wed Jul  9 11:27:39 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 9 Jul 2025 11:27:39 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
Message-ID: <GP5nYib3TRaCRYc27QTvJL0oFj5d0LoZYN3iNLXqrOc=.425fbd16-8758-441b-a6f0-d184896575cb@github.com>

On Wed, 9 Jul 2025 10:53:20 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error, update copyright year

Marked as reviewed by gdub (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3001149894

From dnsimon at openjdk.org  Wed Jul  9 11:46:42 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 11:46:42 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v5]
In-Reply-To: <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <jZCgVtXvZhwrqT-aGp3WVBFvLIgFvPS49eDGu3Dti4k=.d9eaa2e4-a46e-4c23-96f5-bc724f83d58a@github.com>
Message-ID: <Rub6OGY03C1lTLF6-AVtOUQDnUmwRr3JLTmZSNo7XCU=.796f2178-f53d-41b3-bb6a-c3ce04c92475@github.com>

On Wed, 9 Jul 2025 10:53:20 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compilation error, update copyright year

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3001204538

From ayang at openjdk.org  Wed Jul  9 12:03:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 12:03:46 GMT
Subject: RFR: 8361680: Use correct enum Claim value in
 VM_HeapWalkOperation::collect_simple_roots
In-Reply-To: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
References: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
Message-ID: <epoxk5e1_2elTx5_zNG5dAg2hdDG9LBvLYanfFNqX-U=.ff521a05-5f96-4f0e-b84e-18ab702c7842@github.com>

On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26214#issuecomment-3052380514

From ayang at openjdk.org  Wed Jul  9 12:03:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Jul 2025 12:03:46 GMT
Subject: Integrated: 8361680: Use correct enum Claim value in
 VM_HeapWalkOperation::collect_simple_roots
In-Reply-To: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
References: <RGQ6lQUxPVp5sYLcCd8SJZDY38xe_2QJB05-YhxFG_E=.6f55867e-2212-47f1-9090-12b36727a913@github.com>
Message-ID: <5bbkdgPu8pO3BXhdf31cSrlI-r1FIkFM3OopyfdFaWQ=.02657dc5-d815-4b2b-9d64-686aff73a364@github.com>

On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion.

This pull request has now been integrated.

Changeset: eec04dd0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eec04dd01051064bacf5110539755aa41106b1a6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots

Reviewed-by: shade

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

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

From liach at openjdk.org  Wed Jul  9 13:25:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Jul 2025 13:25:22 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Reviews
 - Documentation
 - Don't fail for patching tests
 - Remove design document from code
 - Some more from reviews
 - Reviewed the diff on github
 - Stage
 - Missed comment updates
 - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b

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

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=10
  Stats: 453 lines in 38 files changed: 280 ins; 150 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

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

From yzheng at openjdk.org  Wed Jul  9 13:37:56 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 13:37:56 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v6]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <a3nk2yBJulOtA4gJtYJUpyg52epibbzoziphcvYli2I=.3f9fb4c8-9fe2-42ae-98b1-c9792474c6ae@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  fix method not found in truffle tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/b67bd1bb..ca92354e

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

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

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

From tschatzl at openjdk.org  Wed Jul  9 14:12:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 14:12:12 GMT
Subject: RFR: 8361698: Fix obsolete comments in Klass::clean_weak_klass_links()
Message-ID: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>

Hi all,

  please review this fix to some comments in the Klass::clean_weak_klass_links() after the changes in JDK-8213209. I believe this is a trivial change.

Testing: local compilation

Thanks,
  Thomas

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

Commit messages:
 - 8361698

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

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

From tschatzl at openjdk.org  Wed Jul  9 14:12:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 14:12:54 GMT
Subject: RFR: 8361693: Remove Klass::clean_subklass_tree()
Message-ID: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>

Hi all,

  please review this inlining of Klass::clean_subklass_tree because it's only used in one place and replaces only one call. There does not seem to be any advantage having the extra method.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - 8361693

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

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

From thartmann at openjdk.org  Wed Jul  9 14:16:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Jul 2025 14:16:45 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v3]
In-Reply-To: <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>
Message-ID: <mCOG30UJm7qMo4ezo-5DqUh5TRhMe_JFzKpuYgaRMoI=.4b9c17ac-84cd-44cc-9d0f-6200407f09b3@github.com>

On Wed, 9 Jul 2025 06:17:59 GMT, Guanqiang Han <duke at openjdk.org> wrote:

>> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
>> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
>> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
>> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
>> The above code causes the ptest instruction to be invoked.
>> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
>> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
>> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
>> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
>> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
>> all of these above cause this issue.
>> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Test8358592.java
>   
>   run on x86_64

The fix looks reasonable to me but I'm not an expert in this code.

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

> 1492:         FLAG_SET_DEFAULT(UseSSE42Intrinsics, false);
> 1493:       }
> 1494:     }else{

Suggestion:

    } else {

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

> 1646:         FLAG_SET_DEFAULT(UseSSE42Intrinsics, false);
> 1647:       }
> 1648:     }else{

Suggestion:

    } else {

test/hotspot/jtreg/compiler/intrinsics/Test8358592.java line 31:

> 29:  * @requires os.arch == "x86_64"
> 30:  * @library /test/lib
> 31:  * @run main/othervm Test8358592

I think this test should go to `/hotspot/jtreg/compiler/arguments/` and have a more descriptive name (we generally try not use bug numbers for tests anymore).

test/hotspot/jtreg/compiler/intrinsics/Test8358592.java line 39:

> 37: public class Test8358592 {
> 38:     public static void main(String[] args) throws Exception {
> 39:         ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(

Instead of spawning a new process, you can just pass the arguments via `@run main/othervm`, see for example `test/hotspot/jtreg/compiler/arguments/TestC1Globals.java`.

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

Changes requested by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26151#pullrequestreview-3001515723
PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2195017641
PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2195017946
PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2195003179
PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2195004480

From yzheng at openjdk.org  Wed Jul  9 15:20:29 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 15:20:29 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

Yudi Zheng 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 remote-tracking branch 'upstream/master' into JDK-8361569
 - update signature
 - fix method not found in truffle tests
 - fix compilation error, update copyright year
 - fix compilation error in test
 - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
 - restore HotSpotNmethod constructor
 - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26192/files
  - new: https://git.openjdk.org/jdk/pull/26192/files/ca92354e..413c1f38

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

  Stats: 6846 lines in 241 files changed: 3657 ins; 830 del; 2359 mod
  Patch: https://git.openjdk.org/jdk/pull/26192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26192/head:pull/26192

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

From zgu at openjdk.org  Wed Jul  9 15:20:40 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 9 Jul 2025 15:20:40 GMT
Subject: RFR: 8361693: Remove Klass::clean_subklass_tree()
In-Reply-To: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
References: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
Message-ID: <YkFzDEnuoMYsgFP19XmBhYxpsLmcn-Bfoy8G5A5rd2c=.f891a0a1-c3b9-43b1-8385-b4ef6f0131f5@github.com>

On Wed, 9 Jul 2025 14:08:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this inlining of Klass::clean_subklass_tree because it's only used in one place and replaces only one call. There does not seem to be any advantage having the extra method.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26220#pullrequestreview-3001985884

From iklam at openjdk.org  Wed Jul  9 16:21:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Jul 2025 16:21:42 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
Message-ID: <ZR-8R65WmuyXoHcnIhr7ufAl-Vgdim1MUE3m_TsQFi0=.113e9e73-d235-472a-8ab8-ed20e568a50e@github.com>

On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - Some more from reviews
>  - Reviewed the diff on github
>  - Stage
>  - Missed comment updates
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3002212362

From coleenp at openjdk.org  Wed Jul  9 16:43:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Jul 2025 16:43:39 GMT
Subject: RFR: 8361698: Fix obsolete comments in
 Klass::clean_weak_klass_links()
In-Reply-To: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>
References: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>
Message-ID: <fHpyMQ6gmOFaHJwQREgl8RosnDAhP5oJ9P-SsGuecNg=.3b3be049-5b99-45ec-a92e-c6c9051133df@github.com>

On Wed, 9 Jul 2025 14:07:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to some comments in the Klass::clean_weak_klass_links() after the changes in JDK-8213209. I believe this is a trivial change.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

The method subclass only returns an alive subclass so I think the comment is right.

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

PR Review: https://git.openjdk.org/jdk/pull/26219#pullrequestreview-3002272416

From kbarrett at openjdk.org  Wed Jul  9 17:42:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Jul 2025 17:42:38 GMT
Subject: RFR: 8361693: Remove Klass::clean_subklass_tree()
In-Reply-To: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
References: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
Message-ID: <es5e_KWmOtL95BUGojPjyi2xiqv5BNRNedb8Fx21Yu4=.509f15f1-b1bb-44f8-ac11-c8f32d8e7268@github.com>

On Wed, 9 Jul 2025 14:08:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this inlining of Klass::clean_subklass_tree because it's only used in one place and replaces only one call. There does not seem to be any advantage having the extra method.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26220#pullrequestreview-3002498118

From tschatzl at openjdk.org  Wed Jul  9 18:21:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 18:21:47 GMT
Subject: RFR: 8361698: Fix obsolete comments in
 Klass::clean_weak_klass_links()
In-Reply-To: <fHpyMQ6gmOFaHJwQREgl8RosnDAhP5oJ9P-SsGuecNg=.3b3be049-5b99-45ec-a92e-c6c9051133df@github.com>
References: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>
 <fHpyMQ6gmOFaHJwQREgl8RosnDAhP5oJ9P-SsGuecNg=.3b3be049-5b99-45ec-a92e-c6c9051133df@github.com>
Message-ID: <6q6_WDEa7uZdZMjF9D3ZC9cvYI8jCJ6Ykq8Voity4-k=.661d66b8-7b6a-483d-b3c0-8638e8661635@github.com>

On Wed, 9 Jul 2025 16:41:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The method subclass only returns an alive subclass so I think the comment is right.

Then I'll retract this PR :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26219#issuecomment-3053584244

From tschatzl at openjdk.org  Wed Jul  9 18:21:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 18:21:47 GMT
Subject: Withdrawn: 8361698: Fix obsolete comments in
 Klass::clean_weak_klass_links()
In-Reply-To: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>
References: <KmemXqSxNkX-kXdbkrlE1Q7g3EoqE6yeEXygRS6xWXc=.b7fe1c8e-f1f1-4363-b759-d28f6e87fcf7@github.com>
Message-ID: <f1XdIrT2J7J86ZXimbFaA2FaljuBYFf20NFV-SqNVxo=.f3f05e24-e54b-4f6a-8cc4-7d8e9932f3a9@github.com>

On Wed, 9 Jul 2025 14:07:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this fix to some comments in the Klass::clean_weak_klass_links() after the changes in JDK-8213209. I believe this is a trivial change.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has been closed without being integrated.

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

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

From dnsimon at openjdk.org  Wed Jul  9 18:50:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Jul 2025 18:50:41 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
Message-ID: <77OT73LZ631dhxno_DH8ul9EGtW5b4kPcKLDtW3H6Lk=.23dd5f7c-d300-4d68-a1a0-241635bb89b3@github.com>

On Wed, 9 Jul 2025 15:20:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng 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 remote-tracking branch 'upstream/master' into JDK-8361569
>  - update signature
>  - fix method not found in truffle tests
>  - fix compilation error, update copyright year
>  - fix compilation error in test
>  - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
>  - restore HotSpotNmethod constructor
>  - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26192#pullrequestreview-3002711174

From yzheng at openjdk.org  Wed Jul  9 19:15:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 19:15:47 GMT
Subject: RFR: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod that
 should not collect deoptimization profile [v7]
In-Reply-To: <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
 <cnIOL7jv-bFMIGHpErmfABTVJVsXPfK6nIl3SH98a0Q=.d2f50a1f-a29f-4c35-9f82-a99349fe00ed@github.com>
Message-ID: <S_XPMGEI7Jj1UjbxgjwDps0evlCKoxMuk1vi2GGG1SU=.bb5e4109-1d4f-4c96-abc6-f532e225f61e@github.com>

On Wed, 9 Jul 2025 15:20:29 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.
>
> Yudi Zheng 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 remote-tracking branch 'upstream/master' into JDK-8361569
>  - update signature
>  - fix method not found in truffle tests
>  - fix compilation error, update copyright year
>  - fix compilation error in test
>  - JNIJVMCI::HotSpotNmethod::constructor() cannot be overloaded
>  - restore HotSpotNmethod constructor
>  - [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimiztaion profile

Thanks for the review! Passed Tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/26192#issuecomment-3053725076

From yzheng at openjdk.org  Wed Jul  9 19:15:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Jul 2025 19:15:47 GMT
Subject: Integrated: 8361569: [JVMCI] Further refine JVMCI-compiled nmethod
 that should not collect deoptimization profile
In-Reply-To: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
References: <yrlzXI81ZNqcno6IlLgx8KoZKVjhAXYAoW8_uLjlh6M=.23a7025d-d157-4213-befb-5f3e887d403d@github.com>
Message-ID: <OBh8fMmnSCqn3OED0HMwsir3Y86JwToliIJXN6DdBXo=.745a4c20-9261-4d8e-b6c2-2d511c1fa9c5@github.com>

On Tue, 8 Jul 2025 15:59:10 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/25356 we prevent all non-CompilerBroker JVMCI compilations from collecting deoptimiztaion profiles. This causes some regression in Graal's whitebox unit tests, some of which employ non-CompilerBroker compilations to test deoptimiztaions.

This pull request has now been integrated.

Changeset: 6681fc72
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6681fc72d3463e13876eb84a285eb580ee92b464
Stats:     86 lines in 18 files changed: 39 ins; 5 del; 42 mod

8361569: [JVMCI] Further refine JVMCI-compiled nmethod that should not collect deoptimization profile

Reviewed-by: dnsimon, gdub

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

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

From mbeckwit at openjdk.org  Wed Jul  9 20:15:29 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Wed, 9 Jul 2025 20:15:29 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
Message-ID: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@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 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.

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

Commit messages:
 - Fix trailing whitespace errors
 - JDK-8357445: G1: Time-Based Heap Uncommit During Idle Periods

Changes: https://git.openjdk.org/jdk/pull/26207/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357445
  Stats: 6178 lines in 21 files changed: 1276 ins; 4892 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26207/head:pull/26207

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

From amenkov at openjdk.org  Wed Jul  9 20:38:47 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 9 Jul 2025 20:38:47 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <A11anQUaMdwDAJ1-5VNTiPqlSTciQ0RhXerz_FwmYp8=.fc5ffb07-3b3e-497e-9c7f-f3f42daed00b@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
 <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
 <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>
 <A11anQUaMdwDAJ1-5VNTiPqlSTciQ0RhXerz_FwmYp8=.fc5ffb07-3b3e-497e-9c7f-f3f42daed00b@github.com>
Message-ID: <GOklkOloAZix0yHT_OO12vanoQWj1bSMAHYN3JGyxMI=.669acf40-2535-4f00-9318-1bfa31efa770@github.com>

On Tue, 8 Jul 2025 01:29:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Got it.
>
> Actually I think we need a further check here. If we get the carrier thread directly, we have not checked that it is actually protected by the TLH - that is normally done by `cv_internal_thread_to_JavaThread` but that doesn't know about virtual threads and carriers! I need to check if we have to fix `cv_internal_thread_to_JavaThread` for the virtual thread case.

Well, we don't have TLH protection for carrier (and looks like JVMTI also doesn't care about carrier protection).
I think it may be useful to add virtual thread support to `ThreadsListHandle` (and update comments in threadSMR.hpp).
What about:

  bool cv_internal_thread_to_JavaThread(jobject jthread, JavaThread ** jt_pp, oop * thread_oop_p);

+  bool cv_oop_to_JavaThread(oop thread_oop, JavaThread** jt_pp);
+  bool cv_thread_or_carrier_to_JavaThread(oop thread_oop, JavaThread** jt_pp, bool* is_virtual_p = nullptr);

Also we need a way to check if vthread is mounted to JavaThread (to be checked in handshake), I think it should go to javaThread.hpp/.cpp:


  inline bool is_vthread_mounted() const;
+  inline bool is_vthread_mounted(oop vthread) const;

What do you think?
Would be nice to hear @dcubed-ojdk opinion (AFAIK he implemented threadSMR stuff)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2195926903

From sspitsyn at openjdk.org  Wed Jul  9 23:29:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Jul 2025 23:29:39 GMT
Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR
 enabled due to unknown thread type JfrRecorderThread
In-Reply-To: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
References: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
Message-ID: <cLoaRzjlQkSg8tf26-eIQkkl5QmqFK_AFqy1AOtDyig=.cc275a06-7570-4a52-aaf3-2c07058d1da2@github.com>

On Tue, 8 Jul 2025 17:57:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25.
> 
> Tier5 ci testing in progress.

It is a clean backport.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26198#pullrequestreview-3003381861

From dholmes at openjdk.org  Thu Jul 10 00:10:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 00:10:49 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

After this integration we are seeing crashes on Linux x64 and Aarch64:

assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3054509580

From cjplummer at openjdk.org  Thu Jul 10 00:17:43 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Jul 2025 00:17:43 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <f7CaGrceSQb4UrP6y0dkm1rxYP9eLtnFuq8r-_fouBc=.07e81d38-c47e-4d70-8cc9-0a115269e0fa@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
 <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>
 <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com>
 <f7CaGrceSQb4UrP6y0dkm1rxYP9eLtnFuq8r-_fouBc=.07e81d38-c47e-4d70-8cc9-0a115269e0fa@github.com>
Message-ID: <Ly9B4W6DKlEZVLH5lHD_AHkXcROFosnjMqcndMo1OUg=.9db0ef19-7ecd-47ed-99d5-63bc1c250268@github.com>

On Wed, 9 Jul 2025 04:16:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thank you for the comment.
>> The `NotifyFramePop` is similar to `SetBreakpoint`. I'd even prefer it to be named accordingly: `SetFramePop` instead of `NotifyFramePop`.  Unfortunately, we can't easily rename API's by compatibility reasons.  We enable any kinds of events with `SetEventNotoficationMode` but these are two cases where we need to be precise in setting the events. The `SetBreakpoint` is to set a breakpoint notification at a specific method's bytecode. The `NotifyFramePop` is to set `FramePop` notification for a specific frame. So, I' prefer to keep the terminology similar for `Breakpoints` and `FramePop` events.
>
> Chris, please, let me know if it is okay to keep this at is or you still want an update for the `NotifyFramePop`.

I understand what you are saying about the comparison to SetBreakpoint and that SetFramePop would have been a better name, but I don't see what this with the description. I said "set a FramePop event" doesn't sound right. Neither would "set a Breakpoint event". Also, the analogy with breakpoints doesn't really work when you consider that "a breakpoint" is meaningful, but "a FrampPop" does not.

A breakpoint is a location in the code where a breakpoint event will be triggered when executed. That analogy doesn't really work with FramePop. We don't have a word similar to breakpoint that means "a frame marked for generating a FramePop event when popped".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2196234910

From duke at openjdk.org  Thu Jul 10 00:59:17 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Thu, 10 Jul 2025 00:59:17 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v4]
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <Plc98UIdf_WXEabMlIeccl6ncnlsrEBUyDEyVL6RqHU=.75eac192-032e-49eb-a0a2-0df6be493a5a@github.com>

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  update regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26151/files
  - new: https://git.openjdk.org/jdk/pull/26151/files/1fe904db..206e477a

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

  Stats: 88 lines in 3 files changed: 39 ins; 47 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26151/head:pull/26151

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

From sspitsyn at openjdk.org  Thu Jul 10 01:17:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 01:17:33 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should
 be obsoleted then expired
Message-ID: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>

The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.

There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
 - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
 - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
 
Testing:
 - mach5 tiers 1-6 are good
 - may need to run mach5 tiers > 6

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

Commit messages:
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

Changes: https://git.openjdk.org/jdk/pull/26232/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358890
  Stats: 1851 lines in 36 files changed: 0 ins; 1825 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

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

From dholmes at openjdk.org  Thu Jul 10 02:02:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 02:02:46 GMT
Subject: RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <r3WEPpy9dJcamh_XuKVlaIcD1peqN3m5yZIMWl9aZS0=.1450f9aa-1c24-4003-8be2-8cb608e9be3b@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
 <-LMVVz6nmkGgqub_J0rVAWYp21JjGs4A2m3MrkBPRh8=.38a13c98-767d-4655-930a-49a06f6ef251@github.com>
 <r3WEPpy9dJcamh_XuKVlaIcD1peqN3m5yZIMWl9aZS0=.1450f9aa-1c24-4003-8be2-8cb608e9be3b@github.com>
Message-ID: <UXLnV-AFs2fuBOHKSqCQpbJulhvLJ_3Oo0ruJPW7dFs=.04adfbc3-f4c6-4f7a-8c9e-1ffe644dbfc3@github.com>

On Wed, 9 Jul 2025 06:44:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> @MBaesken please run this through your testing - thanks.
>
>> run this through your testing - thanks.
> 
> Hi David, the tests look good, I did not see issues related to your change !
> (maybe the ubsan issue reported is still there but we do not test with ubsanized binaries daily;  but if it is still there we can address it separately)

Thanks for doing the testing @MBaesken !

Thanks for the review @TheRealMDoerr !

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

PR Comment: https://git.openjdk.org/jdk/pull/26177#issuecomment-3054998561

From dholmes at openjdk.org  Thu Jul 10 02:02:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 02:02:48 GMT
Subject: Integrated: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
References: <X5sPwUWxHzaRn_hp9QB0fzjDTJZ3voTAg5rCEQfCGFE=.2c73e51b-2868-49ee-91aa-99db98719852@github.com>
Message-ID: <psBlUYtgnJ3wY016JnMXztuMWO-tlVPlCnOgNrS8cHE=.9e198338-15a9-4d04-a46a-2ab754d79645@github.com>

On Tue, 8 Jul 2025 02:17:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The original PR (https://github.com/openjdk/jdk/pull/26123) had incorrect usage of `SafeFetch32`. This PR replaces that with the use of `os::is_readable_range` as proposed by @tstuefe  (thank you!). In addition I found that code was no longer getting exercised by the regression test so I added a gtest for that (during which it was discovered that the new implementation in `verify` requires any gtest that uses it to be `TEST_VM` rather than `TEST`).
> 
> Testing: tiers 1-4
> 
> Thanks

This pull request has now been integrated.

Changeset: f67e4354
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579
Stats:     349 lines in 6 files changed: 323 ins; 6 del; 20 mod

8361447: [REDO] Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays

Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: mdoerr, stuefe, coleenp

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

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

From iveresov at openjdk.org  Thu Jul 10 02:42:22 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 10 Jul 2025 02:42:22 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
Message-ID: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>

Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.

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

Commit messages:
 - Use OopStorage directly instead on JNI handles

Changes: https://git.openjdk.org/jdk/pull/26233/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358580
  Stats: 12 lines in 2 files changed: 6 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26233/head:pull/26233

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

From dholmes at openjdk.org  Thu Jul 10 02:42:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 02:42:28 GMT
Subject: [jdk25] RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
Message-ID: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>

Hi all,

This pull request contains a backport of commit [f67e4354](https://github.com/openjdk/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by David Holmes on 10 Jul 2025 and was reviewed by Martin Doerr, Thomas Stuefe and Coleen Phillimore.

Thanks!

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

Commit messages:
 - Backport f67e4354316dcec185eac66adec2395e20b62579

Changes: https://git.openjdk.org/jdk/pull/26234/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361447
  Stats: 349 lines in 6 files changed: 323 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26234/head:pull/26234

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

From sspitsyn at openjdk.org  Thu Jul 10 03:12:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 03:12:27 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  corrected one assert message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/a7bceacb..a8358402

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

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

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

From duke at openjdk.org  Thu Jul 10 03:39:38 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Thu, 10 Jul 2025 03:39:38 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v3]
In-Reply-To: <mCOG30UJm7qMo4ezo-5DqUh5TRhMe_JFzKpuYgaRMoI=.4b9c17ac-84cd-44cc-9d0f-6200407f09b3@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>
 <mCOG30UJm7qMo4ezo-5DqUh5TRhMe_JFzKpuYgaRMoI=.4b9c17ac-84cd-44cc-9d0f-6200407f09b3@github.com>
Message-ID: <hgBXjA-QEp4-eEmqFMVZfMV5tG_J72Q0f5sDAJKKE0E=.4a847ef6-209d-40e4-9516-496ed37a331c@github.com>

On Wed, 9 Jul 2025 14:14:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Test8358592.java
>>   
>>   run on x86_64
>
> The fix looks reasonable to me but I'm not an expert in this code.

hi @TobiHartmann , Thanks a lot for the detailed review, i already update PR and please taking another look when you have time .
Also, since you mentioned you're not an expert in this area, would it make sense to ping someone more familiar?

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

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3055234729

From mbeckwit at openjdk.org  Thu Jul 10 04:31:07 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 04:31:07 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v2]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <twAWth8zQ8NAgXpKWm3JC7rQD_o5D8xPNbMgsPslMvM=.56a54075-31ab-4bbf-a0b9-1b3bb998a1a2@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 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.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge conflict corruption and restore time-based heap sizing changes
  
  - Restore g1CollectedHeap.cpp, g1CollectedHeap.hpp, g1HeapSizingPolicy.cpp from corrupted single-line format
  - Fix character encoding issue in g1HeapSizingPolicy.hpp (multiplication symbol)
  - All time-based heap sizing features restored and functional
  - Files are now in proper multi-line format and compilable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/a0bcdd58..650870a8

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

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

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

From darcy at openjdk.org  Thu Jul 10 04:54:37 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Jul 2025 04:54:37 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

What is the accuracy of the algorithm in ulps (units the last place)?

The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3055484802

From mbeckwit at openjdk.org  Thu Jul 10 06:29:07 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 06:29:07 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v3]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <jQjF13fT0WWNDhBfnS_YhriEQbJmosaLXzvoUlLGRpM=.bb14bde9-7301-4970-b6c9-b72f7d6b31ed@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 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.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge conflict corruption and restore time-based heap sizing changes
  
  - Restore g1CollectedHeap.cpp, g1CollectedHeap.hpp, g1HeapSizingPolicy.cpp from corrupted single-line format
  - Fix character encoding issue in g1HeapSizingPolicy.hpp (multiplication symbol)
  - All time-based heap sizing features restored and functional
  - Files are now in proper multi-line format and compilable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/650870a8..fc815905

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

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

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

From dholmes at openjdk.org  Thu Jul 10 07:23:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 07:23:40 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
Message-ID: <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>

On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
>> 
>> TBD: Need to submit a related CSR.
>> 
>> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>>  
>> Testing:
>>  - mach5 tiers 1-6 are good
>>  - may need to run mach5 tiers > 6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected one assert message

This involved a lot more code than I had envisaged.

The test situation seems problematic as it suggests to me that we have required functionality (redefine a method containing a lambda expression) that is not possible without the flag. And it seems this flag is also being used in the wild e.g.

https://blog.picnic.nl/embracing-java-17-heres-what-we-learned-69779d95fdf2

> As of Java 16, JDK internals are strongly encapsulated by default ([JEP 396](https://openjdk.java.net/jeps/396)). These and other changes mean that some dependencies now [require](https://github.com/reactor/BlockHound/issues/33) additional JVM flags such as --add-opens and -XX:+AllowRedefinitionToAddDeleteMethods to function properly. We updated our shared build system such that teams can configure these flags in a single place, ensuring that test and production runtimes remain in sync.

With more info in https://github.com/reactor/BlockHound/issues/33

So I am quite concerned that this "workaround" has become entrenched.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053:

> 4051: }
> 4052: 
> 4053: void VM_RedefineClasses::compute_matching_methods() {

I can't see that this method actually still does anything useful. ??

src/hotspot/share/runtime/arguments.cpp line 525:

> 523:   // -------------- Deprecated Flags --------------
> 524:   // --- Non-alias flags - sorted by obsolete_in then expired_in:
> 525:   { "AllowRedefinitionToAddDeleteMethods", JDK_Version::jdk(13), JDK_Version::jdk(26), JDK_Version::jdk(27) },

Please move this line to before line 535 (ParallelRefProcEnabled) so that we are sorted on obsolete_in as required.

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

PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3004272187
PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196808392
PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196813023

From mbeckwit at openjdk.org  Thu Jul 10 07:33:33 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 07:33:33 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v4]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <wlwSmc9NeegMOd2F8F5eMgkHCO-QWnwCb_7MM7SS12g=.5131c59d-9eaf-4771-b7bf-8f4df60416b3@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 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.

Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision:

 - Normalize G1 C++ sources as text (LF eol)
 - Normalize C/C++ sources as text with LF eol

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/fc815905..d096e624

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

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

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

From dholmes at openjdk.org  Thu Jul 10 07:48:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 07:48:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <GOklkOloAZix0yHT_OO12vanoQWj1bSMAHYN3JGyxMI=.669acf40-2535-4f00-9318-1bfa31efa770@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
 <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
 <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>
 <A11anQUaMdwDAJ1-5VNTiPqlSTciQ0RhXerz_FwmYp8=.fc5ffb07-3b3e-497e-9c7f-f3f42daed00b@github.com>
 <GOklkOloAZix0yHT_OO12vanoQWj1bSMAHYN3JGyxMI=.669acf40-2535-4f00-9318-1bfa31efa770@github.com>
Message-ID: <MoJAh-CPstZSaOZJl3ttqeMpzDR0VOjIoimsFWAlCfM=.59b9e1ac-de96-42b0-987d-c95915ee96fb@github.com>

On Wed, 9 Jul 2025 20:35:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Actually I think we need a further check here. If we get the carrier thread directly, we have not checked that it is actually protected by the TLH - that is normally done by `cv_internal_thread_to_JavaThread` but that doesn't know about virtual threads and carriers! I need to check if we have to fix `cv_internal_thread_to_JavaThread` for the virtual thread case.
>
> Well, we don't have TLH protection for carrier (and looks like JVMTI also doesn't care about carrier protection).
> I think it may be useful to add virtual thread support to `ThreadsListHandle` (and update comments in threadSMR.hpp).
> What about:
> 
>   bool cv_internal_thread_to_JavaThread(jobject jthread, JavaThread ** jt_pp, oop * thread_oop_p);
> 
> +  bool cv_oop_to_JavaThread(oop thread_oop, JavaThread** jt_pp);
> +  bool cv_thread_or_carrier_to_JavaThread(oop thread_oop, JavaThread** jt_pp, bool* is_virtual_p = nullptr);
> 
> Also we need a way to check if specific vthread is mounted to JavaThread (to be checked in handshake), I think it should go to javaThread.hpp/.cpp:
> 
> 
>   inline bool is_vthread_mounted() const;
> +  inline bool is_vthread_mounted(oop vthread) const;
> 
> What do you think?
> Would be nice to hear @dcubed-ojdk opinion (AFAIK he implemented threadSMR stuff)

I was thinking simply(?) to change `cv_internal_thread_to_JavaThread` so that it extracts the carrier for a vthread and checks it is within the given threads-list.

> Also we need a way to check if specific vthread is mounted to JavaThread (to be checked in handshake)

Not sure that would be of general use as the answer could change the instant you return from the operation. Explicit checks for being mounted are done within the handshake/safepoint op code as needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2196884985

From mbeckwit at openjdk.org  Thu Jul 10 07:53:33 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 07:53:33 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v5]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <8pZBz9567s3Yrf_AgBRmQTb0jvXnIgC8J8g4en3EoCQ=.371eb710-e04c-4c23-ab59-d37fd5ae177f@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 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.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8357445: Force GitHub to recognize G1 HotSpot files as text (temporary comment)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/d096e624..9e623d1b

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

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

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

From sspitsyn at openjdk.org  Thu Jul 10 08:05:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 08:05:54 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v5]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <LS-ETzGOLfeF-JWCvdsaB6OzcrJD_BiGrHuxUNG5UHk=.735a4b14-451c-44f5-a78d-c71df2a50c1a@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI spec sections:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
>   - `GetLocal<Type>`
>   - `SetLocal<Type>`
>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>   
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: corrected OPAQUE_FRAME clarification for NotifyFramePop function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/da3f20a8..4f1d4170

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

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

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

From sspitsyn at openjdk.org  Thu Jul 10 08:10:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 08:10:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v3]
In-Reply-To: <Ly9B4W6DKlEZVLH5lHD_AHkXcROFosnjMqcndMo1OUg=.9db0ef19-7ecd-47ed-99d5-63bc1c250268@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com>
 <HHaHGEEqJGdqhEKjW7QS5HVGYCTuDKDXjIQEgHtvAGA=.c3df70cd-b19c-4438-ac53-26fa0721e5d1@github.com>
 <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com>
 <f7CaGrceSQb4UrP6y0dkm1rxYP9eLtnFuq8r-_fouBc=.07e81d38-c47e-4d70-8cc9-0a115269e0fa@github.com>
 <Ly9B4W6DKlEZVLH5lHD_AHkXcROFosnjMqcndMo1OUg=.9db0ef19-7ecd-47ed-99d5-63bc1c250268@github.com>
Message-ID: <cf3o8mFJYJcEBNb84zOJ0k8xuHm5etYTmsO31MDY_Fc=.88593552-6504-4965-bdcf-3a8879ac3722@github.com>

On Thu, 10 Jul 2025 00:15:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Chris, please, let me know if it is okay to keep this at is or you still want an update for the `NotifyFramePop`.
>
> I understand what you are saying about the comparison to SetBreakpoint and that SetFramePop would have been a better name, but I don't see what this with the description. I said "set a FramePop event" doesn't sound right. Neither would "set a Breakpoint event". Also, the analogy with breakpoints doesn't really work when you consider that "a breakpoint" is meaningful, but "a FrampPop" does not.
> 
> A breakpoint is a location in the code where a breakpoint event will be triggered when executed. That analogy doesn't really work with FramePop. We don't have a word similar to breakpoint that means "a frame marked for generating a FramePop event when popped".

Okay, thanks. I've updated the `NotifyFramePop` spec as you suggested:
 ```A FramePop event cannot be generated for this frame```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2196933575

From sspitsyn at openjdk.org  Thu Jul 10 08:24:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Jul 2025 08:24:56 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI spec sections:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
>   - `GetLocal<Type>`
>   - `SetLocal<Type>`
>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>   
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: minor tweak of previous change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/4f1d4170..170fe280

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

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

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

From mbeckwit at openjdk.org  Thu Jul 10 08:26:39 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 08:26:39 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v6]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <mdxuElAZtaLQWBICLEc6u-2Sx16eU-1HFEL_hXN2goU=.55c7bff3-d6f9-46b3-a84a-2169a20956c1@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 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.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Reencode G1 C++ files as text (LF endings)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/9e623d1b..76f9ce19

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

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

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

From shade at openjdk.org  Thu Jul 10 08:38:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 08:38:39 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
In-Reply-To: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
Message-ID: <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>

On Thu, 10 Jul 2025 02:37:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.

src/hotspot/share/oops/trainingData.cpp line 437:

> 435: KlassTrainingData::KlassTrainingData(InstanceKlass* klass) : TrainingData(klass) {
> 436:   assert(klass != nullptr, "");
> 437:   oop* handle = oop_storage()->allocate();

I don't think you are supposed to allocate from `OopStorage` directly, that's the job for various `Handle`-s. Also, capturing the `java_mirror` does not really block the unloading, see:


// Loading the java_mirror does not keep its holder alive. See Klass::keep_alive().
inline oop Klass::java_mirror() const {
  return _java_mirror.resolve();
}


So the idiomatic way would be:


_holder_mirror = OopHandle(Universe::vm_global(), klass->klass_holder());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2196997605

From mbeckwit at openjdk.org  Thu Jul 10 09:08:13 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 09:08:13 GMT
Subject: RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
 [v7]
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <x9FCZjjzuv_WdZqpIebsG8SpfUfeuonHNnw1spVtmJI=.f32c995c-f973-4081-8abc-070c1db7dbfb@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 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.

Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:

  Normalize g1CollectedHeap.cpp as text (LF endings)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26207/files
  - new: https://git.openjdk.org/jdk/pull/26207/files/76f9ce19..ca30e3da

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

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

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

From duke at openjdk.org  Thu Jul 10 09:42:42 2025
From: duke at openjdk.org (Samuel Chee)
Date: Thu, 10 Jul 2025 09:42:42 GMT
Subject: RFR: 8356556: AArch64: No need for acquire fence in safepoint poll
 in FFM
In-Reply-To: <fw66m6cnpV49SFy1jHf0XRu9HFaHUpvd6F5hKU8Q30w=.23839a2b-5527-44da-8855-d0e3de345c20@github.com>
References: <fw66m6cnpV49SFy1jHf0XRu9HFaHUpvd6F5hKU8Q30w=.23839a2b-5527-44da-8855-d0e3de345c20@github.com>
Message-ID: <46fXNzAzmkhFl0hxeMPosZdN4yUBYJ_pRq-VqzJV_nA=.bb5f0d8c-ff2d-477f-ab25-d1ee628ec8de@github.com>

On Tue, 13 May 2025 12:53:56 GMT, Samuel Chee <duke at openjdk.org> wrote:

> Removes the unnecessary acquire to reduce memory ordering requirement since it is not longer needed as threads always disarm their own poll value.

What seems to have happened, is that:

1. I created this GitHub PR and someone else created the corresponding JBS ticket since I don't have the ability to do so.
2. This PR and the JBS ticket didn't automatically link together due to my lack of OCA access.
3. In the time it took for to get my OCA access (1.5 months), someone else saw the unassigned, unresolved JBS ticket, did it themselves and got it upstreamed before I ever got my OCA access.
4. I got my OCA access and realised what just happened.

What should happen now? Should I just close this PR?

And is there something both sides can do to prevent this from happening again? Since its work which has almost identically unnecessarily been done twice.

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

PR Comment: https://git.openjdk.org/jdk/pull/25211#issuecomment-3056598584

From fweimer at openjdk.org  Thu Jul 10 10:07:38 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Thu, 10 Jul 2025 10:07:38 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
 <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
Message-ID: <pjgNDrlkQfhfDwybzk2t0HJ2pTBNIDKmWNjt7jVOi9A=.a757ed01-fb48-4f25-ac6d-828cccb4c723@github.com>

On Mon, 7 Jul 2025 23:53:14 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify?

I didn't notice the code you ported over from the Intel math library at first. I assumed ?libm? referred to the system libm version.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3056706410

From mbeckwit at openjdk.org  Thu Jul 10 10:20:49 2025
From: mbeckwit at openjdk.org (Monica Beckwith)
Date: Thu, 10 Jul 2025 10:20:49 GMT
Subject: Withdrawn: 8357445: G1: Time-Based Heap Uncommit During Idle Periods
In-Reply-To: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
References: <dfzdZmtWD-15oSNl0vsKehyFy7nWcRMY26XQspYssAA=.07814e6b-67c4-4d81-ae10-8a6ea2348842@github.com>
Message-ID: <p3fyh1A1JfU-E_UipjpLlV1if9tcpHWKglrn2ORZn0I=.e6833c94-7e2b-45dc-9e4e-04f4b1114540@github.com>

On Wed, 9 Jul 2025 02:29:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> **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 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.

This pull request has been closed without being integrated.

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

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

From adinn at openjdk.org  Thu Jul 10 10:25:48 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 10:25:48 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
 <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
Message-ID: <qKnuCEcyHb3zzINIQP2jKY48_9bVKKd8R-CGwI_2Nvk=.c1dfa2bd-0e9c-47a2-a351-302ac90ccfd0@github.com>

On Thu, 10 Jul 2025 00:08:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> After this integration we are seeing crashes on Linux x64 and Aarch64:
>   assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

@dholmes-ora Can you provide more detail as to what is failing? Is this a specific build?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3056788682

From adinn at openjdk.org  Thu Jul 10 11:18:51 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 11:18:51 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
 <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
Message-ID: <PviQrtw5U9m9jo5im2NRmz7yLeyRBlP2qhwOTRMxOQ4=.7dfb25e9-3784-482e-9f83-119841a599ae@github.com>

On Thu, 10 Jul 2025 00:08:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>>  - add missing C++ method to AOT cache address table
>
> After this integration we are seeing crashes on Linux x64 and Aarch64:
> 
> assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

@dholmes-ora It's ok I have identified what is going wrong.

The problem appears to occur when either C1 or C2 is omitted from the build. I have raised [JDK-8361844](https://bugs.openjdk.org/browse/JDK-8361844) and have a PR ready which I am checking against tier1 (with a build that omits C2).

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3057005534

From coleenp at openjdk.org  Thu Jul 10 11:54:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Jul 2025 11:54:39 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
In-Reply-To: <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>
Message-ID: <Y1eEjk5oMTmx-5JFAGtLHHXAeWflGz_I6cnp2pxk0Yk=.022e4750-3d86-4cd9-8822-f90c234982ba@github.com>

On Thu, 10 Jul 2025 08:35:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.
>
> src/hotspot/share/oops/trainingData.cpp line 437:
> 
>> 435: KlassTrainingData::KlassTrainingData(InstanceKlass* klass) : TrainingData(klass) {
>> 436:   assert(klass != nullptr, "");
>> 437:   oop* handle = oop_storage()->allocate();
> 
> I don't think you are supposed to allocate from `OopStorage` directly, that's the job for various `Handle`-s. Also, capturing the `java_mirror` does not really block the unloading, see:
> 
> 
> // Loading the java_mirror does not keep its holder alive. See Klass::keep_alive().
> inline oop Klass::java_mirror() const {
>   return _java_mirror.resolve();
> }
> 
> 
> So the idiomatic way would be:
> 
> 
> _holder_mirror = OopHandle(Universe::vm_global(), klass->klass_holder());

What a confusing comment, but luckily it points to Klass::keep_alive() for context.  Yes, please don't allocate an OopStorage handle directly.  Then the OopHandle constructor will check for native oom.

Otherwise this seems okay and better than using jni.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2197505170

From adinn at openjdk.org  Thu Jul 10 12:16:50 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 12:16:50 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707
Message-ID: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>

After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:

    assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.

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

Commit messages:
 - fix issue after 8360707 when C1 or C2 omitted

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

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

From thartmann at openjdk.org  Thu Jul 10 12:25:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Jul 2025 12:25:45 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707
In-Reply-To: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
Message-ID: <_-851d5djM-cdr0Aqexd0zzwJVqSVRqEOETELR3jXpw=.341f4ee8-5efe-4cb4-ba63-04812316ecb2@github.com>

On Thu, 10 Jul 2025 12:11:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
> 
>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
> 
> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.

Is this a duplicate of [JDK-8361745](https://bugs.openjdk.org/browse/JDK-8361745)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26242#issuecomment-3057225117

From adinn at openjdk.org  Thu Jul 10 12:38:55 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 12:38:55 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707 [v2]
In-Reply-To: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
Message-ID: <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>

> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
> 
>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
> 
> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.

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

  check for empty stub groups when dumping stub tables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26242/files
  - new: https://git.openjdk.org/jdk/pull/26242/files/b282a3ce..3b95f93a

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

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

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

From adinn at openjdk.org  Thu Jul 10 12:43:39 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 12:43:39 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707
In-Reply-To: <_-851d5djM-cdr0Aqexd0zzwJVqSVRqEOETELR3jXpw=.341f4ee8-5efe-4cb4-ba63-04812316ecb2@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
 <_-851d5djM-cdr0Aqexd0zzwJVqSVRqEOETELR3jXpw=.341f4ee8-5efe-4cb4-ba63-04812316ecb2@github.com>
Message-ID: <zirpCHW2mEt9Nh-Iha-MysrE8NLO4Cxx16DyKJkXWBk=.464f982c-cee7-4014-94a9-7b77c90e1e89@github.com>

On Thu, 10 Jul 2025 12:22:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
>> 
>>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
>> 
>> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.
>
> Is this a duplicate of [JDK-8361745](https://bugs.openjdk.org/browse/JDK-8361745)?

@TobiHartmann Yes, it appears to be.

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

PR Comment: https://git.openjdk.org/jdk/pull/26242#issuecomment-3057293069

From liach at openjdk.org  Thu Jul 10 12:58:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> 
> 2. Comp...

src/java.base/share/classes/java/lang/StringCoding.java line 93:

> 91:     public static int countPositives(byte[] ba, int off, int len) {
> 92:         Objects.requireNonNull(ba, "ba");
> 93:         Objects.checkFromIndexSize(off, len, ba.length);

I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2169545990

From vyazici at openjdk.org  Thu Jul 10 12:58:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:54 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> 
> 2. Comp...

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

> 961: 
> 962:   if (bailout->req() > 1) {
> 963:     if (halt) {

Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.

src/java.base/share/classes/java/lang/StringCoding.java line 140:

> 138:      *
> 139:      * @param sa the source byte array containing characters encoded in UTF-16
> 140:      * @param sp the index of the <em>byte (not character!)</em> from the source array to start reading from

Note the `byte (not character!)` emphasis here and below.

src/java.base/share/classes/java/lang/StringCoding.java line 150:

> 148:      */
> 149:     static int encodeISOArray(byte[] sa, int sp, byte[] da, int dp, int len) {
> 150:         checkFromIndexSize(sp, len << 1, requireNonNull(sa, "sa").length, AIOOBE_FORMATTER);

`sa` contains 2-byte `char`s, and `sp` points to an index of this inflated array. Though, `len` denotes the codepoint count, hence the `len << 1` while checking `sp` and `len` bounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197576759
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197566783
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197572078

From duke at openjdk.org  Thu Jul 10 12:58:56 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
>> 
>> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.
>
> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

Maybe?use `jdk.internal.util.Preconditions` directly?instead?
Suggestion:

        Preconditions.checkFromIndexSize(off, len, ba.length, null);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172823303

From liach at openjdk.org  Thu Jul 10 12:58:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
Message-ID: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>

On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringCoding.java line 93:
>> 
>>> 91:     public static int countPositives(byte[] ba, int off, int len) {
>>> 92:         Objects.requireNonNull(ba, "ba");
>>> 93:         Objects.checkFromIndexSize(off, len, ba.length);
>> 
>> I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401
>
> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
> 
> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.

My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172044145

From vyazici at openjdk.org  Thu Jul 10 12:58:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:53 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
Message-ID: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>

Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input.

## Implementation notes

The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,

1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag

Following preliminary work needs to be carried out as well:

1. Add a new `VerifyIntrinsicChecks` VM flag
2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.

<sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.

## Functional and performance tests

- `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.

- Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.

## Verification of the VM crash

I've tested the VM crash scenario as follows:

1. Created the following test program:

public class StrIntri {
    public static void main(String[] args) {
        Exception lastException = null;
        for (int i = 0; i < 1_000_000; i++) {
            try {
                jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
            } catch (Exception exception) {
                lastException = exception;
            }
        }
        if (lastException != null) {
            lastException.printStackTrace();
        } else {
            System.out.println("completed");
        }
    }
}

2. Compiled the JDK and run the test:

$ bash jib.sh configure -p linux-x64-slowdebug
$ CONF=linux-x64-slowdebug make jdk
$ ./build/linux-x64-slowdebug/jdk/bin/java -XX:+VerifyIntrinsicChecks --add-exports java.base/jdk.internal.access=ALL-UNNAMED StrIntri.java
java.lang.ArrayIndexOutOfBoundsException: Range [2, 2 + 5) out of bounds for length 3

Received `AIOOBE` as expected.

3. Removed all checks in `StringCodec.java`, and re-compiled the JDK
4. Set the `countPositives(...)` arguments in the program to `(null, 1, 1)`, run it, and observed the VM crash with `unexpected null in intrinsic`.
5. Set the `countPositives(...)` arguments in the program to `(new byte[]{1,2,3}, 2, 5)`, run it, and observed the VM crash with `unexpected guard failure in intrinsic`.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
 - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
 - Improve intrinsics in `StringCoding`
 - Add `StringCodingCountPositives` benchmark
 - Apply review feedback
 - Move `StringCoding::countPositives` checks from C++ to Java

Changes: https://git.openjdk.org/jdk/pull/25998/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361842
  Stats: 271 lines in 18 files changed: 157 ins; 19 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

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

From vyazici at openjdk.org  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
Message-ID: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>

On Fri, 27 Jun 2025 20:21:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.
>
> Maybe?use `jdk.internal.util.Preconditions` directly?instead?
> Suggestion:
> 
>         Preconditions.checkFromIndexSize(off, len, ba.length, null);

@ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185587428

From thartmann at openjdk.org  Thu Jul 10 12:58:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Jul 2025 12:58:55 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
Message-ID: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>

On Thu, 26 Jun 2025 17:26:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace();
>>   ...
>
> src/java.base/share/classes/java/lang/StringCoding.java line 93:
> 
>> 91:     public static int countPositives(byte[] ba, int off, int len) {
>> 92:         Objects.requireNonNull(ba, "ba");
>> 93:         Objects.checkFromIndexSize(off, len, ba.length);
> 
> I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401

But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`

This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2170997677

From vyazici at openjdk.org  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
 <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
Message-ID: <WSlx76BipS-RhuSlJyR8jV_uiWs5_ZJ5PrxD8toqhaw=.44efab1a-c960-4b56-90b1-a0af0e64c5bd@github.com>

On Fri, 4 Jul 2025 15:03:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Maybe?use `jdk.internal.util.Preconditions` directly?instead?
>> Suggestion:
>> 
>>         Preconditions.checkFromIndexSize(off, len, ba.length, null);
>
> @ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed.

Doh! I've just noticed `Objects::checkFromIndexSize` throws `IndexOutOfBoundsException`, though we need `ArrayIndexOutOfBoundsException`. `Objects::checkFromIndexSize` doesn't accept an exception supplier, replacing it with `Preconditions::checkFromIndexSize`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185930404

From vyazici at openjdk.org  Thu Jul 10 12:58:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Jul 2025 12:58:56 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bAdxgImspJYrluIITQe3keO4y7QC4SRR_pO-dWvcdFk=.a4d45d2f-bffa-4762-be24-868901cad785@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative`
>> 
>> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.
>
> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression.

@liach, thanks for sharing your feedback on this draft, much appreciated. ? In order to address your (rightful) concerns (which I also share) regarding the performance impact, in 196fc5d, I've added `StringCodingCountPositives` JMH benchmark and produced the following results:

*OS:* Ubuntu 24.04.2
*CPU:* Intel Core Ultra 9 185H x 22


Mode  Cnt  Score   Error  Units
avgt   10  8.617 ? 0.646  ns/op          # 149882416a9 (strIntrinCheck)
avgt   10  8.787 ? 0.313  ns/op          # 5a1301df195 (master)


AFAICT, (even though the patched version appears to be performing better ?) the scores do match. Note that I will run the entire `test/micro/org/openjdk/bench/java/lang/String*.java` suite on various platforms and make sure there are no (visible?) performance regressions, before promoting this draft to a PR.

Let me know if this addresses your concerns and if there is anything else I can do to better assess the performance impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185582087

From tschatzl at openjdk.org  Thu Jul 10 13:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 13:03:47 GMT
Subject: RFR: 8361693: Remove Klass::clean_subklass_tree()
In-Reply-To: <YkFzDEnuoMYsgFP19XmBhYxpsLmcn-Bfoy8G5A5rd2c=.f891a0a1-c3b9-43b1-8385-b4ef6f0131f5@github.com>
References: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
 <YkFzDEnuoMYsgFP19XmBhYxpsLmcn-Bfoy8G5A5rd2c=.f891a0a1-c3b9-43b1-8385-b4ef6f0131f5@github.com>
Message-ID: <UOr5ujRcyCLtaU0DjW-bh8asw33Kvdk3mGBV7GWDHv8=.b5ae72a3-12f1-4bed-934a-6622ca8aba92@github.com>

On Wed, 9 Jul 2025 15:18:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this inlining of Klass::clean_subklass_tree because it's only used in one place and replaces only one call. There does not seem to be any advantage having the extra method.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> LGTM

Thanks @zhengyu123 @kimbarrett for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26220#issuecomment-3057353435

From tschatzl at openjdk.org  Thu Jul 10 13:03:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Jul 2025 13:03:48 GMT
Subject: Integrated: 8361693: Remove Klass::clean_subklass_tree()
In-Reply-To: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
References: <U9a_gfAq55uGZCba0YfyMNJ5laEY0wlhEIaJRTXinXM=.700f7ab0-861d-4cac-861a-023ce9db0b43@github.com>
Message-ID: <T2wzuT5boesi6RXd__QzFe_rfo1xz8-2wr-M4CNz0wQ=.0755680f-615e-4be3-9f3f-c9c0fd1fc1a0@github.com>

On Wed, 9 Jul 2025 14:08:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this inlining of Klass::clean_subklass_tree because it's only used in one place and replaces only one call. There does not seem to be any advantage having the extra method.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 3d37c4e3
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d37c4e37ac6e3fb7915de46ed98136453b8840a
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

8361693: Remove Klass::clean_subklass_tree()

Reviewed-by: zgu, kbarrett

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

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

From adinn at openjdk.org  Thu Jul 10 13:27:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 13:27:40 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707 [v2]
In-Reply-To: <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
 <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
Message-ID: <EKRQT4CV7fDz8RQ5HDIMpqmxpYhZsvYZ6exvcKFCEiM=.25d3884f-e6ec-4d22-8d74-0f3e51db39fd@github.com>

On Thu, 10 Jul 2025 12:38:55 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
>> 
>>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
>> 
>> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for empty stub groups when dumping stub tables

Testing:

Built zero, image omitting c1 and image omitting c2 with this patch.

Ran tier1 tests in a C2-only build and they succeeded except for the following cases which look like they require both C1 and C2 to work as expected:

compiler.codecache.MHIntrinsicAllocFailureTest (threw NPE calling MemoryPoolMXBean.getUsage())
runtime/ErrorHandling/StackWalkNativeToJava.java (Count error: count was 1)
compiler/c2/irTests/ProfileAtTypeCheck.java (invalid IR -- enables TieredCompilation)
compiler/c2/irTests/TestLongRangeChecks.java (ditto)
compiler/c2/irTests/TestPrunedExHandler.java (ditto)
compiler/types/TestMeetIncompatibleInterfaceArrays.java (ditto)
jdk/test/lib/TestPlatformIsTieredSupported.java (it's not!)

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

PR Comment: https://git.openjdk.org/jdk/pull/26242#issuecomment-3057454334

From missa at openjdk.org  Thu Jul 10 14:33:40 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 10 Jul 2025 14:33:40 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
Message-ID: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>

On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> What is the accuracy of the algorithm in ulps (units the last place)?
> 
> The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.

0.51 ulps

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3057699676

From iveresov at openjdk.org  Thu Jul 10 14:45:38 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 10 Jul 2025 14:45:38 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
In-Reply-To: <Y1eEjk5oMTmx-5JFAGtLHHXAeWflGz_I6cnp2pxk0Yk=.022e4750-3d86-4cd9-8822-f90c234982ba@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>
 <Y1eEjk5oMTmx-5JFAGtLHHXAeWflGz_I6cnp2pxk0Yk=.022e4750-3d86-4cd9-8822-f90c234982ba@github.com>
Message-ID: <5j7Yko4SxyZxJkDlO9itXMmbLK9W7Mz4b0IYQMplNKA=.3aace3f2-7233-4c5f-8b85-2f4d3b9458fa@github.com>

On Thu, 10 Jul 2025 11:51:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/trainingData.cpp line 437:
>> 
>>> 435: KlassTrainingData::KlassTrainingData(InstanceKlass* klass) : TrainingData(klass) {
>>> 436:   assert(klass != nullptr, "");
>>> 437:   oop* handle = oop_storage()->allocate();
>> 
>> I don't think you are supposed to allocate from `OopStorage` directly, that's the job for various `Handle`-s. Also, capturing the `java_mirror` does not really block the unloading, see:
>> 
>> 
>> // Loading the java_mirror does not keep its holder alive. See Klass::keep_alive().
>> inline oop Klass::java_mirror() const {
>>   return _java_mirror.resolve();
>> }
>> 
>> 
>> So the idiomatic way would be:
>> 
>> 
>> _holder_mirror = OopHandle(Universe::vm_global(), klass->klass_holder());
>
> What a confusing comment, but luckily it points to Klass::keep_alive() for context.  Yes, please don't allocate an OopStorage handle directly.  Then the OopHandle constructor will check for native oom.
> 
> Otherwise this seems okay and better than using jni.

@coleenp I kind of like the fact that I can get rid of a field in KTD that previously stored a handle. Perhaps that benefit justifies a direct allocation?

@shipilev I don't understand your comment about loading the mirror. I'm not merely loading it, I'm registering it as a root. It is also all happening in a safepoint-free context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2197939820

From matthias.baesken at sap.com  Thu Jul 10 15:23:48 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 10 Jul 2025 15:23:48 +0000
Subject: hotspot jtreg tests take  WARNING_CFLAGS_JDK_CONLY  flags
Message-ID: <AM9PR02MB6770334B693A05E91D313E619348A@AM9PR02MB6770.eurprd02.prod.outlook.com>

When  trying the GCC static analyzer (-fanalyzer flag)


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index e80d9a98957..9d1ae60047b 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -610,7 +610,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
   # CFLAGS WARNINGS STUFF
   # Set JVM_CFLAGS warning handling
   if test "x$TOOLCHAIN_TYPE" = xgcc; then
-    WARNING_CFLAGS_JDK_CONLY="$WARNINGS_ENABLE_ALL_CFLAGS"
+    # enable -fanalyzer (but better only for gcc12 + , and also only for C)
+    # too many strange / shaky fd leak warnings
+    WARNING_CFLAGS_JDK_CONLY="-fanalyzer -Wno-analyzer-fd-leak $WARNINGS_ENABLE_ALL_CFLAGS"
     WARNING_CFLAGS_JDK_CXXONLY="$WARNINGS_ENABLE_ALL_CXXFLAGS"
     WARNING_CFLAGS_JVM="$WARNINGS_ENABLE_ALL_CXXFLAGS"

I noticed that the   WARNING_CFLAGS_JDK_CONLY  go into the  hotspot   jtreg tests, e.g.  :


/jdk/test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h:46:6: error: dereference of NULL '0' [CWE-476] [-Werror=analyzer-null-dereference]
   46 |   *x = 34; // Crash
      |   ~~~^~~~
  'dereference_null': event 1
    |
    |   46 |   *x = 34; // Crash
    |      |   ~~~^~~~
    |      |      |
    |      |      (1) dereference of NULL '0'


This might be intended but   I was surprised that the HS  C tests take  WARNING_CFLAGS_JDK_CONLY    !?   Is this intended or not ?


Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250710/288285aa/attachment-0001.htm>

From cjplummer at openjdk.org  Thu Jul 10 15:45:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Jul 2025 15:45:45 GMT
Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR
 enabled due to unknown thread type JfrRecorderThread
In-Reply-To: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
References: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
Message-ID: <PBSyYA0wW4EDIsxNaC08N7RRME_4Z-Mbhxms7Ee8IFk=.fba8f6f7-5fce-4062-b308-eea0c105abba@github.com>

On Tue, 8 Jul 2025 17:57:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25.
> 
> Tier5 ci testing in progress.

Thank you for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/26198#issuecomment-3057984680

From cjplummer at openjdk.org  Thu Jul 10 15:45:46 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Jul 2025 15:45:46 GMT
Subject: [jdk25] Integrated: 8360312: Serviceability Agent tests fail with JFR
 enabled due to unknown thread type JfrRecorderThread
In-Reply-To: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
References: <Pkhl-DOJnaePFtoLpHEusULroLUOOJVRtpR64WtY2_Q=.cd386753-7e26-4972-abd9-265871908e0e@github.com>
Message-ID: <qAvjIIpg0TjrRjDYMsG_XNYI96Yzu_vpRY3XrfZc1Zo=.568bb596-ea03-4701-b844-13e06bca5956@github.com>

On Tue, 8 Jul 2025 17:57:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25.
> 
> Tier5 ci testing in progress.

This pull request has now been integrated.

Changeset: 96380509
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96380509b31a2dcc41bbba62ec316e1c569b13ab
Stats:     25 lines in 5 files changed: 13 ins; 9 del; 3 mod

8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread

Reviewed-by: kevinw, sspitsyn
Backport-of: 712d866b72b43c839c57c3303dfb215f94c0db3b

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

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

From coleenp at openjdk.org  Thu Jul 10 16:50:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Jul 2025 16:50:45 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
In-Reply-To: <5j7Yko4SxyZxJkDlO9itXMmbLK9W7Mz4b0IYQMplNKA=.3aace3f2-7233-4c5f-8b85-2f4d3b9458fa@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>
 <Y1eEjk5oMTmx-5JFAGtLHHXAeWflGz_I6cnp2pxk0Yk=.022e4750-3d86-4cd9-8822-f90c234982ba@github.com>
 <5j7Yko4SxyZxJkDlO9itXMmbLK9W7Mz4b0IYQMplNKA=.3aace3f2-7233-4c5f-8b85-2f4d3b9458fa@github.com>
Message-ID: <dPKa2lmdgLs4iRIGgrOaFX5beYEguhk2zIc0E3oUsbU=.e460116e-62ec-4f27-a35a-9dfe2ff4b40e@github.com>

On Thu, 10 Jul 2025 14:42:47 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> What a confusing comment, but luckily it points to Klass::keep_alive() for context.  Yes, please don't allocate an OopStorage handle directly.  Then the OopHandle constructor will check for native oom.
>> 
>> Otherwise this seems okay and better than using jni.
>
> @coleenp I kind of like the fact that I can get rid of a field in KTD that previously stored a handle. Perhaps that benefit justifies a direct allocation?
> 
> @shipilev I don't understand your comment about loading the mirror. I'm not merely loading it, I'm registering it as a root. It is also all happening in a safepoint-free context.

Then just have OopHandle handle = OopHandle(Universe::vm_global(), klass->klass_holder());

or similar.  You don't have to store it unless you're going to release it.  But footprint seems unimportant in this case.  Also, maybe OopStorage::allocate() should just be friends with OopHandle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2198233387

From iveresov at openjdk.org  Thu Jul 10 17:05:40 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 10 Jul 2025 17:05:40 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
In-Reply-To: <dPKa2lmdgLs4iRIGgrOaFX5beYEguhk2zIc0E3oUsbU=.e460116e-62ec-4f27-a35a-9dfe2ff4b40e@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <XxAzvoGpTwD8o76YcZ3IQDZeJja9iChPGbNHBO9DFus=.67130431-1a47-4f1b-bfb8-92791ffbc86a@github.com>
 <Y1eEjk5oMTmx-5JFAGtLHHXAeWflGz_I6cnp2pxk0Yk=.022e4750-3d86-4cd9-8822-f90c234982ba@github.com>
 <5j7Yko4SxyZxJkDlO9itXMmbLK9W7Mz4b0IYQMplNKA=.3aace3f2-7233-4c5f-8b85-2f4d3b9458fa@github.com>
 <dPKa2lmdgLs4iRIGgrOaFX5beYEguhk2zIc0E3oUsbU=.e460116e-62ec-4f27-a35a-9dfe2ff4b40e@github.com>
Message-ID: <geUeBm_0syNoi0FEA1sGl2fTUcTSnn7sYltXWRL_jSs=.4b8b460d-562c-45b6-9468-5fc2d6ed298a@github.com>

On Thu, 10 Jul 2025 16:48:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> @coleenp I kind of like the fact that I can get rid of a field in KTD that previously stored a handle. Perhaps that benefit justifies a direct allocation?
>> 
>> @shipilev I don't understand your comment about loading the mirror. I'm not merely loading it, I'm registering it as a root. It is also all happening in a safepoint-free context.
>
> Then just have OopHandle handle = OopHandle(Universe::vm_global(), klass->klass_holder());
> 
> or similar.  You don't have to store it unless you're going to release it.  But footprint seems unimportant in this case.  Also, maybe OopStorage::allocate() should just be friends with OopHandle.
> 
> Edit: looks like it's also used by string deduplication but this shouldn't call OopStorage::allocate directly.

Ah, sorry, I was somehow under the impression that OopHandle would have a destructor that release the handle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26233#discussion_r2198257057

From iveresov at openjdk.org  Thu Jul 10 17:10:22 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 10 Jul 2025 17:10:22 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
 [v2]
In-Reply-To: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
Message-ID: <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>

> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.

Igor Veresov 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/26233/files
  - new: https://git.openjdk.org/jdk/pull/26233/files/e262230b..80d33dab

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

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

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

From kvn at openjdk.org  Thu Jul 10 17:13:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Jul 2025 17:13:39 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707 [v2]
In-Reply-To: <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
 <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
Message-ID: <CXmZftjsyVbX3GEIzvbPEZQiYWPAV6qUauq4DFaHo1Y=.b15bd856-1c5a-476d-978a-5691e88d9527@github.com>

On Thu, 10 Jul 2025 12:38:55 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
>> 
>>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
>> 
>> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for empty stub groups when dumping stub tables

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26242#pullrequestreview-3006596417

From coleenp at openjdk.org  Thu Jul 10 17:14:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Jul 2025 17:14:38 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
 [v2]
In-Reply-To: <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
Message-ID: <fb2wxTpA_COkhOxdRoMVyFxHLHyUN9zEg_a-npY3FoA=.01362f26-45c3-4a5b-9f58-2e142896c379@github.com>

On Thu, 10 Jul 2025 17:10:22 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good. thanks for the comment.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26233#pullrequestreview-3006599873

From adinn at openjdk.org  Thu Jul 10 17:25:44 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 17:25:44 GMT
Subject: Integrated: 8361844: Build without C1 or C2 fails after 8360707
In-Reply-To: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
Message-ID: <0skB42z6C1s8jCdeIxLYGllAseQsj0FAaQSsUFkt9M0=.ac00a7c0-8c00-40ec-b32b-205f689fb909@github.com>

On Thu, 10 Jul 2025 12:11:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
> 
>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
> 
> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.

This pull request has now been integrated.

Changeset: 3d74cbe0
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d74cbe0ac9b68dfc161a4c079b695a320a0e133
Stats:     42 lines in 1 file changed: 30 ins; 0 del; 12 mod

8361844: Build without C1 or C2 fails after 8360707

Reviewed-by: kvn

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

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

From coleenp at openjdk.org  Thu Jul 10 17:33:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Jul 2025 17:33:39 GMT
Subject: [jdk25] RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
References: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
Message-ID: <5BbcGO-cBtrHqAWn_Bkh_2bVOztvgm0P02U7Z7HHzhs=.e6f24cc0-0747-4463-87da-9af3b3873d3c@github.com>

On Thu, 10 Jul 2025 02:37:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f67e4354](https://github.com/openjdk/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 10 Jul 2025 and was reviewed by Martin Doerr, Thomas Stuefe and Coleen Phillimore.
> 
> There is a follow up fix to the test - JDK-8361754 - that will also be backported immediately after this is integrated.
> 
> Thanks!

Backport looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26234#pullrequestreview-3006651271

From jrose at openjdk.org  Thu Jul 10 20:56:38 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 10 Jul 2025 20:56:38 GMT
Subject: RFR: 8361842: Validate input in both Java and C++ for
 java.lang.StringCoding intrinsics
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> 
> 2. Comp...

I disagree with a small part of the statement of goals:

> Always validate all input at the intrinsic (but preferably behind a VM flag)

As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free.  Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic.  It?s too hard to verify by code review, and coverage testing is suspect.

We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors.  Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call).  Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic.

I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode.  This tells me that the extra optional testing is also not required to be 100%.

Thus, I think the above goal would be better stated this way:

> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation.

> Note:  IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw.

I think I'm agreeing with you on the material points.  It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3059044829

From cjplummer at openjdk.org  Thu Jul 10 21:19:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Jul 2025 21:19:41 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
Message-ID: <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>

On Thu, 10 Jul 2025 08:24:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI spec sections:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>>   - `GetLocal<Type>`
>>   - `SetLocal<Type>`
>>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>>   
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweak of previous change

src/hotspot/share/prims/jvmti.xml line 6233:

> 6231:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 6232:           The implementation is unable to set the frame locals
> 6233:           (e.g. the frame at <code>depth</code> is executing a native method).

The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2198754120

From darcy at openjdk.org  Thu Jul 10 21:26:37 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Jul 2025 21:26:37 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
 <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
Message-ID: <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>

On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> > What is the accuracy of the algorithm in ulps (units the last place)?
> > The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.
> 
> 0.51 ulps

Please add that as a comment to the changeset.

Also, if the worst-case inputs for this algorithm are known, they should the added as part of the core libraries regression tests for the math library.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3059152934

From amenkov at openjdk.org  Thu Jul 10 21:36:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 10 Jul 2025 21:36:53 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
Message-ID: <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>

> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
> 
> Testing: tier1..5

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  carrier in TLH

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26119/files
  - new: https://git.openjdk.org/jdk/pull/26119/files/04b2a383..58c4004e

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

  Stats: 60 lines in 3 files changed: 35 ins; 7 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/26119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119

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

From amenkov at openjdk.org  Thu Jul 10 21:36:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 10 Jul 2025 21:36:53 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v3]
In-Reply-To: <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <cjoAckLgDd7NTbv_oZOqjn3muiWFBzRn6wqieYfoCpY=.6b38d951-676b-4dea-a4e5-860ee1d88abf@github.com>
Message-ID: <qx7MqUVAj9y6IQdGPdzRblOYlaIRuKpWz0q54qUB4OE=.7077fc5e-f014-4b87-9636-c074b064debc@github.com>

On Mon, 7 Jul 2025 19:36:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comment

- added mounted vthread's carrier support to ThreadsListHandle
- renamed fields/variables in GetStackTraceHandshakeClosure
- removed obsolete comment about executeOnCarrierThread

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3059180430

From amenkov at openjdk.org  Thu Jul 10 21:40:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 10 Jul 2025 21:40:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v2]
In-Reply-To: <MoJAh-CPstZSaOZJl3ttqeMpzDR0VOjIoimsFWAlCfM=.59b9e1ac-de96-42b0-987d-c95915ee96fb@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <6PFMlvLTJTRDUr4Z2CiMgXYSsmi558E6ZNZ3JJK5lcU=.743882df-5ca1-4008-b3c3-88c00c4134ac@github.com>
 <QLzn-L8r4pqqvWgBGrs56IEt713WqWtCc02jw977mJQ=.138e4f55-8925-4115-b7d2-833f770f82f2@github.com>
 <aHrySPT6Wm5gAUYD3j9HhN_Mvem3wpWesg9AhiMuvwU=.5c3db26f-55e9-4dd9-9095-06c38a5366f3@github.com>
 <hAsXlvZ9DSMO-iPON_X0f7svt76PumPy5XzG1nPdRmo=.68000c13-51ca-41bd-8f09-bc78dddfa195@github.com>
 <A11anQUaMdwDAJ1-5VNTiPqlSTciQ0RhXerz_FwmYp8=.fc5ffb07-3b3e-497e-9c7f-f3f42daed00b@github.com>
 <GOklkOloAZix0yHT_OO12vanoQWj1bSMAHYN3JGyxMI=.669acf40-2535-4f00-9318-1bfa31efa770@github.com>
 <MoJAh-CPstZSaOZJl3ttqeMpzDR0VOjIoimsFWAlCfM=.59b9e1ac-de96-42b0-987d-c95915ee96fb@github.com>
Message-ID: <U__ntuMluRatQjcmvVCcgZ0kONoGsfe2iWoa3ZuIGE0=.4cb55c85-b0e6-4b6c-81a3-321929df191a@github.com>

On Thu, 10 Jul 2025 07:45:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I was thinking simply(?) to change `cv_internal_thread_to_JavaThread` so that it extracts the carrier for a vthread and checks it is within the given threads-list.

I prefer to keep the current behavior for existing callers to be sure they are not affected.
Added extra argument to `cv_internal_thread_to_JavaThread` to return carrrier's JavaThread.

> > Also we need a way to check if specific vthread is mounted to JavaThread (to be checked in handshake)
> 
> Not sure that would be of general use as the answer could change the instant you return from the operation. Explicit checks for being mounted are done within the handshake/safepoint op code as needed.

Ok, kept it as it is

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2198803351

From dholmes at openjdk.org  Thu Jul 10 22:17:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 22:17:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
Message-ID: <73NBrSzN1jXj3U8Rhuq0IECTEUhD-pxtx0QN0J43vms=.e6931f8e-fe8d-4dd0-8988-fabcb0dd188d@github.com>

On Thu, 10 Jul 2025 21:36:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   carrier in TLH

> Added extra argument to cv_internal_thread_to_JavaThread to return carrrier's JavaThread.

@alexmenkov  I think we need a separate JBS issue for this and have runtime fix it. I want to be sure we are fixing it in the right/best way. I don't think we need the extra argument, but need to examine the existing usages. Chances are that any code trying to deal with virtual thread's via the API is actually doing it wrong and will need fixing anyway. I will file a bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3059286832

From dholmes at openjdk.org  Thu Jul 10 22:34:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 22:34:41 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
Message-ID: <rN1cJDRhlCQIK-Zv9Yy6VyapruPXKBPzJbNaVS4pYsg=.356f32e5-f09a-447c-ab11-d49f0aea78e9@github.com>

On Thu, 10 Jul 2025 21:36:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   carrier in TLH

Filed [JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912)

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3059342348

From iveresov at openjdk.org  Thu Jul 10 22:41:39 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Thu, 10 Jul 2025 22:41:39 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
 [v2]
In-Reply-To: <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
Message-ID: <CmoG0srPVXtlToLDTtaaklsfGhE-5wPhXaiWS7Cbl7A=.4b583133-4bfa-41c4-9486-c6fd1c1ff6f8@github.com>

On Thu, 10 Jul 2025 17:10:22 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Testing is good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26233#issuecomment-3059360956

From dholmes at openjdk.org  Thu Jul 10 23:12:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 23:12:25 GMT
Subject: [jdk25] RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
References: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
Message-ID: <9dN1w7STx86oZmA-eWRPz7sJ3eS24Y3oFhOwVwWCHQA=.1bf1378e-1439-4618-a189-38127542c982@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [f67e4354](https://github.com/openjdk/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 10 Jul 2025 and was reviewed by Martin Doerr, Thomas Stuefe and Coleen Phillimore.
> 
> There is a follow up fix to the test - JDK-8361754 - that has been incorporated into this PR
> 
> Thanks!

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
  
  Reviewed-by: jpai, darcy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26234/files
  - new: https://git.openjdk.org/jdk/pull/26234/files/b3870f25..37caf98f

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

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

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

From amenkov at openjdk.org  Thu Jul 10 23:12:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 10 Jul 2025 23:12:40 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <73NBrSzN1jXj3U8Rhuq0IECTEUhD-pxtx0QN0J43vms=.e6931f8e-fe8d-4dd0-8988-fabcb0dd188d@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <73NBrSzN1jXj3U8Rhuq0IECTEUhD-pxtx0QN0J43vms=.e6931f8e-fe8d-4dd0-8988-fabcb0dd188d@github.com>
Message-ID: <MI8ogBvXZ59vx0WaSDMiMG_wZ-K9QKH9nzW5jsGZk14=.b57db105-56e8-4dcb-99de-e02622a63c9b@github.com>

On Thu, 10 Jul 2025 22:15:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Added extra argument to cv_internal_thread_to_JavaThread to return carrrier's JavaThread.
> 
> @alexmenkov I think we need a separate JBS issue for this and have runtime fix it. I want to be sure we are fixing it in the right/best way. I don't think we need the extra argument, but need to examine the existing usages. Chances are that any code trying to deal with virtual thread's via the API is actually doing it wrong and will need fixing anyway. I will file a bug.

I think just update the method to use carrier is error prone and callers should explicitly request the functionality.
I'm fine with separate issue, will remove changes in threadSMR.* and restore original handling of virtual thread carrier

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3059466886

From dholmes at openjdk.org  Thu Jul 10 23:21:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 23:21:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <MI8ogBvXZ59vx0WaSDMiMG_wZ-K9QKH9nzW5jsGZk14=.b57db105-56e8-4dcb-99de-e02622a63c9b@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <73NBrSzN1jXj3U8Rhuq0IECTEUhD-pxtx0QN0J43vms=.e6931f8e-fe8d-4dd0-8988-fabcb0dd188d@github.com>
 <MI8ogBvXZ59vx0WaSDMiMG_wZ-K9QKH9nzW5jsGZk14=.b57db105-56e8-4dcb-99de-e02622a63c9b@github.com>
Message-ID: <iirA0SinVDSawbqe6i_EVmn5avDDojxx-ZYTUC-22Ys=.2607d089-c121-49a5-b879-bfcce26103d8@github.com>

On Thu, 10 Jul 2025 23:10:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>>> Added extra argument to cv_internal_thread_to_JavaThread to return carrrier's JavaThread.
>> 
>> @alexmenkov  I think we need a separate JBS issue for this and have runtime fix it. I want to be sure we are fixing it in the right/best way. I don't think we need the extra argument, but need to examine the existing usages. Chances are that any code trying to deal with virtual thread's via the API is actually doing it wrong and will need fixing anyway. I will file a bug.
>
>> > Added extra argument to cv_internal_thread_to_JavaThread to return carrrier's JavaThread.
>> 
>> @alexmenkov I think we need a separate JBS issue for this and have runtime fix it. I want to be sure we are fixing it in the right/best way. I don't think we need the extra argument, but need to examine the existing usages. Chances are that any code trying to deal with virtual thread's via the API is actually doing it wrong and will need fixing anyway. I will file a bug.
> 
> I think just update the method to use carrier is error prone and callers should explicitly request the functionality.
> I'm fine with separate issue, will remove changes in threadSMR.* and restore original handling of virtual thread carrier

@alexmenkov  Alex, the form of this fix will be determined by whatever we end up doing for [JDK-8361912](https://bugs.openjdk.org/browse/JDK-8361912). I don't see any point in re-doing this fix later, so I suggest just putting this on hold for now. I will ensure the other issue is fixed within the next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3059489700

From dcubed at openjdk.org  Thu Jul 10 23:37:40 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 10 Jul 2025 23:37:40 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
Message-ID: <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>

On Thu, 10 Jul 2025 21:36:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   carrier in TLH

src/hotspot/share/runtime/threadSMR.cpp line 797:

> 795: // return JavaThread for the carrier thread; if the thread is unmounted
> 796: // or use_carrier is false, return false.
> 797: //

Right after the check on L827 below, what prevents the vthread from being unmounted?

So we fetch the JavaThread* on L833 and then verify that it is protected by the TLH
which is good, but that does not prevent the vthread from being unmounted by the
time that we return the JavaThread* on L853 below.

Am I missing something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2198998536

From coleenp at openjdk.org  Thu Jul 10 23:51:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Jul 2025 23:51:38 GMT
Subject: [jdk25] RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <9dN1w7STx86oZmA-eWRPz7sJ3eS24Y3oFhOwVwWCHQA=.1bf1378e-1439-4618-a189-38127542c982@github.com>
References: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
 <9dN1w7STx86oZmA-eWRPz7sJ3eS24Y3oFhOwVwWCHQA=.1bf1378e-1439-4618-a189-38127542c982@github.com>
Message-ID: <FNAEwjNwvVljihWDRNVDt8_l179i5aSoKMiE9fCLP28=.0926c7b5-377b-45e7-9029-2db572511d15@github.com>

On Thu, 10 Jul 2025 23:12:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [f67e4354](https://github.com/openjdk/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 10 Jul 2025 and was reviewed by Martin Doerr, Thomas Stuefe and Coleen Phillimore.
>> 
>> There is a follow up fix to the test - JDK-8361754 - that has been incorporated into this PR
>> 
>> Thanks!
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
>   
>   Reviewed-by: jpai, darcy

Ok, makes sense to backport both together.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26234#pullrequestreview-3007770996

From amenkov at openjdk.org  Fri Jul 11 00:16:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 11 Jul 2025 00:16:39 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
Message-ID: <Qt2V00MN5EKhuT4y-C3E5lu7sBpjJY8usjZWJt3UeSc=.fdb92ef0-c7a4-46a3-b113-a5040a015ba6@github.com>

On Thu, 10 Jul 2025 23:34:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   carrier in TLH
>
> src/hotspot/share/runtime/threadSMR.cpp line 797:
> 
>> 795: // return JavaThread for the carrier thread; if the thread is unmounted
>> 796: // or use_carrier is false, return false.
>> 797: //
> 
> Right after the check on L827 below, what prevents the vthread from being unmounted?
> 
> So we fetch the JavaThread* on L833 and then verify that it is protected by the TLH
> which is good, but that does not prevent the vthread from being unmounted by the
> time that we return the JavaThread* on L853 below.
> 
> Am I missing something?

Yes, that's right.
vthread can be unmounted at any moment. So it's caller responsibility to check is vthread is still mounted to the same carrier thread in handshake/VMOp (see comment about virtul threads in the threadSMR.hpp)
`VirtualThread.asyncGetStackTrace` retries to get stack trace in the case

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2199066506

From dholmes at openjdk.org  Fri Jul 11 00:22:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 00:22:41 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
Message-ID: <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>

On Thu, 10 Jul 2025 23:34:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   carrier in TLH
>
> src/hotspot/share/runtime/threadSMR.cpp line 797:
> 
>> 795: // return JavaThread for the carrier thread; if the thread is unmounted
>> 796: // or use_carrier is false, return false.
>> 797: //
> 
> Right after the check on L827 below, what prevents the vthread from being unmounted?
> 
> So we fetch the JavaThread* on L833 and then verify that it is protected by the TLH
> which is good, but that does not prevent the vthread from being unmounted by the
> time that we return the JavaThread* on L853 below.
> 
> Am I missing something?

@dcubed-ojdk No you are not missing anything, the vthread could become unmounted. It is up to the subsequent handshake code to re-check that (as briefly discussed above).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2199076367

From dholmes at openjdk.org  Fri Jul 11 00:24:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 00:24:47 GMT
Subject: [jdk25] RFR: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays [v2]
In-Reply-To: <FNAEwjNwvVljihWDRNVDt8_l179i5aSoKMiE9fCLP28=.0926c7b5-377b-45e7-9029-2db572511d15@github.com>
References: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
 <9dN1w7STx86oZmA-eWRPz7sJ3eS24Y3oFhOwVwWCHQA=.1bf1378e-1439-4618-a189-38127542c982@github.com>
 <FNAEwjNwvVljihWDRNVDt8_l179i5aSoKMiE9fCLP28=.0926c7b5-377b-45e7-9029-2db572511d15@github.com>
Message-ID: <Ma0vgHPFXpttzxAry8tyliPAURL3zp-hg3uVe92Qf9c=.eb5ea1aa-3173-40b6-85cc-f123298200d5@github.com>

On Thu, 10 Jul 2025 23:48:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
>>   
>>   Reviewed-by: jpai, darcy
>
> Ok, makes sense to backport both together.

Thanks @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/26234#issuecomment-3059680233

From dholmes at openjdk.org  Fri Jul 11 00:24:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 00:24:49 GMT
Subject: [jdk25] Integrated: 8361447: [REDO] Checked version of JNI
 Release<type>ArrayElements needs to filter out known wrapped arrays
In-Reply-To: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
References: <hKJQBrHXhd81a95oc24SP_Imf4qWRKQFOmflaqBaihs=.36573e79-0b41-48db-b187-6b15441f49b6@github.com>
Message-ID: <ZNXk1vd8VBJfU6NwgigXaurTni469rOhZYSvYPmEXPY=.22546881-83ab-4eb0-aa94-1d1f4ade15b2@github.com>

On Thu, 10 Jul 2025 02:37:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f67e4354](https://github.com/openjdk/jdk/commit/f67e4354316dcec185eac66adec2395e20b62579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 10 Jul 2025 and was reviewed by Martin Doerr, Thomas Stuefe and Coleen Phillimore.
> 
> There is a follow up fix to the test - JDK-8361754 - that has been incorporated into this PR
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9adc480e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9adc480ec3b67ca0dca6ae6c49774c28eae46ded
Stats:     350 lines in 6 files changed: 324 ins; 6 del; 20 mod

8361447: [REDO] Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays
8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors

Reviewed-by: coleenp
Backport-of: f67e4354316dcec185eac66adec2395e20b62579

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

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

From dholmes at openjdk.org  Fri Jul 11 02:11:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 02:11:51 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
Message-ID: <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>

On Fri, 11 Jul 2025 00:19:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.cpp line 797:
>> 
>>> 795: // return JavaThread for the carrier thread; if the thread is unmounted
>>> 796: // or use_carrier is false, return false.
>>> 797: //
>> 
>> Right after the check on L827 below, what prevents the vthread from being unmounted?
>> 
>> So we fetch the JavaThread* on L833 and then verify that it is protected by the TLH
>> which is good, but that does not prevent the vthread from being unmounted by the
>> time that we return the JavaThread* on L853 below.
>> 
>> Am I missing something?
>
> @dcubed-ojdk No you are not missing anything, the vthread could become unmounted. It is up to the subsequent handshake code to re-check that (as briefly discussed above).

Except I'm now discovering that can't work other than to abandon the virtual thread in question if you found the carrier has changed, otherwise you are in a handshake with the wrong carrier and so can't grab the stack - but that means you need to retry for this virtual thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2199302545

From sspitsyn at openjdk.org  Fri Jul 11 04:27:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 04:27:44 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
 <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
Message-ID: <aPiwuJ7d3MqTmYtvWcuaOIlhvxPaifQfzf0M7ZraXU0=.ead9efc5-40e4-42fc-830b-890a31b4552e@github.com>

On Thu, 10 Jul 2025 21:11:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: minor tweak of previous change
>
> src/hotspot/share/prims/jvmti.xml line 6233:
> 
>> 6231:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 6232:           The implementation is unable to set the frame locals
>> 6233:           (e.g. the frame at <code>depth</code> is executing a native method).
> 
> The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here.

Thank you for the comment.
Yes, I was thinking about adding virtual thread specific clarification for `SetLocal*` to the general API description.
I'll prepare and push an update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2199542452

From dholmes at openjdk.org  Fri Jul 11 04:41:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 04:41:43 GMT
Subject: RFR: 8361844: Build without C1 or C2 fails after 8360707 [v2]
In-Reply-To: <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
References: <jjFAMZfaVYh6WNi2ZKmItgEChqN79M-qiTXyNXKQDdk=.e53bdff4-a206-4de0-b44c-160548f5e755@github.com>
 <WZls1ayHRtjrptgZpQtK_chrKgk1HuoLOlBHEPhtgFo=.36e61f79-83dc-45e4-920b-37fd3b592e46@github.com>
Message-ID: <w2xGmhNFlQkc0XhIiVMejUzA0vgkcAcpNcpF-fmYQAQ=.09a58f28-6b57-4c5f-8aff-28d42eb0ae77@github.com>

On Thu, 10 Jul 2025 12:38:55 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> After [JDK-8360707](https://bugs.openjdk.org/browse/JDK-8360707) builds which omit C1 or C2 can generate an exploded jdk which fails on startup with an assert:
>> 
>>     assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
>> 
>> The problem is that the blob and stub id verification expects the blob, stub and entry ranges in the C1 and C2 stub groups to be positive. However, when C1 or C2 is omitted the associated range starts and ends are NO_BLOBID, NO_STUBID and NO_ENTRYID (all -1) and this breaks some of the internal consistency checks that test the span of blob, stub and entry ranges.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for empty stub groups when dumping stub tables

A reminder that hotspot changes require two reviews unless they are trivial. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26242#issuecomment-3060485027

From dholmes at openjdk.org  Fri Jul 11 05:09:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 05:09:40 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
Message-ID: <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>

On Fri, 11 Jul 2025 02:09:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dcubed-ojdk No you are not missing anything, the vthread could become unmounted. It is up to the subsequent handshake code to re-check that (as briefly discussed above).
>
> Except I'm now discovering that can't work other than to abandon the virtual thread in question if you found the carrier has changed, otherwise you are in a handshake with the wrong carrier and so can't grab the stack - but that means you need to retry for this virtual thread.

I see the current code just produces an empty stack trace if the virtual thread is found to have switched carriers. This seems wrong. We should be "pinning" the virtual thread whilst we try to get its stacktrace, such that it is unmounted or else mounted and fixed to a carrier. Other thread walking code uses the JvmtiVTMSTransitionDisabler to try and achieve this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2199604664

From sspitsyn at openjdk.org  Fri Jul 11 05:28:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 05:28:38 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
 <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
Message-ID: <bdrV4TCPIZfA722rqukObKV1mvOxUdAKip8z-52HYEI=.8d8e2ccb-4041-4baf-ad7d-2c81c1138eb6@github.com>

On Thu, 10 Jul 2025 07:20:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So I am quite concerned that this "workaround" has become entrenched.

Thank you for the comments and concern! I'll check what can be done here. Need to investigate it a little bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26232#issuecomment-3060599600

From sspitsyn at openjdk.org  Fri Jul 11 05:31:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 05:31:40 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
 <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
Message-ID: <Hs6jt_IBKQ3ill7bwM--2nxHcwCiJ2K1ThpVEhuLqeU=.35500f04-6b47-4f32-915f-0d200425e693@github.com>

On Thu, 10 Jul 2025 07:12:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   corrected one assert message
>
> src/hotspot/share/runtime/arguments.cpp line 525:
> 
>> 523:   // -------------- Deprecated Flags --------------
>> 524:   // --- Non-alias flags - sorted by obsolete_in then expired_in:
>> 525:   { "AllowRedefinitionToAddDeleteMethods", JDK_Version::jdk(13), JDK_Version::jdk(26), JDK_Version::jdk(27) },
> 
> Please move this line to before line 535 (ParallelRefProcEnabled) so that we are sorted on obsolete_in as required.

Thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2199641968

From sspitsyn at openjdk.org  Fri Jul 11 05:49:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 05:49:40 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v3]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <E-qxJ-MPaOi8TK6FiRlXbHv8YYmPosVi-9AtioXr8SI=.931813ea-1696-4012-8dd0-84a460418fd3@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: keep right order of the obsoleted VM options

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/a8358402..833c6169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From sspitsyn at openjdk.org  Fri Jul 11 05:49:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 05:49:41 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
 <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
Message-ID: <aDDx2El3AvFho8cs6gubYkkXJ0vp88RMDmJLL0SRi6g=.c309e0bd-3c80-4ea5-9432-0d65e705607d@github.com>

On Thu, 10 Jul 2025 07:09:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   corrected one assert message
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053:
> 
>> 4051: }
>> 4052: 
>> 4053: void VM_RedefineClasses::compute_matching_methods() {
> 
> I can't see that this method actually still does anything useful. ??

I think it does:
 - has asserts on added/deleted methods
 - collects `_matching_old_methods` and `_matching_new_methods`
 
 It seems that the `_old_methods` is same as `_matching_old_methods` and `_new_methods` is same as `_matching_new_methods`. But I do not want to make a deeper refactoring at this point until we have a decision on the full removal of added/deleted methods support. It feels like we may need to keep some support for lambda expression changes in class redefinitions/retransformations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2199664342

From dholmes at openjdk.org  Fri Jul 11 05:58:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Jul 2025 05:58:41 GMT
Subject: RFR: 8356556: AArch64: No need for acquire fence in safepoint poll
 in FFM
In-Reply-To: <46fXNzAzmkhFl0hxeMPosZdN4yUBYJ_pRq-VqzJV_nA=.bb5f0d8c-ff2d-477f-ab25-d1ee628ec8de@github.com>
References: <fw66m6cnpV49SFy1jHf0XRu9HFaHUpvd6F5hKU8Q30w=.23839a2b-5527-44da-8855-d0e3de345c20@github.com>
 <46fXNzAzmkhFl0hxeMPosZdN4yUBYJ_pRq-VqzJV_nA=.bb5f0d8c-ff2d-477f-ab25-d1ee628ec8de@github.com>
Message-ID: <tWkLBp2NFLmNHfRxEF9nZRgyphP4XOAN_-q8WxeldXs=.442ef54f-6a18-4870-aefe-5133cef54786@github.com>

On Thu, 10 Jul 2025 09:40:04 GMT, Samuel Chee <duke at openjdk.org> wrote:

>> Removes the unnecessary acquire to reduce memory ordering requirement since it is not longer needed as threads always disarm their own poll value.
>
> What seems to have happened, is that:
> 
> 1. I created this GitHub PR and someone else created the corresponding JBS ticket since I don't have the ability to do so.
> 2. This PR and the JBS ticket didn't automatically link together due to my lack of OCA access.
> 3. In the time it took for to get my OCA access (1.5 months), someone else saw the unassigned, unresolved JBS ticket, did it themselves and got it upstreamed before I ever got my OCA access.
> 4. I got my OCA access and realised what just happened.
> 
> What should happen now? Should I just close this PR?
> 
> And is there something both sides can do to prevent this from happening again? Since its work which has almost identically unnecessarily been done twice.

@spchee I would say that when @stooart-mon created the JBS issue he should have assigned it to himself and added a comment that you were working on it. That way it would have not been seen as available for picking up. Please just close this PR. If there is anything further to do in this area that your PR covered and the integrated one did not then a new JBS issue can be filed for that.

Also the OCA process should not have taken 1.5 months, but I can't comment on what may have happened there - @robilad?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25211#issuecomment-3060696128

From vyazici at openjdk.org  Fri Jul 11 08:40:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 11 Jul 2025 08:40:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics
In-Reply-To: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
Message-ID: <w_UNRtKLIrLTYOorLnJUZBAW5VFt8uten6KXUwAUwwI=.54ceb4fb-85d0-465a-a5a9-9711546ad5bb@github.com>

On Thu, 10 Jul 2025 20:54:24 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> I disagree with a small part of the statement of goals:
> 
>> Always validate all input at the intrinsic (but preferably behind a VM flag)
> 
> As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free.  Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic.  It?s too hard to verify by code review, and coverage testing is suspect.
> 
> We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors.  Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call).  Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic.
> 
> I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode.  This tells me that the extra optional testing is also not required to be 100%.
> 
> Thus, I think the above goal would be better stated this way:
> 
>> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation.
> 
>> Note:  IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw.
> 
> I think I'm agreeing with you on the material points.  It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary.

@rose00, thanks so much for the feedback. I agree with your remarks and get your points on _"Always validate all input at the intrinsic"_ is a violation of DRY and an impractical goal.

I incorporated your suggestions as follows:

1. Renamed the ticket to `Move input validation checks to Java for String-related intrinsics` (to better reflect the goal)
2. Replaced `Always validate all input at the intrinsic...` with your suggestion

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3061201145

From cstein at openjdk.org  Fri Jul 11 09:10:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 11 Jul 2025 09:10:19 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 8
Message-ID: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>

Please review the change to update to using jtreg 8.

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:
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

Changes: https://git.openjdk.org/jdk/pull/26261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289798
  Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261

PR: https://git.openjdk.org/jdk/pull/26261

From shade at openjdk.org  Fri Jul 11 09:20:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 09:20:10 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
 [v2]
In-Reply-To: <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
Message-ID: <6PnCrAx7F67U67Lqv1pvLvb4FBpJoUQ_OovolEUDMoA=.31a589ef-bc56-4764-bcf5-850c5de2c4e4@github.com>

On Thu, 10 Jul 2025 17:10:22 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I guess `klass->klass_holder()` is not needed to make sure we keep alive the class correctly, if we are running at init safepoint anyway. Given that code also works fine with storing Java mirror as root, and this change only moves that from JNI handles to OopStorage, this looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26233#pullrequestreview-3009424634

From tschatzl at openjdk.org  Fri Jul 11 09:53:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Jul 2025 09:53:16 GMT
Subject: RFR: 8361952: Double-checked locking MethodData::extra_data_lock()
 misses synchronization on reader side
Message-ID: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>

Hi all,

  please review this change that fixes some recently introduced double-checked locking missing the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.

Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.

Testing: gha

Thanks,
  Thomas

-------------

Commit messages:
 - 8361952

Changes: https://git.openjdk.org/jdk/pull/26262/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26262&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361952
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26262.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26262/head:pull/26262

PR: https://git.openjdk.org/jdk/pull/26262

From shade at openjdk.org  Fri Jul 11 10:47:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 10:47:12 GMT
Subject: RFR: 8361952: Double-checked locking MethodData::extra_data_lock()
 misses synchronization on reader side
In-Reply-To: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
Message-ID: <zPIm-1wa4YUjGEU0iX5uZXXQZ17baT6ARQsNuMCxn5I=.e916827c-ac51-44e2-a630-ef5f0401fb16@github.com>

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced double-checked locking missing the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks reasonable. 

Two nits:
  - This is not technically double-checked locking, this is just an atomic installation. So the RFE synopsis is not that accurate.
  - Maybe `Atomic::cmpxchg` should use a more relaxed memory ordering as well, to micro-optimize and offset the costs of now-proper acquire a bit. There is no need for default `memory_order_conservative` here. I think `memory_order_seq_cst` would do: gives acquire of `old` and release of new in the same package.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26262#pullrequestreview-3009726736

From duke at openjdk.org  Fri Jul 11 11:48:48 2025
From: duke at openjdk.org (Samuel Chee)
Date: Fri, 11 Jul 2025 11:48:48 GMT
Subject: Withdrawn: 8356556: AArch64: No need for acquire fence in safepoint
 poll in FFM
In-Reply-To: <fw66m6cnpV49SFy1jHf0XRu9HFaHUpvd6F5hKU8Q30w=.23839a2b-5527-44da-8855-d0e3de345c20@github.com>
References: <fw66m6cnpV49SFy1jHf0XRu9HFaHUpvd6F5hKU8Q30w=.23839a2b-5527-44da-8855-d0e3de345c20@github.com>
Message-ID: <arWfXcg0f2abrTdjmqaylhc_LfaUuJBryUCYNniVy3k=.7e247e28-b2cc-4fc4-8ecb-07015c73a100@github.com>

On Tue, 13 May 2025 12:53:56 GMT, Samuel Chee <duke at openjdk.org> wrote:

> Removes the unnecessary acquire to reduce memory ordering requirement since it is not longer needed as threads always disarm their own poll value.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25211

From tschatzl at openjdk.org  Fri Jul 11 12:18:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Jul 2025 12:18:38 GMT
Subject: RFR: 8361952: Installation of MethodData::extra_data_lock() misses
 synchronization on reader side
In-Reply-To: <zPIm-1wa4YUjGEU0iX5uZXXQZ17baT6ARQsNuMCxn5I=.e916827c-ac51-44e2-a630-ef5f0401fb16@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
 <zPIm-1wa4YUjGEU0iX5uZXXQZ17baT6ARQsNuMCxn5I=.e916827c-ac51-44e2-a630-ef5f0401fb16@github.com>
Message-ID: <pa4j-1rdQJE_VkLl_aDpVZKMfxe65x-LBEo3FRr5sHc=.f7d672f1-a8c2-4a54-8a00-255399f2e4b6@github.com>

On Fri, 11 Jul 2025 10:43:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks reasonable.
> 
> Two nits:
> 
>     * This is not technically double-checked locking, this is just an atomic installation. So the RFE synopsis is not that accurate.

Fixed.

> 
>     * Maybe `Atomic::cmpxchg` should use a more relaxed memory ordering as well, to micro-optimize and offset the costs of now-proper acquire a bit. There is no need for default `memory_order_conservative` here. I think `memory_order_seq_cst` would do: gives acquire of `old` and release of new in the same package.

I will leave that suggestion to another RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26262#issuecomment-3062079334

From shade at openjdk.org  Fri Jul 11 12:25:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 12:25:39 GMT
Subject: RFR: 8361952: Installation of MethodData::extra_data_lock() misses
 synchronization on reader side
In-Reply-To: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
Message-ID: <N4xaMUDLp37eBHpXjpPAJA8XHN3hi8kBBb7FqcfYpPA=.50673a5b-1f55-4af2-8be4-0c83744609fe@github.com>

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced atomic installation of a mutex, where the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

OK, sure.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26262#pullrequestreview-3010074399

From coleenp at openjdk.org  Fri Jul 11 15:05:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Jul 2025 15:05:40 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v3]
In-Reply-To: <E-qxJ-MPaOi8TK6FiRlXbHv8YYmPosVi-9AtioXr8SI=.931813ea-1696-4012-8dd0-84a460418fd3@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <E-qxJ-MPaOi8TK6FiRlXbHv8YYmPosVi-9AtioXr8SI=.931813ea-1696-4012-8dd0-84a460418fd3@github.com>
Message-ID: <PtnQR-BknYBYCWkiwAILsguZKJy4YsMypkwgsRe2sKw=.ab6d0494-5c4b-4463-9d4a-ae02b8ec6f11@github.com>

On Fri, 11 Jul 2025 05:49:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
>> 
>> TBD: Need to submit a related CSR.
>> 
>> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>>  
>> Testing:
>>  - mach5 tiers 1-6 are good
>>  - may need to run mach5 tiers > 6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: keep right order of the obsoleted VM options

It's nice to be able to clean this code out but I also think it's being used in the wild.  Was there another mechanism that we suggest for instrumenting native methods?  And there was code once to prefix native methods so this adding private method mechanism worked.

src/hotspot/share/oops/methodFlags.hpp line 49:

> 47:    status(is_old                      , 1 << 2) /* RedefineClasses() has replaced this method */ \
> 48:    status(is_obsolete                 , 1 << 3) /* RedefineClasses() has made method obsolete */ \
> 49:    status(RESERVED                    , 1 << 4) \

Maybe change to unused rather than reserved.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3010624569
PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2200936076

From coleenp at openjdk.org  Fri Jul 11 15:05:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Jul 2025 15:05:42 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v2]
In-Reply-To: <aDDx2El3AvFho8cs6gubYkkXJ0vp88RMDmJLL0SRi6g=.c309e0bd-3c80-4ea5-9432-0d65e705607d@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
 <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>
 <aDDx2El3AvFho8cs6gubYkkXJ0vp88RMDmJLL0SRi6g=.c309e0bd-3c80-4ea5-9432-0d65e705607d@github.com>
Message-ID: <ix_KFPID4wc-Rbywpi0vbjbcb54K9z_jBzeY1n_eDsk=.fa596a2f-567c-4340-bc85-af32cda1c4d4@github.com>

On Fri, 11 Jul 2025 05:44:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053:
>> 
>>> 4051: }
>>> 4052: 
>>> 4053: void VM_RedefineClasses::compute_matching_methods() {
>> 
>> I can't see that this method actually still does anything useful. ??
>
> I think it does:
>  - has asserts on added/deleted methods
>  - collects `_matching_old_methods` and `_matching_new_methods`
>  
>  It seems that the `_old_methods` is same as `_matching_old_methods` and `_new_methods` is same as `_matching_new_methods`. But I do not want to make a deeper refactoring at this point until we have a decision on the full removal of added/deleted methods support. It feels like we may need to keep some support for lambda expression changes in class redefinitions/retransformations.

What this does now is that the redefined class can have matching method names in a different order because of the signature.  So this sorts this out.  I don't know why we don't sort methods according to name and signature when creating the klass though.  That would make this just a method to check that the methods match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2200944838

From kvn at openjdk.org  Fri Jul 11 15:45:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 11 Jul 2025 15:45:39 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v3]
In-Reply-To: <hgBXjA-QEp4-eEmqFMVZfMV5tG_J72Q0f5sDAJKKE0E=.4a847ef6-209d-40e4-9516-496ed37a331c@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>
 <mCOG30UJm7qMo4ezo-5DqUh5TRhMe_JFzKpuYgaRMoI=.4b9c17ac-84cd-44cc-9d0f-6200407f09b3@github.com>
 <hgBXjA-QEp4-eEmqFMVZfMV5tG_J72Q0f5sDAJKKE0E=.4a847ef6-209d-40e4-9516-496ed37a331c@github.com>
Message-ID: <OobCF2nakAeLIWstVX2jb8Jk7KUGSaWtRB0RP1F0QyU=.29353d09-cc09-4907-926a-7f7d3893abc8@github.com>

On Thu, 10 Jul 2025 03:36:43 GMT, Guanqiang Han <duke at openjdk.org> wrote:

>> The fix looks reasonable to me but I'm not an expert in this code.
>
> hi @TobiHartmann , Thanks a lot for the detailed review, i already update PR and please taking another look when you have time .
> Also, since you mentioned you're not an expert in this area, would it make sense to ping someone more familiar?

Thank you, @hgqxjj, for finding this.  Looking through other flags setting I see some have the same issue, for example, `UseUnalignedLoadStores`.  Which could be set on command line and not switched off even if Cpu does not support the feature.

May be we should rework how all such flags are handled instead of fixing only one of them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3062795956

From sparasa at openjdk.org  Fri Jul 11 17:10:25 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Jul 2025 17:10:25 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
Message-ID: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>

Hi all,

This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.

Thanks!

-------------

Commit messages:
 - Backport 1c560727b850593561982ccc3ed37b0e98b3bbee

Changes: https://git.openjdk.org/jdk/pull/26271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360775
  Stats: 41 lines in 2 files changed: 40 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26271/head:pull/26271

PR: https://git.openjdk.org/jdk/pull/26271

From iris at openjdk.org  Fri Jul 11 17:42:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Jul 2025 17:42:38 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <hNvkWs8N0batlQY3XmA-hnwS_Z6Tc5DFIAusJSOoaDI=.0b5f04b6-643a-4c59-babb-f313b362f4ca@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> 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/26261#pullrequestreview-3011356650

From joehw at openjdk.org  Fri Jul 11 17:52:39 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 11 Jul 2025 17:52:39 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <0DTztUpAJe-j6cGqC33j6xyeTb1W_dFdaP65Z7f6NFk=.7bb3d63e-2a5a-4a95-93d2-9249285bcf70@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> 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.

test/jaxp/TEST.ROOT looks good.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3011378027

From coleenp at openjdk.org  Fri Jul 11 17:53:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Jul 2025 17:53:38 GMT
Subject: RFR: 8361952: Installation of MethodData::extra_data_lock() misses
 synchronization on reader side
In-Reply-To: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
Message-ID: <Vkzu_zf25zdrRDjoDs3H-7jTzGh_rBXkXOrPcNMsbrA=.16d445c4-f340-4cd6-abd8-3fc13c5042e1@github.com>

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced atomic installation of a mutex, where the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26262#pullrequestreview-3011379256

From shade at openjdk.org  Fri Jul 11 18:04:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:04:47 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <ipA9SlRuxB82xN9GFkfAsimc1lpscZ5-PF7Uy8XJ1vI=.602c69f9-ccfe-421d-b18a-fde6c82c7e5d@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

Looks good, assuming tests are passing.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26271#pullrequestreview-3011405250

From shade at openjdk.org  Fri Jul 11 18:08:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:08:21 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
Message-ID: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>

See bug for more investigation.

Additional testing:
 - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
 - [ ] Linux x86_64 Zero fastdebug, `bootcycle-images`
 - [ ] Linux x86_64 server fastdebug, `tier1`
 - [ ] Linux AArch64 server fastdebug, `tier1`

-------------

Commit messages:
 - Merge branch 'master' into JDK-8361380-arm32-bootstrap-atomics
 - Move Zero stubs
 - Shuffle things around a bit
 - Fix

Changes: https://git.openjdk.org/jdk/pull/26270/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26270&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361380
  Stats: 60 lines in 4 files changed: 28 ins; 30 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26270/head:pull/26270

PR: https://git.openjdk.org/jdk/pull/26270

From shade at openjdk.org  Fri Jul 11 18:08:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:08:21 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <x6DxP3CQRQFuzqzzgpO1xGZDiVvPnqnV5PQ_fTYyXdM=.5d03a261-468a-4708-8592-b7fa9a3ffc04@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [ ] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [ ] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `tier1`

Hey @adinn, I am probably confused how the stubs machinery is supposed to work. This patch looks simple, but Zero now fails with:


$ CONF=linux-x86_64-zero-fastdebug make images
Building target 'images' in configuration 'linux-x86_64-zero-fastdebug'
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/stubInfo.cpp:169), pid=986601, tid=986604
#  assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
#


What's the landmine here?

Must be https://github.com/openjdk/jdk/commit/3d74cbe0ac9b68dfc161a4c079b695a320a0e133, I'll pick it up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26270#issuecomment-3063070110
PR Comment: https://git.openjdk.org/jdk/pull/26270#issuecomment-3063160913

From shade at openjdk.org  Fri Jul 11 18:08:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:08:21 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <x6DxP3CQRQFuzqzzgpO1xGZDiVvPnqnV5PQ_fTYyXdM=.5d03a261-468a-4708-8592-b7fa9a3ffc04@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
 <x6DxP3CQRQFuzqzzgpO1xGZDiVvPnqnV5PQ_fTYyXdM=.5d03a261-468a-4708-8592-b7fa9a3ffc04@github.com>
Message-ID: <w7XDWw0XkSeXOjDbSXG2rlmakFKpl6oAdjBndo38JqE=.27db2dc4-ee02-49c2-aae2-71bc00b8b8e2@github.com>

On Fri, 11 Jul 2025 17:04:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Hey @adinn, I am probably confused how the stubs machinery is supposed to work. This patch looks simple, but Zero now fails with:
> 
> ```
> $ CONF=linux-x86_64-zero-fastdebug make images
> Building target 'images' in configuration 'linux-x86_64-zero-fastdebug'
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/stubInfo.cpp:169), pid=986601, tid=986604
> #  assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1
> #
> ```
> 
> What's the landmine here?

Oh wait, Linux x86_64 zero build fails like this even without this patch, ha.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26270#issuecomment-3063140796

From iveresov at openjdk.org  Fri Jul 11 18:09:59 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 11 Jul 2025 18:09:59 GMT
Subject: RFR: 8358580: Rethink how classes are kept alive in training data
 [v2]
In-Reply-To: <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
 <VjyC0HcncfV5UZlZNwNOdugDlMFKMoLzHe-Dg4HCOVE=.4d39acfd-d2df-4180-854f-2efa296a08f6@github.com>
Message-ID: <JSXI_bmahgrab2mrutodR0C0R0AV-Cjob5nEqWwLcjM=.ac7b461c-34ed-4dc0-ab72-e3d3dc88576b@github.com>

On Thu, 10 Jul 2025 17:10:22 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks for the reviews Coleen and Alexey!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26233#issuecomment-3063249658

From iveresov at openjdk.org  Fri Jul 11 18:09:59 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 11 Jul 2025 18:09:59 GMT
Subject: Integrated: 8358580: Rethink how classes are kept alive in training
 data
In-Reply-To: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
References: <pfQNKIrHhdmvWTH_wkM5hAi7WA5jRCJDbQpXLNKgO90=.9f4911b7-e5d7-409b-8f41-ba88fae5aae9@github.com>
Message-ID: <DHwd0F8NtCdPaoSXiaE3xgx3iabaJBbsLk9HP23VpEI=.4a8e19ee-a3d6-42f7-a64e-7393dcb844c0@github.com>

On Thu, 10 Jul 2025 02:37:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Use OopStorage directly instead of JNI handles. Note that we never destroy TrainingData objects, so we don't need to concern ourselves with freeing the OopStorage entries. Also, keeping the klasses alive is only necessary during the training run. During the replay the klasses TD objects refer to are always alive.

This pull request has now been integrated.

Changeset: 59bec29c
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59bec29c35361b7b256a2d435ced3458b0c5ea58
Stats:     7 lines in 2 files changed: 1 ins; 3 del; 3 mod

8358580: Rethink how classes are kept alive in training data

Reviewed-by: coleenp, shade

-------------

PR: https://git.openjdk.org/jdk/pull/26233

From shade at openjdk.org  Fri Jul 11 18:18:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:18:39 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <HjK2FB7fkQf9TqykurOjGSue2NnlASRlgOXfwmRiAjo=.e2ee9d15-9155-4c59-8f91-24ed84875951@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [ ] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `tier1`

...since he lead me to suspect ARM32 atomics involvement in this whole debacle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26270#issuecomment-3063269638

From kvn at openjdk.org  Fri Jul 11 18:23:39 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 11 Jul 2025 18:23:39 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <D3z_mpfbjoYGdEcOZFoPTa3B09snhe1CP0vrk-OiIsg=.869c655e-ef55-4630-a198-76fe009f5404@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [ ] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `tier1`

Looks good to me.

But @adinn will be main reviewed.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26270#pullrequestreview-3011453082

From duke at openjdk.org  Fri Jul 11 18:46:41 2025
From: duke at openjdk.org (duke)
Date: Fri, 11 Jul 2025 18:46:41 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <3kyK-okqHFO4kRIKc_q0RTmeOd2CNiz-eeI5DOmWDLg=.b1e6f409-2dd5-413d-a8e8-1b3bbb2805d6@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

@vamsi-parasa 
Your change (at version 601ac00fbbf2d85ca605185af1ff7d6e8d8447a3) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3063360331

From sspitsyn at openjdk.org  Fri Jul 11 18:54:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 18:54:34 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v4]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <RxLzaNkFiwjnXLTQTqZSOe6IlSjeCEcq_z2mnCDfCiY=.3fbfba7f-6666-42d4-b38f-05bcd14e1348@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: replace RESERVED flag with UNUSED

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/833c6169..fc5630c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From sspitsyn at openjdk.org  Fri Jul 11 18:54:37 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 18:54:37 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v3]
In-Reply-To: <PtnQR-BknYBYCWkiwAILsguZKJy4YsMypkwgsRe2sKw=.ab6d0494-5c4b-4463-9d4a-ae02b8ec6f11@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <E-qxJ-MPaOi8TK6FiRlXbHv8YYmPosVi-9AtioXr8SI=.931813ea-1696-4012-8dd0-84a460418fd3@github.com>
 <PtnQR-BknYBYCWkiwAILsguZKJy4YsMypkwgsRe2sKw=.ab6d0494-5c4b-4463-9d4a-ae02b8ec6f11@github.com>
Message-ID: <SuPzpo-vupnMoLVVhggvNMbxYzWOJcDcCwa7ZtrIL6c=.3d10afe8-a09b-4aad-b0e9-5f129e344bc8@github.com>

On Fri, 11 Jul 2025 14:54:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: keep right order of the obsoleted VM options
>
> src/hotspot/share/oops/methodFlags.hpp line 49:
> 
>> 47:    status(is_old                      , 1 << 2) /* RedefineClasses() has replaced this method */ \
>> 48:    status(is_obsolete                 , 1 << 3) /* RedefineClasses() has made method obsolete */ \
>> 49:    status(RESERVED                    , 1 << 4) \
> 
> Maybe change to unused rather than reserved.

Thanks. Fixed now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2201539524

From sspitsyn at openjdk.org  Fri Jul 11 19:01:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 19:01:48 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v3]
In-Reply-To: <PtnQR-BknYBYCWkiwAILsguZKJy4YsMypkwgsRe2sKw=.ab6d0494-5c4b-4463-9d4a-ae02b8ec6f11@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <E-qxJ-MPaOi8TK6FiRlXbHv8YYmPosVi-9AtioXr8SI=.931813ea-1696-4012-8dd0-84a460418fd3@github.com>
 <PtnQR-BknYBYCWkiwAILsguZKJy4YsMypkwgsRe2sKw=.ab6d0494-5c4b-4463-9d4a-ae02b8ec6f11@github.com>
Message-ID: <I8ZvH5xJ-AZ_mMOcgs7pvsUX-Fvh98oJvxwMN43AYWM=.6267925b-076e-44ee-9b9a-4c5dbb3825fd@github.com>

On Fri, 11 Jul 2025 15:02:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> It's nice to be able to clean this code out but I also think it's being used. Was there another mechanism that we suggest for instrumenting native methods? And there was code once to prefix native methods so this adding private method mechanism worked.
>
> Edit: I seem to remember TransferNativeFunctionRegistration code was for instrumenting native methods that used adding and deleting static private methods. So maybe this should be removed also as a follow-up?

In fact, I have a big doubt we really want to get rid of this approach to instrument native methods calls.
The same doubt is about lambda expressions change support. It feels we need more thinking on this and some kind of consensus on this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26232#issuecomment-3063405103

From sparasa at openjdk.org  Fri Jul 11 19:03:45 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Jul 2025 19:03:45 GMT
Subject: RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds [v2]
In-Reply-To: <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
 <89lL3KxdJaMfke0irOMa24-3_ZbTifpXAXCDq1TGvNQ=.50ab6ae7-9d4a-426e-8832-a7692acbd921@github.com>
Message-ID: <sQlgp6eptMhY-O3DJ6qYkPmlBh8QVqE8w5Qt4QxbmWA=.27337cde-2cd3-4c85-8853-04f4a8359e83@github.com>

On Mon, 30 Jun 2025 18:30:24 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Currently, APX is not enabled consistently between product and debug builds.
>> 
>> If the hardware supports Intel APX:
>> 
>> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
>> 
>> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
>> 
>> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**
>
> Srinivas Vamsi Parasa 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:
> 
>   8360776: Enable -XX:+UseAPX as experimental feature in all builds

> /sponsor

Thank you Vladimir!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26029#issuecomment-3063398180

From sparasa at openjdk.org  Fri Jul 11 19:03:46 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Jul 2025 19:03:46 GMT
Subject: Integrated: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
References: <0FxXpxiS5AsdMzFmEkhVGhWBPyB9H2n7N74iAoAmXdg=.5aca9c53-24d7-42ff-b1ed-072dd039ae1b@github.com>
Message-ID: <4j-qYKeK0wSfx3MDAftRf_8T6fMycD2fUPqvlhETlE0=.8e511213-27bb-432e-8217-a47ef849199c@github.com>

On Fri, 27 Jun 2025 22:13:47 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Currently, APX is not enabled consistently between product and debug builds.
> 
> If the hardware supports Intel APX:
> 
> 1) In product builds, APX is disabled by default, even if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.
> 
> 2) In debug builds, APX is enabled by default regardless of whether the user explicitly enables it or not.
> 
> **The goal of this PR is to enable APX for both product and debug builds if and only if the user explicitly enables it using `-XX:+UnlockExperimentalVMOptions -XX:+UseAPX`.**

This pull request has now been integrated.

Changeset: 26b00280
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671
Stats:     16 lines in 4 files changed: 0 ins; 16 del; 0 mod

8360776: Disable Intel APX by default and enable it with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds

Reviewed-by: sviswanathan, dholmes, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/26029

From sparasa at openjdk.org  Fri Jul 11 19:05:51 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Jul 2025 19:05:51 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it with
 -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
Message-ID: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>

Hi all,

This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.

This PR **got approval** for the late enhancement feature request. 

Thanks!

-------------

Commit messages:
 - Backport 26b002805ab235d07998eddd486fe66a69f60671

Changes: https://git.openjdk.org/jdk/pull/26274/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360776
  Stats: 16 lines in 4 files changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26274/head:pull/26274

PR: https://git.openjdk.org/jdk/pull/26274

From kvn at openjdk.org  Fri Jul 11 19:57:38 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 11 Jul 2025 19:57:38 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it
 with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
Message-ID: <203GJDqOWoSqcG1mV0v1kPqjoMlnQNtgsjzV2_7ciCE=.b3737c7f-4e35-41d4-8da1-411748d0c56f@github.com>

On Fri, 11 Jul 2025 19:00:20 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.
> 
> This PR **got approval** for the late enhancement feature request. 
> 
> Thanks!

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26274#pullrequestreview-3011800864

From sspitsyn at openjdk.org  Fri Jul 11 20:08:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 20:08:01 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI spec sections:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
>   - `GetLocal<Type>`
>   - `SetLocal<Type>`
>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>   
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

Serguei Spitsyn 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
 - review: minor tweak of previous change
 - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
 - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
 - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
 - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
 - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26111/files
  - new: https://git.openjdk.org/jdk/pull/26111/files/170fe280..8f6e7787

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=05-06

  Stats: 16165 lines in 539 files changed: 9142 ins; 3145 del; 3878 mod
  Patch: https://git.openjdk.org/jdk/pull/26111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111

PR: https://git.openjdk.org/jdk/pull/26111

From sspitsyn at openjdk.org  Fri Jul 11 20:16:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Jul 2025 20:16:24 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v5]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <KyIi-AeynLg_E6GDrMLiwZgH8Xf3b9EyAKtkCVtngyY=.60aa046e-7aab-4dc6-806a-50a89d2f1282@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/fc5630c1..3900252d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=03-04

  Stats: 16165 lines in 539 files changed: 9142 ins; 3145 del; 3878 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From cjplummer at openjdk.org  Fri Jul 11 22:22:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Jul 2025 22:22:44 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
Message-ID: <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>

On Fri, 11 Jul 2025 20:08:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI spec sections:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>>   - `GetLocal<Type>`
>>   - `SetLocal<Type>`
>>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>>   
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn 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
>  - review: minor tweak of previous change
>  - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
>  - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>  - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>  - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
>  - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

src/hotspot/share/prims/jvmti.xml line 5904:

> 5902:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 5903:           The implementation is unable to get the frame locals
> 5904:           (e.g. the frame at <code>depth</code> is executing a native method).

Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT .

For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2201974159

From stuefe at openjdk.org  Sat Jul 12 06:43:33 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 12 Jul 2025 06:43:33 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing
Message-ID: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>

Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulnes:

- In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
- In assert_correct, we test the narrowKlass before decoding it. Otherwise, if its 0, we'd assert, if garbage, the resulting Klass* would be garbage.
- In print_failure, we now check pointers for readability before handing them to print_obj
- In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
- In print_obj, we print a small hex dump of the header (32bytes). With little cost we get a glance at the raw header and the first members.
- In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
- In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*

Tests: I manually tested the patch with a number of manually broken oops of various flavours. 

Example output, invalid forwardee:


Referenced from:
  no interior location recorded (probably a plain heap scan, or detached oop)

Object:
  0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;

        allocated after mark start
        after update watermark
        marked strong
        marked weak
    not in collection set
    mark:  marked(0xdeaddeaddeaddeaf)
    region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0

  0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
  0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................

Forwardee:
  0xdeaddeaddeaddeac - safe print, no details

-------------

Commit messages:
 - small revert
 - cosmetics
 - wip
 - wip
 - wip
 - wip
 - assert_correct

Changes: https://git.openjdk.org/jdk/pull/26237/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26237&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361712
  Stats: 164 lines in 9 files changed: 122 ins; 12 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26237/head:pull/26237

PR: https://git.openjdk.org/jdk/pull/26237

From adinn at openjdk.org  Sat Jul 12 08:24:38 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sat, 12 Jul 2025 08:24:38 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <2GsTdvKbjungrYxV2mNQ00swTwDNM9TKfaz9WoXFlxg=.80d16ad6-fc94-44bf-b21d-aed77d01c2b8@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [ ] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `tier1`

Thanks for fixing this, Alexei. Looks good.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26270#pullrequestreview-3012832120

From sviswanathan at openjdk.org  Sat Jul 12 14:01:42 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 12 Jul 2025 14:01:42 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it
 with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
Message-ID: <bljzZFZWnIgEsbN88qhOmjpSJX2X1LdhSUeWu7luTGI=.43effb4c-73a0-45ed-8047-30c7b109002a@github.com>

On Fri, 11 Jul 2025 19:00:20 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.
> 
> This PR **got approval** for the late enhancement feature request. 
> 
> Thanks!

Looks good to me as well.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26274#pullrequestreview-3013174899

From sviswanathan at openjdk.org  Sat Jul 12 14:04:37 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 12 Jul 2025 14:04:37 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <EuhxmqEbfx9BB8EPKr9ensdrQhhqFD6Llv9W86yqfA4=.7119f93e-477d-4bc9-9d4f-ef7b70c5b2fa@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26271#pullrequestreview-3013177048

From duke at openjdk.org  Sat Jul 12 17:32:41 2025
From: duke at openjdk.org (duke)
Date: Sat, 12 Jul 2025 17:32:41 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it
 with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
Message-ID: <tG8uSAqC4fCzMlYqGoa5rQa97-yVUgLZ1uBBe46vPxE=.9b05f388-3f23-4f68-baae-5b0d8fa94a15@github.com>

On Fri, 11 Jul 2025 19:00:20 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.
> 
> This PR **got approval** for the late enhancement feature request. 
> 
> Thanks!

@vamsi-parasa 
Your change (at version fb0d081c5ca0add99d457545dfbc10aa88d5618e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26274#issuecomment-3065897028

From duke at openjdk.org  Sat Jul 12 17:32:42 2025
From: duke at openjdk.org (duke)
Date: Sat, 12 Jul 2025 17:32:42 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <m5KvCqyFMqg_Cs9YW4AzlH76VgyEokoWsXTvstq2l_0=.4ca30ee8-5a41-4ae4-996f-d89cd3906f85@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

@vamsi-parasa 
Your change (at version c47ecfe58923367c9ebdb8e103ab2467736e839d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26271#issuecomment-3065896947

From sparasa at openjdk.org  Sat Jul 12 21:37:45 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Sat, 12 Jul 2025 21:37:45 GMT
Subject: [jdk25] Integrated: 8360776: Disable Intel APX by default and enable
 it with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
Message-ID: <8zhEkP4gTjuArExN8mWUX5ma-93QWgoG4NSVxLcixBg=.c132c33b-35ac-4522-9f7c-0abc6f128ad1@github.com>

On Fri, 11 Jul 2025 19:00:20 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.
> 
> This PR **got approval** for the late enhancement feature request. 
> 
> Thanks!

This pull request has now been integrated.

Changeset: c5d0f1bc
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5d0f1bc5ebd13595d24473b673a8934f2326189
Stats:     16 lines in 4 files changed: 0 ins; 16 del; 0 mod

8360776: Disable Intel APX by default and enable it with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds

Reviewed-by: kvn, sviswanathan
Backport-of: 26b002805ab235d07998eddd486fe66a69f60671

-------------

PR: https://git.openjdk.org/jdk/pull/26274

From duke at openjdk.org  Sun Jul 13 18:31:59 2025
From: duke at openjdk.org (duke)
Date: Sun, 13 Jul 2025 18:31:59 GMT
Subject: Withdrawn: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <gxHnytUC-4FxOCzfdNqXlZKsKaRFxv2sIx4OQd8-3TU=.81d3f2be-1df5-45f6-b8d6-20cc4c6186df@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23739

From sparasa at openjdk.org  Sun Jul 13 20:28:44 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Sun, 13 Jul 2025 20:28:44 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it
 with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <bljzZFZWnIgEsbN88qhOmjpSJX2X1LdhSUeWu7luTGI=.43effb4c-73a0-45ed-8047-30c7b109002a@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
 <bljzZFZWnIgEsbN88qhOmjpSJX2X1LdhSUeWu7luTGI=.43effb4c-73a0-45ed-8047-30c7b109002a@github.com>
Message-ID: <UKdqowTThW3f64MIbML19o1ESOxTJuC3EQGTppcOLp0=.9e14d198-a69f-4716-8e6f-b98228f812d8@github.com>

On Sat, 12 Jul 2025 13:58:46 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Looks good to me as well.

Thank You Sandhya!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26274#issuecomment-3067283165

From sparasa at openjdk.org  Sun Jul 13 20:28:44 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Sun, 13 Jul 2025 20:28:44 GMT
Subject: [jdk25] RFR: 8360776: Disable Intel APX by default and enable it
 with -XX:+UnlockExperimentalVMOptions -XX:+UseAPX in all builds
In-Reply-To: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
References: <qhtaBUH2GE-pH7w_Mo1E_h3ajWvA2jEPadq9T8yxqWA=.d62e4f5f-e65a-4e71-a0bf-09ba447e59a7@github.com>
Message-ID: <0Wi046xEm6dvSwmNKa2UeEpk3b4e6Bb6_roErseI12k=.6970c5ed-9982-4d58-b295-2ccfb6a68dbc@github.com>

On Fri, 11 Jul 2025 19:00:20 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [26b00280](https://github.com/openjdk/jdk/commit/26b002805ab235d07998eddd486fe66a69f60671) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 11 Jul 2025 and was reviewed by Sandhya Viswanathan, David Holmes and Jatin Bhateja.
> 
> This PR **got approval** for the late enhancement feature request. 
> 
> Thanks!

> /sponsor

Thank you Vladmir!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26274#issuecomment-3067283458

From jbhateja at openjdk.org  Mon Jul 14 02:57:58 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Jul 2025 02:57:58 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <Li4FxpFG2LwyJXflYHKV3RyCR-wubpBZ5IUmrPX09IU=.6f9ec47d-9898-425e-9ffc-5695c54ec921@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

Link to original PR: https://github.com/openjdk/jdk/pull/26009

LGTM

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26271#pullrequestreview-3014641602

From sparasa at openjdk.org  Mon Jul 14 02:57:59 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 14 Jul 2025 02:57:59 GMT
Subject: [jdk25] Integrated: 8360775: Fix Shenandoah GC test failures when APX
 is enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <ZWcntpM1mRtAvzd3UueCIboiE4bYhqkqh2YGKAQiu7k=.e2920e62-2c24-42d0-bd86-f05d3a326e6f@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9f218452
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f218452625250109e3f2fca22319ae36205f0b3
Stats:     41 lines in 2 files changed: 40 ins; 0 del; 1 mod

8360775: Fix Shenandoah GC test failures when APX is enabled

Reviewed-by: shade, sviswanathan, jbhateja
Backport-of: 1c560727b850593561982ccc3ed37b0e98b3bbee

-------------

PR: https://git.openjdk.org/jdk/pull/26271

From dholmes at openjdk.org  Mon Jul 14 03:46:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 03:46:40 GMT
Subject: RFR: 8361952: Installation of MethodData::extra_data_lock() misses
 synchronization on reader side
In-Reply-To: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
Message-ID: <17de-tEa5r8YpcWhJukEJUvVDjIIXuANurWSfa7m3UQ=.f9745287-4454-4186-8382-0392e328c490@github.com>

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced atomic installation of a mutex, where the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26262#pullrequestreview-3014697109

From duke at openjdk.org  Mon Jul 14 04:08:42 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Mon, 14 Jul 2025 04:08:42 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v3]
In-Reply-To: <OobCF2nakAeLIWstVX2jb8Jk7KUGSaWtRB0RP1F0QyU=.29353d09-cc09-4907-926a-7f7d3893abc8@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <dJrP6JtwhDcMAlFCd54yfxmWMkhMPkVfqGICVaMkouE=.085a682a-f6a5-4f3f-bb7a-f16ddb92db77@github.com>
 <mCOG30UJm7qMo4ezo-5DqUh5TRhMe_JFzKpuYgaRMoI=.4b9c17ac-84cd-44cc-9d0f-6200407f09b3@github.com>
 <hgBXjA-QEp4-eEmqFMVZfMV5tG_J72Q0f5sDAJKKE0E=.4a847ef6-209d-40e4-9516-496ed37a331c@github.com>
 <OobCF2nakAeLIWstVX2jb8Jk7KUGSaWtRB0RP1F0QyU=.29353d09-cc09-4907-926a-7f7d3893abc8@github.com>
Message-ID: <4Nn6ckDqoo7zpqKY-M-JxZRrvncEAddnQ8WPK1c2IQc=.1ad9d8e7-5a1a-406c-a6ac-a59b3d9ea3bf@github.com>

On Fri, 11 Jul 2025 15:42:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> hi @TobiHartmann , Thanks a lot for the detailed review, i already update PR and please taking another look when you have time .
>> Also, since you mentioned you're not an expert in this area, would it make sense to ping someone more familiar?
>
> Thank you, @hgqxjj, for finding this.  Looking through other flags setting I see some have the same issue, for example, `UseUnalignedLoadStores`.  Which could be set on command line and not switched off even if Cpu does not support the feature.
> 
> May be we should rework how all such flags are handled instead of fixing only one of them.

hi @vnkozlov ?Thank you very much for your feedback. I looked into the issue you mentioned regarding flags like UseUnalignedLoadStores. I tested it with the command "java -XX:+UseUnalignedLoadStores -XX:UseSSE=1 -version" and found that no exception occurred. This is likely because supports_sse3 is a sufficient but not a necessary condition for enabling this flag, whereas for this issue [JDK-8358592] , supports_sse3 is both a necessary and sufficient condition for enabling UseSSE42Intrinsics. The bug was caused by the omission of handling when supports_sse3 is false and UseSSE42Intrinsics is enabled, which led to the error.
As for your suggestion to "rework how all such flags are handled," I think it?s an excellent idea because the logic here is indeed a bit convoluted. However, given that this code was contributed by multiple people and determining which conditions are sufficient or necessary can be quite complex, large-scale changes may introduce instability. Therefore, I would suggest we hold off on making such extensive modifications at this point, as such changes could be risky and require a broader understanding of the relationship between all flags.
That said, I really appreciate your feedback and would be glad to hear any further thoughts you may have ? These are very helpful!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3067764119

From tschatzl at openjdk.org  Mon Jul 14 08:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 08:03:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <mmlNgBegOf3YMmUIXIzwKno1STvzS1_5o7Jhmr7-8XA=.92dac625-f773-498b-a014-addfd74e619e@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
> 
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review: remove sweep_epoch
>  - Merge branch 'master' into card-table-as-dcq-merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)
>  - * indentation fix
>  - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

Not yet...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3068246695

From jbhateja at openjdk.org  Mon Jul 14 08:17:41 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Jul 2025 08:17:41 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
Message-ID: <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>

On Tue, 8 Jul 2025 22:44:55 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename to paired_push and paired_pop

src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 114:

> 112:         __ paired_push(rax);
> 113:       }
> 114:       __ paired_push(rcx);

Hi @vamsi-parasa , for consecutive push/pop we can use push2/pop2 and 16byte alignment can be  guaranteed using following technique 
https://github.com/openjdk/jdk/pull/25351/files#diff-d5d721ebf93346ba66e81257e4f6c5e6268d59774313c61e97353c0dfbf686a5R94

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2204155927

From jbhateja at openjdk.org  Mon Jul 14 08:23:46 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Jul 2025 08:23:46 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <Xyigm3QyWQf9-oqkmC28lb51YRAK4f3PZikl73RJEN8=.956a50ab-8b5e-4138-81f1-69ec0f458fa7@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <x9-qqipC6yB8WMDgHZZKNuCTdqWgVqMaPscglOQuFv4=.67e08ef7-acab-4752-87f8-318bf20ec070@github.com>
 <DWBR-FDFnC7dZaVkXzUnjPZJexq8A-P8d8RAEjx6Uq0=.327b2aea-9970-4bc1-a550-8ff539ef0666@github.com>
 <PbGdp-ZyWlqTaPl04irhlkyyK5pgjHc3NTTRRejKLAc=.43e02651-2528-4bb0-bdd9-453cfe76f49b@github.com>
 <hIDvtNZLFYjj0GVl3BLEE2EwJE7Xteczd6jf1ydX8SU=.446db765-5999-4e65-837e-26d08171b62b@github.com>
 <Xyigm3QyWQf9-oqkmC28lb51YRAK4f3PZikl73RJEN8=.956a50ab-8b5e-4138-81f1-69ec0f458fa7@github.com>
Message-ID: <vhX1e6ehP7IVMWt5nvwKbVvICAjrYGhdo2KUks4H344=.386ddd24-08b0-435c-a14c-9af79555d65d@github.com>

On Wed, 2 Jul 2025 23:28:42 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> For a cleaner interface, I think we can also maintain a RAII style APXPushPopPairTracker in the stub snippets using push/pop instruction sequence and wrap the actual assembler call underneath. The idea here is to catch the balancing error upfront as PPX is purely a performance hint. Instructions with this hint have the same functional semantics as those without. PPX hints set by the compiler that violate the balancing rule may turn off the PPX
>> optimization, but they will not affect program semantics..
>> 
>> 
>> class APXPushPopPairTracker {
>>     private:
>>         int _counter;
>>  
>>     public:
>>         APXPushPopPairTracker() _counter(0) {
>>         }
>> 
>>        ~APXPushPopPairTracker() {
>>            assert(_counter == 0, "Push/pop pair mismatch");
>>         }
>>      
>>         void push(Register reg, bool has_matching_pop) {
>>             if (has_matching_pop && VM_Version::supports_apx_f()) {
>>                Assembler::pushp(reg);
>>                incrementCounter();
>>             } else {
>>                Assembler::push(reg);
>>             }
>>         }
>>         void pop(Register reg, bool has_matching_push) {
>>             if (has_matching_push && VM_Version::supports_apx_f()) {
>>                Assembler::popp(reg);
>>                decrementCounter();
>>             } else {
>>                Assembler::pop(reg);
>>             }
>>         }     
>>         void incrementCounter() {
>>           _counter++;
>>         }
>>         void decrementCounter() {
>>            _counter--;
>>         }
>> }
>
> Hi Jatin (@jatin-bhateja) and Vlad (@vpaprotsk),
> 
> There's one more issue to be considered. The C++ PushPopTracker code will be run during the stub generation time. There are code bocks which do a single push onto the stack but due to multiple exit paths, there will be multiple pops as illustrated below. Will this reference counting approach not fail in such a scenario as the stub code is generated all at once during the stub generation phase?
> 
> 
> #begin stack frame
> push(r21)
> 
> #exit condition 1
> pop(r21)
> 
> # exit condition 2
> pop(r21)

There is no one size fits all soution, idea is to be smart whereever possible, by maintaining a fixed stack of registers populated during push operation we can delegate the responsibility of emitting pop instructions in reverse order to tracker, @vamsi-parasa for now I am ok with maintaining existing implimentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2204183436

From aph at openjdk.org  Mon Jul 14 08:25:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Jul 2025 08:25:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <gvVKJFTN6wQKkP4VxBh_6-GhYNdQSoq3KQ05pj54A0Q=.7fe80989-b668-420e-b439-179786b39800@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
> 
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review: remove sweep_epoch
>  - Merge branch 'master' into card-table-as-dcq-merge
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)
>  - * indentation fix
>  - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a

AArch64 looks good.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3015276922

From tschatzl at openjdk.org  Mon Jul 14 09:02:50 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:02:50 GMT
Subject: RFR: 8361952: Installation of MethodData::extra_data_lock() misses
 synchronization on reader side
In-Reply-To: <N4xaMUDLp37eBHpXjpPAJA8XHN3hi8kBBb7FqcfYpPA=.50673a5b-1f55-4af2-8be4-0c83744609fe@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
 <N4xaMUDLp37eBHpXjpPAJA8XHN3hi8kBBb7FqcfYpPA=.50673a5b-1f55-4af2-8be4-0c83744609fe@github.com>
Message-ID: <M5PdffEDSM8vCkwZTbAxW7zoJ-fgYSqW5OapymW-fBU=.d63482cb-ea5c-4fa3-a5cd-4762d11465ba@github.com>

On Fri, 11 Jul 2025 12:23:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that fixes some recently introduced atomic installation of a mutex, where the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
>> 
>> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> OK, sure.

Thanks @shipilev @coleenp @dholmes-ora for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26262#issuecomment-3068518246

From tschatzl at openjdk.org  Mon Jul 14 09:02:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:02:51 GMT
Subject: Integrated: 8361952: Installation of MethodData::extra_data_lock()
 misses synchronization on reader side
In-Reply-To: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
References: <ve6hN2neFe4ogtqIBEPcmjNstG_HgOEmhNrRJzYt1kY=.bc740088-c0a0-4c56-ae25-e826fda99fa7@github.com>
Message-ID: <zXWdv7P5oDgpgx0jxtOo2i8pbxl4HzioohkBOQMaPB8=.bd14bbb0-3729-423c-a0ee-9382f8e7c134@github.com>

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced atomic installation of a mutex, where the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 272e66d0
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/272e66d017a3497d9af4df6f042c741ad8a59dd6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361952: Installation of MethodData::extra_data_lock() misses synchronization on reader side

Reviewed-by: shade, coleenp, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26262

From tschatzl at openjdk.org  Mon Jul 14 09:13:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:13:38 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v42]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8lZdT84SJ-daIPPpdq35hAZ0MGa8b07TPpPa3IDp030=.201a5b52-aecb-424e-9bdf-4c64baff5e87@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:

 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - ... and 48 more: https://git.openjdk.org/jdk/compare/14c79be1...5ab928e8

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=41
  Stats: 7124 lines in 112 files changed: 2589 ins; 3594 del; 941 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From mli at openjdk.org  Mon Jul 14 10:31:31 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Jul 2025 10:31:31 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v3]
In-Reply-To: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
Message-ID: <w5d7W1hiCR_1g0do4sTcn4uHA1a7OYMjEVjEbNpx-KU=.dba531b7-9f78-4ae2-877d-1b7a82f7198d@github.com>

> Hi,
> Can you help to review this patch?
> 
> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
> 
> Riscv should support these features and resolve relative issues.
> 
> ## Test
> 
> ### jtreg
> 
> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
> 
> ### Performance
> 
> perf command to run the simplest Hello world java program:
> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
> 
> perf data:
> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
> 
> Thanks

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/26101/files
  - new: https://git.openjdk.org/jdk/pull/26101/files/bc05a32f..c0fc6bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26101&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26101&range=01-02

  Stats: 53 lines in 3 files changed: 26 ins; 26 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26101/head:pull/26101

PR: https://git.openjdk.org/jdk/pull/26101

From mli at openjdk.org  Mon Jul 14 10:31:34 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Jul 2025 10:31:34 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <Xk8pi5GoYYqXVsbYT5Tvt5xz8VxeFEa3g6LL2qjMnyo=.59d5fc9b-83d2-48ea-aa5a-9d1f2362521a@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
 <Xk8pi5GoYYqXVsbYT5Tvt5xz8VxeFEa3g6LL2qjMnyo=.59d5fc9b-83d2-48ea-aa5a-9d1f2362521a@github.com>
Message-ID: <6Nju2tXHfHz0pucBcl6eSCwx7oQZXvDczTmoHKlJr4o=.0089e8c6-446e-4a21-8cd3-226516547d63@github.com>

On Mon, 7 Jul 2025 07:31:11 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - pass msg via a0 in stop
>>  - comment
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 800:
> 
>> 798:   push_reg(RegSet::of(t1, xmethod), sp);   // push << t1 & xmethod >> to sp
>> 799:   movptr(t1, RuntimeAddress(entry_point), t0);
>> 800:   jalr(t1);
> 
> This movptr + jalr sequence could be further simplified into `rt_call(entry_point)`, which could help save one add instruction.

Not sure if I understand your suggestion right.
If we use `rt_call` here, it will only call into `movptr1`, whose instructions is one longer than `movptr2`.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4930:
> 
>> 4928:   push_reg(saved_regs, sp);
>> 4929: 
>> 4930:   movptr(t1, ExternalAddress(CAST_FROM_FN_PTR(address, Thread::current)));
> 
> It will be more consistent with other places in riscv code where we move an ExternalAddress into a register if we do: `la(t1, ExternalAddress(CAST_FROM_FN_PTR(address, Thread::current)))`.

make sense, will fix it.

> src/hotspot/cpu/riscv/runtime_riscv.cpp line 63:
> 
>> 61: UncommonTrapBlob* OptoRuntime::generate_uncommon_trap_blob() {
>> 62:   // Allocate space for the code
>> 63:   ResourceMark rm;
> 
> Seems more reasonable to move this `ResourceMark rm;` closer to its user `CodeBuffer buffer(name, 2048, 1024);`.
> Similar for other changes in this file and src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp.

make sense, will fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2204501151
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2204501707
PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2204502061

From dfenacci at openjdk.org  Mon Jul 14 10:34:45 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 14 Jul 2025 10:34:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Thanks a lot for looking into this Volkan!
I left a couple of minor comments.
I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:

> 6012: }
> 6013: 
> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII

Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

src/hotspot/share/classfile/vmIntrinsics.hpp line 417:

> 415:                                                                                                                         \
> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \

It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

src/hotspot/share/opto/c2_globals.hpp line 666:

> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 666:           "Verify that Java level checks in intrinsics work as expected")   \

To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3015376813
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204312397
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204505403
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204256430

From mli at openjdk.org  Mon Jul 14 11:22:18 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Jul 2025 11:22:18 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v4]
In-Reply-To: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
Message-ID: <ii7ZRcOl4H7pOIwnCBAip3fMnNj8hg-IokqYsR00bQ8=.1d9f30ce-cbde-48f3-a453-f7cb6bc8c1a6@github.com>

> Hi,
> Can you help to review this patch?
> 
> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
> 
> Riscv should support these features and resolve relative issues.
> 
> ## Test
> 
> ### jtreg
> 
> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
> 
> ### Performance
> 
> perf command to run the simplest Hello world java program:
> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
> 
> perf data:
> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
> 
> 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 17 commits:

 - merge master - JDK-8360707
 - minor
 - pass msg via a0 in stop
 - comment
 - clean
 - revert
 - stop
 - clean
 - clean
 - fix stop
 - ... and 7 more: https://git.openjdk.org/jdk/compare/99c299f0...53019e34

-------------

Changes: https://git.openjdk.org/jdk/pull/26101/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26101&range=03
  Stats: 125 lines in 8 files changed: 100 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26101/head:pull/26101

PR: https://git.openjdk.org/jdk/pull/26101

From mli at openjdk.org  Mon Jul 14 11:46:22 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Jul 2025 11:46:22 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v5]
In-Reply-To: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
Message-ID: <h0ZyE415swdEnNQeSp7P64_tU2seeXdx4OMY7BbfJ08=.f0ccc394-597e-4936-94cc-53d817ed087b@github.com>

> Hi,
> Can you help to review this patch?
> 
> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
> 
> Riscv should support these features and resolve relative issues.
> 
> ## Test
> 
> ### jtreg
> 
> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
> 
> ### Performance
> 
> perf command to run the simplest Hello world java program:
> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
> 
> perf data:
> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
> 
> Thanks

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/26101/files
  - new: https://git.openjdk.org/jdk/pull/26101/files/53019e34..a65abed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26101&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26101&range=03-04

  Stats: 15 lines in 2 files changed: 6 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26101/head:pull/26101

PR: https://git.openjdk.org/jdk/pull/26101

From duke at openjdk.org  Mon Jul 14 13:35:02 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Mon, 14 Jul 2025 13:35:02 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v5]
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <VI_EFhZgZuRRPvSciHmWxZ0NLn6p--5tQ-kAdA416E0=.3e08bb6f-f9db-41b9-a517-2f2a80e26424@github.com>

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

Guanqiang Han 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:

 - Update full name
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - update regression test
 - Update Test8358592.java
   
   run on x86_64
 - add regression test for JDK-8358592
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - 8358592: Assert in Assembler::ptest due to missing SSE42 support
   
   Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26151/files
  - new: https://git.openjdk.org/jdk/pull/26151/files/206e477a..563b4f7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26151&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26151&range=03-04

  Stats: 10054 lines in 299 files changed: 5581 ins; 1627 del; 2846 mod
  Patch: https://git.openjdk.org/jdk/pull/26151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26151/head:pull/26151

PR: https://git.openjdk.org/jdk/pull/26151

From duke at openjdk.org  Mon Jul 14 13:36:55 2025
From: duke at openjdk.org (Yuri Gaevsky)
Date: Mon, 14 Jul 2025 13:36:55 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v2]
In-Reply-To: <wqv9D6F-ipJoWEpblNuWN7tSu_DdAPBPBHpwgVFV4QU=.ac9aa726-4417-45ce-b2d7-06977f7d1d6f@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
 <wqv9D6F-ipJoWEpblNuWN7tSu_DdAPBPBHpwgVFV4QU=.ac9aa726-4417-45ce-b2d7-06977f7d1d6f@github.com>
Message-ID: <2x2Y0Lv8xTrsqTvZJN1oFXSnOxClarHWZXvuXcUs1fE=.428cbb6a-975f-448a-ae89-bfe991a6564a@github.com>

On Thu, 24 Apr 2025 17:27:39 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 with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - 8324124: RISC-V: implement _vectorizedMismatch intrinsic

.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3069641368

From shade at openjdk.org  Mon Jul 14 14:32:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 14:32:46 GMT
Subject: RFR: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <7gB06vNJlcgdo0wlmK7nzsFMt3mGru6dvjK90Sf9OQU=.2608b378-ff21-4820-bc5c-cd4644e6ac06@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [x] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `tier1`

`linux-x64-static` GHA failures look unrelated. Linux x86_64 server fastdebug `make test TEST=all` looks good. I am integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26270#issuecomment-3069825077

From shade at openjdk.org  Mon Jul 14 14:32:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Jul 2025 14:32:46 GMT
Subject: Integrated: 8361380: ARM32: Atomic stubs should be in pre-universe
In-Reply-To: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
References: <BKlY_37Jrq7gdKXTe8Dx9RO7fK9PD2qOeHANclhVgCU=.a3059ff1-1ef7-4e22-bada-f66ce34e5747@github.com>
Message-ID: <c5EIKJihFiOTNszP7M_X3uFC-8JOtEtxpvOkAvilox0=.e06158b4-9d65-4368-b3ef-79e92573770b@github.com>

On Fri, 11 Jul 2025 17:02:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more investigation.
> 
> Additional testing:
>  - [x] Linux ARM32 server fastdebug, reproducer does not fail anymore
>  - [x] Linux x86_64 Zero fastdebug, `bootcycle-images`
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `tier1`

This pull request has now been integrated.

Changeset: 6cff49c0
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cff49c0fe7f5fac2efe50ac51479d7ee964436a
Stats:     60 lines in 4 files changed: 28 ins; 30 del; 2 mod

8361380: ARM32: Atomic stubs should be in pre-universe

Co-authored-by: Andrew Dinn <adinn at openjdk.org>
Reviewed-by: kvn, adinn

-------------

PR: https://git.openjdk.org/jdk/pull/26270

From sparasa at openjdk.org  Mon Jul 14 17:30:42 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 14 Jul 2025 17:30:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
Message-ID: <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>

On Mon, 14 Jul 2025 08:15:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename to paired_push and paired_pop
>
> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 114:
> 
>> 112:         __ paired_push(rax);
>> 113:       }
>> 114:       __ paired_push(rcx);
> 
> Hi @vamsi-parasa , for consecutive push/pop we can use push2/pop2 and 16byte alignment can be  guaranteed using following technique 
> https://github.com/openjdk/jdk/pull/25351/files#diff-d5d721ebf93346ba66e81257e4f6c5e6268d59774313c61e97353c0dfbf686a5R94

Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?

Thanks,
Vamsi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2205447287

From vpaprotski at openjdk.org  Mon Jul 14 17:46:40 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Jul 2025 17:46:40 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
Message-ID: <OUqBL8hUqHNeYCVwHrMQf-PnhQPtNj50La_Z6hQNqTE=.c32f2e5f-a075-4d2e-afe5-6c378448f30b@github.com>

On Tue, 8 Jul 2025 22:44:55 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename to paired_push and paired_pop

My concerns have been addressed; thanks Vamsi for changing the names!

-------------

Marked as reviewed by vpaprotski (Author).

PR Review: https://git.openjdk.org/jdk/pull/25889#pullrequestreview-3017232260

From vpaprotski at openjdk.org  Mon Jul 14 17:56:42 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 14 Jul 2025 17:56:42 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
 <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
Message-ID: <9OjuCgSkGnhRtf-nqXBbTu74RaaoySY7JMRaaJ0kaIY=.5575082f-2048-4d03-a8e1-3c23f916f8db@github.com>

On Mon, 14 Jul 2025 17:27:35 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 114:
>> 
>>> 112:         __ paired_push(rax);
>>> 113:       }
>>> 114:       __ paired_push(rcx);
>> 
>> Hi @vamsi-parasa , for consecutive push/pop we can use push2/pop2 and 16byte alignment can be  guaranteed using following technique 
>> https://github.com/openjdk/jdk/pull/25351/files#diff-d5d721ebf93346ba66e81257e4f6c5e6268d59774313c61e97353c0dfbf686a5R94
>
> Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?
> 
> Thanks,
> Vamsi

I like the current approach, unless we can come up with a very 'visually-low-overhead' way of adding extra alignment (i.e. this current change is across quite a few files, rather not complicate it). At most, perhaps something like `MacroAssembler::push_align()/MacroAssembler::pop_align()`, but I really rather not add more to this PR; It touches quite a few places so I like it being simpler.

As it stands, if nothing else, its clear from the `if` statement that existing path is left unmodified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2205494234

From lmesnik at openjdk.org  Mon Jul 14 17:58:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Jul 2025 17:58:40 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <qWzZIrbgSewZGqws1NFnY88b76jpDqb-QfNHDJyPwBk=.69e511eb-2206-45a9-89c5-5c432bd475eb@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

ping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-3070458885

From kvn at openjdk.org  Mon Jul 14 18:21:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 14 Jul 2025 18:21:41 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v5]
In-Reply-To: <VI_EFhZgZuRRPvSciHmWxZ0NLn6p--5tQ-kAdA416E0=.3e08bb6f-f9db-41b9-a517-2f2a80e26424@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <VI_EFhZgZuRRPvSciHmWxZ0NLn6p--5tQ-kAdA416E0=.3e08bb6f-f9db-41b9-a517-2f2a80e26424@github.com>
Message-ID: <zvWINLgxifTb5eNz4kvO6_4C21pFRAyKqbIKUNGAE-g=.ea9703a1-3dc9-4402-85a5-475666e64704@github.com>

On Mon, 14 Jul 2025 13:35:02 GMT, Guanqiang Han <duke at openjdk.org> wrote:

>> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
>> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
>> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
>> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
>> The above code causes the ptest instruction to be invoked.
>> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
>> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
>> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
>> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
>> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
>> all of these above cause this issue.
>> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.
>
> Guanqiang Han 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:
> 
>  - Update full name
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - update regression test
>  - Update Test8358592.java
>    
>    run on x86_64
>  - add regression test for JDK-8358592
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>    
>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

Okay, forget about other flags. My proposal regarding SSE4_2 for re-writing was because we should not have such sets under specific CPU's families.  SSE4_2 features bit set regardless that: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L2930

We also check `supports_sse4_2` outside CPUs specific codes for `UseCRC32CIntrinsics` for example.
Originally only Intel supported, that is why it was placed there. And then code was copied for AMD. We don't need to do it separately.

An other reason to put such code under specific CPU if on other cpus it is slow/broken. sse4_2 is very old, I think we should not worry about that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3070533726

From coleenp at openjdk.org  Mon Jul 14 19:49:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 14 Jul 2025 19:49:39 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <VSuaNfGYSzgbO0keged87fN9sULvgHtSLc0i31IhcFY=.04b9d1b3-aa9c-457b-a267-2ee94124040f@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

I was wondering if scimark ever found JVM bugs, but I think it's also run in the SPECjvm tests, like in bug [JDK-8352317](https://bugs.openjdk.org/browse/JDK-8352317). But this doesn't need Scimark.java.  Is this right?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-3017560379

From lmesnik at openjdk.org  Mon Jul 14 21:29:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 14 Jul 2025 21:29:44 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <BxoobONIku6_Zs9ocsh3wvAAZrD7_X5T5zsCed6CxBk=.e0015949-a5fd-47e7-8c50-811931f1be9d@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

the scimark has never been found any issues, it was needed as an example af aritfactory usage in openjdk
The problem is that scimark itself has a a bug that can lead to test failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-3071040360

From sspitsyn at openjdk.org  Mon Jul 14 21:46:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 14 Jul 2025 21:46:41 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
 <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
Message-ID: <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>

On Fri, 11 Jul 2025 22:18:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: minor tweak of previous change
>>  - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
>>  - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>>  - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>>  - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
>>  - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method
>
> src/hotspot/share/prims/jvmti.xml line 5904:
> 
>> 5902:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 5903:           The implementation is unable to get the frame locals
>> 5904:           (e.g. the frame at <code>depth</code> is executing a native method).
> 
> Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT .
> 
> For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads.

Thank you for the concern. But I'm kind of puzzled with your observation.
The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads.
Though I wonder if it also was the case before virtual thread support was added.

The `VM_BaseGetOrSetLocal::doit()` have the following checks in place:


void VM_BaseGetOrSetLocal::doit() {
  . . .
  frame fr = _jvf->fr();
  if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
    _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations
    return;
  }
  Method* method = _jvf->method();
  if (getting_receiver()) {
    if (method->is_static()) {
      _result = JVMTI_ERROR_INVALID_SLOT;   ### This check is for GetLocalInstance
      return;
    }
  } else {
    if (method->is_native()) {
      _result = JVMTI_ERROR_OPAQUE_FRAME;   ### This check is before calls to
                               ### check_slot_type_no_lvt() and check_slot_type_lvt()
      return;
    }
    if (!check_slot_type_no_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
      return;
    }
    if (method->has_localvariable_table() &&
        !check_slot_type_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
      return;
    }
  }
  . . .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2205878604

From iklam at openjdk.org  Mon Jul 14 22:39:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Jul 2025 22:39:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
Message-ID: <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>

On Tue, 8 Jul 2025 21:25:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
>> 
>> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
>> 
>> Testing:
>>  - modified existing regression test
>>  - tiers 1-4
>> 
>> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
>> 
>> Thanks
>> 
>> PS. The diff is much smaller if you disable whitespace differences.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix weird logic - requested by Coleen

The changes look reasonable to me.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26122#pullrequestreview-3017999789

From dholmes at openjdk.org  Mon Jul 14 22:39:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:39:40 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
 <59TWztBno7U4Y_y3NEHqbpcC3i7tcLVqTk0xEbQErzc=.0f79114c-d276-4a22-824a-3e3c262b925c@github.com>
Message-ID: <qDPDff8_pLYs1-Z1ouI6APXTWo2g67OGTF_ymPwZ09E=.419636f7-c4e7-4483-8e3a-e398bd4d05e9@github.com>

On Tue, 8 Jul 2025 22:37:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix weird logic - requested by Coleen
>
> Looks good.

Thanks for the review @coleenp !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26122#issuecomment-3054992667

From dholmes at openjdk.org  Mon Jul 14 22:56:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:56:45 GMT
Subject: RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?= [v3]
In-Reply-To: <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
 <S8h6abDBVIYEXswCi8IRPCFvaBbX5-ZE6WbfeFMJ2NE=.e9e9baba-6563-4403-a2c0-a7235dc13a3b@github.com>
 <MenQZS-xUNAiy4Tp62bA25wm1esPHUl8xmLQOP8JjLk=.e831b960-33d9-429b-86db-111896a8884a@github.com>
Message-ID: <OvtXXAKX7K45s86pfmWsPJq8O_C8FiLksoGGjpmmV3s=.c2393b4e-ae66-44f7-9068-af2c5742e0c3@github.com>

On Mon, 14 Jul 2025 22:36:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix weird logic - requested by Coleen
>
> The changes look reasonable to me.

Thanks for the review @iklam !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26122#issuecomment-3071267381

From dholmes at openjdk.org  Mon Jul 14 22:56:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Jul 2025 22:56:45 GMT
Subject: Integrated: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
References: <8Dh9B06hDuORGQ-uufrbswlGw9ABFFCA62sCJSUnJaY=.6498b7e8-a39b-43f0-a76f-a0ed9aea3905@github.com>
Message-ID: <Gm2z_rBIPlUUJgbPkdf82_vyFEk5VOIbG-yak87OLKo=.403e3189-f7e3-4270-9583-d14285e2f6a0@github.com>

On Thu, 3 Jul 2025 22:11:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092) (way back in JDK 10) we elided loader constraint checks for overpass methods related to default methods by skipping them when initializing the itable for the interface. But that was the wrong place to do that. The overpass method is setup when there is a resolution/selection error so that the correct exception is thrown if the problematic method is invoked (like the ICCE reporting conflicting methods) and by eliding that entry we instead get the `AbstractMethhodError`.
> 
> The fix here is to revert that change from [JDK-8186092](https://bugs.openjdk.org/browse/JDK-8186092), and to address the loader constraint problem by adding the same check for overpass methods in `klassItable::check_constraints` that exists for `klassVtable::check_constraints`.
> 
> Testing:
>  - modified existing regression test
>  - tiers 1-4
> 
> EDIT: originally there was a new regression test for this, but this area is already covered by the `vmTestBase` "`defmeth` tests. That test was missing the necessary invocation modes to expose the bug, so they have been added.
> 
> Thanks
> 
> PS. The diff is much smaller if you disable whitespace differences.

This pull request has now been integrated.

Changeset: f36147b3
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d
Stats:     71 lines in 2 files changed: 12 ins; 2 del; 57 mod

8356942: invokeinterface?Throws?AbstractMethodError?Instead of?IncompatibleClassChangeError

Reviewed-by: coleenp, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/26122

From cjplummer at openjdk.org  Mon Jul 14 23:25:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 14 Jul 2025 23:25:39 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
 <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
 <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>
Message-ID: <CubpXtvaLT6zJyemLm3JGfL_-uj9BxQqBSyDOqdcyJs=.75bc2b7e-9331-4bb9-8416-986074f2e1dc@github.com>

On Mon, 14 Jul 2025 21:42:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 5904:
>> 
>>> 5902:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>>> 5903:           The implementation is unable to get the frame locals
>>> 5904:           (e.g. the frame at <code>depth</code> is executing a native method).
>> 
>> Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT .
>> 
>> For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads.
>
> Thank you for the concern. But I'm kind of puzzled with your observation.
> The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads.
> Though I wonder if it also was the case before virtual thread support was added.
> 
> The `VM_BaseGetOrSetLocal::doit()` have the following checks in place:
> 
> 
> void VM_BaseGetOrSetLocal::doit() {
>   . . .
>   frame fr = _jvf->fr();
>   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
>     _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations
>     return;
>   }
>   Method* method = _jvf->method();
>   if (getting_receiver()) {
>     if (method->is_static()) {
>       _result = JVMTI_ERROR_INVALID_SLOT;   ### This check is for GetLocalInstance
>       return;
>     }
>   } else {
>     if (method->is_native()) {
>       _result = JVMTI_ERROR_OPAQUE_FRAME;   ### This check is before calls to
>                                ### check_slot_type_no_lvt() and check_slot_type_lvt()
>       return;
>     }
>     if (!check_slot_type_no_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
>       return;
>     }
>     if (method->has_localvariable_table() &&
>         !check_slot_type_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
>       return;
>     }
>   }
>   . . .

My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details.

It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal.

So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2205981269

From dholmes at openjdk.org  Tue Jul 15 00:37:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Jul 2025 00:37:05 GMT
Subject: [jdk25] RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
Message-ID: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>

Hi all,

This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.

Thanks!

-------------

Commit messages:
 - Backport f36147b3263662229e9a0ec712b9748711d2d85d

Changes: https://git.openjdk.org/jdk/pull/26304/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26304&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356942
  Stats: 71 lines in 2 files changed: 12 ins; 2 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/26304.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26304/head:pull/26304

PR: https://git.openjdk.org/jdk/pull/26304

From iklam at openjdk.org  Tue Jul 15 01:23:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Jul 2025 01:23:39 GMT
Subject: [jdk25] RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
References: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
Message-ID: <yVHTVO7pTqITxNMjWqVxWtoEQ5SIhyy50aJ-5T5yFmM=.199e45c9-a47b-4206-b4b4-f9dc6bee54c9@github.com>

On Tue, 15 Jul 2025 00:31:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.
> 
> Thanks!

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26304#pullrequestreview-3018227204

From dholmes at openjdk.org  Tue Jul 15 02:02:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Jul 2025 02:02:48 GMT
Subject: [jdk25] RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <yVHTVO7pTqITxNMjWqVxWtoEQ5SIhyy50aJ-5T5yFmM=.199e45c9-a47b-4206-b4b4-f9dc6bee54c9@github.com>
References: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
 <yVHTVO7pTqITxNMjWqVxWtoEQ5SIhyy50aJ-5T5yFmM=.199e45c9-a47b-4206-b4b4-f9dc6bee54c9@github.com>
Message-ID: <kmzgenXgrzdWGU0OgjZ5mBuk69V-GVuCHU0rFIIoHfY=.9352822c-1b47-4d1b-9191-87e4d52255f3@github.com>

On Tue, 15 Jul 2025 01:20:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.
>> 
>> Thanks!
>
> Marked as reviewed by iklam (Reviewer).

Thanks for the review @iklam !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26304#issuecomment-3071644574

From fyang at openjdk.org  Tue Jul 15 02:26:39 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Jul 2025 02:26:39 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <6Nju2tXHfHz0pucBcl6eSCwx7oQZXvDczTmoHKlJr4o=.0089e8c6-446e-4a21-8cd3-226516547d63@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
 <Xk8pi5GoYYqXVsbYT5Tvt5xz8VxeFEa3g6LL2qjMnyo=.59d5fc9b-83d2-48ea-aa5a-9d1f2362521a@github.com>
 <6Nju2tXHfHz0pucBcl6eSCwx7oQZXvDczTmoHKlJr4o=.0089e8c6-446e-4a21-8cd3-226516547d63@github.com>
Message-ID: <_LOcxXBh2-PB1auCoLLwCuQ8SlSvGg9XQZVJaG49ViY=.472e8e8e-08f7-464a-b0ff-a84d772f6dca@github.com>

On Mon, 14 Jul 2025 10:25:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 800:
>> 
>>> 798:   push_reg(RegSet::of(t1, xmethod), sp);   // push << t1 & xmethod >> to sp
>>> 799:   movptr(t1, RuntimeAddress(entry_point), t0);
>>> 800:   jalr(t1);
>> 
>> This movptr + jalr sequence could be further simplified into `rt_call(entry_point)`, which could help save one add instruction.
>
> Not sure if I understand your suggestion right.
> If we use `rt_call` here, it will only call into `movptr1`, whose instructions is one longer than `movptr2`.

Ah, yes. I think you are right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26101#discussion_r2206144302

From fyang at openjdk.org  Tue Jul 15 02:47:40 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Jul 2025 02:47:40 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v5]
In-Reply-To: <h0ZyE415swdEnNQeSp7P64_tU2seeXdx4OMY7BbfJ08=.f0ccc394-597e-4936-94cc-53d817ed087b@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <h0ZyE415swdEnNQeSp7P64_tU2seeXdx4OMY7BbfJ08=.f0ccc394-597e-4936-94cc-53d817ed087b@github.com>
Message-ID: <nBmGvEI2eFd2RKAj-1azDYD5yE8JsgwTaCpR2QT1K9Y=.de2d6829-e095-4b05-a583-9f7269c68e7c@github.com>

On Mon, 14 Jul 2025 11:46:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache.
>> 
>> Riscv should support these features and resolve relative issues.
>> 
>> ## Test
>> 
>> ### jtreg
>> 
>> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. 
>> 
>> ### Performance
>> 
>> perf command to run the simplest Hello world java program:
>> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed
>> 
>> perf data:
>> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% )
>> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% )
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

The updated changes seems fine to me. But I am not an AOT expert.
I agree with @adinn that it might be more reasonable & safer to implement this in the Leyden premain branch. I see the Leyden people are upstreaming work regularly. Especially, this enables existing AOT tests which might break if we cannot sync in time with latest work in that branch which may involve more tweaks on the CPU side and bring more AOT tests.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26101#pullrequestreview-3018329436

From sspitsyn at openjdk.org  Tue Jul 15 03:02:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 03:02:38 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <CubpXtvaLT6zJyemLm3JGfL_-uj9BxQqBSyDOqdcyJs=.75bc2b7e-9331-4bb9-8416-986074f2e1dc@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
 <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
 <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>
 <CubpXtvaLT6zJyemLm3JGfL_-uj9BxQqBSyDOqdcyJs=.75bc2b7e-9331-4bb9-8416-986074f2e1dc@github.com>
Message-ID: <Oarlb75pfGnT-RQ7rJMJ0at7OCWURYnspHDYrMGWHdY=.7bdb8a17-0ba9-4c85-acb6-bea5f0db07c7@github.com>

On Mon, 14 Jul 2025 23:23:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thank you for the concern. But I'm kind of puzzled with your observation.
>> The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads.
>> Though I wonder if it also was the case before virtual thread support was added.
>> 
>> The `VM_BaseGetOrSetLocal::doit()` have the following checks in place:
>> 
>> 
>> void VM_BaseGetOrSetLocal::doit() {
>>   . . .
>>   frame fr = _jvf->fr();
>>   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
>>     _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations
>>     return;
>>   }
>>   Method* method = _jvf->method();
>>   if (getting_receiver()) {
>>     if (method->is_static()) {
>>       _result = JVMTI_ERROR_INVALID_SLOT;   ### This check is for GetLocalInstance
>>       return;
>>     }
>>   } else {
>>     if (method->is_native()) {
>>       _result = JVMTI_ERROR_OPAQUE_FRAME;   ### This check is before calls to
>>                                ### check_slot_type_no_lvt() and check_slot_type_lvt()
>>       return;
>>     }
>>     if (!check_slot_type_no_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
>>       return;
>>     }
>>     if (method->has_localvariable_table() &&
>>         !check_slot_type_lvt(_jvf)) {    ### This has checks for JVMTI_ERROR_INVALID_SLOT
>>       return;
>>     }
>>   }
>>   . . .
>
> My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details.
> 
> It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal.
> 
> So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed.

Okay, thanks. This sounds right. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206180435

From lmesnik at openjdk.org  Tue Jul 15 03:07:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 03:07:38 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() !=
 nullptr) failed: incomplete state
Message-ID: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>

The problem happens if post_early_vm_start is triggered.
The fix is to complete initialization once threadObj become available.

I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

-------------

Commit messages:
 - fixed comments after feedback, some polishing
 - 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state

Changes: https://git.openjdk.org/jdk/pull/26303/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362203
  Stats: 19 lines in 4 files changed: 17 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303

PR: https://git.openjdk.org/jdk/pull/26303

From sspitsyn at openjdk.org  Tue Jul 15 03:07:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 03:07:39 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <KhzttswHgxSHJiNJo18ov4XBArr5fGIQTn81T4faxO8=.83557385-698f-4076-8a12-ed9859980107@github.com>

On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

Changes requested by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiExport.cpp line 678:

> 676:   EVT_TRIG_TRACE(JVMTI_EVENT_VM_START, ("Trg VM start event triggered" ));
> 677: 
> 678:   // The thread state might be incomplete if initialized in post_early_vm_start

Nit: Better to say "The JvmtiThreadState might be incomplete" to avoid confusion with other means of thread state.

src/hotspot/share/prims/jvmtiThreadState.cpp line 1045:

> 1043: 
> 1044: void JvmtiThreadState::update_thread_oop(JavaThread* thread) {
> 1045:   assert(thread->threadObj() != nullptr, "Should threadObj be already initialized");

Nit: Better just to say: "Sanity check".

-------------

PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3018124707
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206025058
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206028317

From lmesnik at openjdk.org  Tue Jul 15 03:07:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 03:07:40 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <reTCv2Giu82-Bzbn7bsxcxS2YZCeb7-MzM5Zbg4qox4=.67ece044-053d-4862-9486-f2de19f7eb08@github.com>

On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

I renamed function just to make clear that it should be used once in startup phase.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26303#issuecomment-3071735984

From lmesnik at openjdk.org  Tue Jul 15 03:07:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 03:07:40 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state
In-Reply-To: <KhzttswHgxSHJiNJo18ov4XBArr5fGIQTn81T4faxO8=.83557385-698f-4076-8a12-ed9859980107@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <KhzttswHgxSHJiNJo18ov4XBArr5fGIQTn81T4faxO8=.83557385-698f-4076-8a12-ed9859980107@github.com>
Message-ID: <znZ88fTm01YCWRpTJx4FhKxGGMHIJIc4iqs7smfn1QM=.3000d1ab-17d2-4096-8231-46427ad1ec75@github.com>

On Tue, 15 Jul 2025 00:17:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The problem happens if post_early_vm_start is triggered.
>> The fix is to complete initialization once threadObj become available.
>> 
>> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.
>
> src/hotspot/share/prims/jvmtiExport.cpp line 678:
> 
>> 676:   EVT_TRIG_TRACE(JVMTI_EVENT_VM_START, ("Trg VM start event triggered" ));
>> 677: 
>> 678:   // The thread state might be incomplete if initialized in post_early_vm_start
> 
> Nit: Better to say "The JvmtiThreadState might be incomplete" to avoid confusion with other means of thread state.

updated

> src/hotspot/share/prims/jvmtiThreadState.cpp line 1045:
> 
>> 1043: 
>> 1044: void JvmtiThreadState::update_thread_oop(JavaThread* thread) {
>> 1045:   assert(thread->threadObj() != nullptr, "Should threadObj be already initialized");
> 
> Nit: Better just to say: "Sanity check".

updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206182954
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206182861

From sspitsyn at openjdk.org  Tue Jul 15 03:08:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 03:08:41 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
 <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
Message-ID: <V1TMme-MF1Ya0e28EMd2Dlsnl08myghyXR5Ic9VPpuw=.57200d59-5b98-4dd7-b968-ae5bc080f081@github.com>

On Thu, 10 Jul 2025 21:11:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: minor tweak of previous change
>
> src/hotspot/share/prims/jvmti.xml line 6233:
> 
>> 6231:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>> 6232:           The implementation is unable to set the frame locals
>> 6233:           (e.g. the frame at <code>depth</code> is executing a native method).
> 
> The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here.

@plummercj  Please, let me know if I've addressed your concern or you still want a spec update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206185378

From cjplummer at openjdk.org  Tue Jul 15 03:14:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Jul 2025 03:14:38 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <Oarlb75pfGnT-RQ7rJMJ0at7OCWURYnspHDYrMGWHdY=.7bdb8a17-0ba9-4c85-acb6-bea5f0db07c7@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
 <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
 <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>
 <CubpXtvaLT6zJyemLm3JGfL_-uj9BxQqBSyDOqdcyJs=.75bc2b7e-9331-4bb9-8416-986074f2e1dc@github.com>
 <Oarlb75pfGnT-RQ7rJMJ0at7OCWURYnspHDYrMGWHdY=.7bdb8a17-0ba9-4c85-acb6-bea5f0db07c7@github.com>
Message-ID: <x2q7bmt5plziwAt8YH_Pl6B1ZwaiRCNfKhcAn7adMDM=.ca7d1ad9-4fe0-45c2-82ec-4a7f5876fc29@github.com>

On Tue, 15 Jul 2025 03:00:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details.
>> 
>> It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal.
>> 
>> So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed.
>
> Okay, thanks. This sounds right. ?

...but JDWP might need some work. StackFrame.SetValues and GetValues only mentions OPAQUE_FRAME for SetValues of a virtual thread. However, I don't think there is anything to prevent them being called on a native frame. You might expect INVALID_SLOT in that case because it would not be possible to specify a valid slot for a local when there are none, but from the code you gave above it looks like slot checks are made after the native method check. So if a combination of a native method and invalid slot results in OPAQUE_FRAME, then we need to update the JDWP spec to reflect this. The other choice is to make JVMTI return INVALID_SLOT when the method is native.

And speaking of INVALID_SLOT, it missing in the JDWP spec for SetValues, but is there for GetValues. It seems that should be fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206190118

From cjplummer at openjdk.org  Tue Jul 15 03:22:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Jul 2025 03:22:39 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
Message-ID: <16umPXOVTbR55u-y9vmxOv4Vb-laTixA-0g2jin80Rw=.651ed95b-aca9-41b3-9c7a-27982ca1c9a8@github.com>

On Fri, 11 Jul 2025 20:08:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI spec sections:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>>   - `GetLocal<Type>`
>>   - `SetLocal<Type>`
>>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>>   
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn 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
>  - review: minor tweak of previous change
>  - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
>  - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>  - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>  - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
>  - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26111#pullrequestreview-3018370144

From cjplummer at openjdk.org  Tue Jul 15 03:22:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Jul 2025 03:22:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <V1TMme-MF1Ya0e28EMd2Dlsnl08myghyXR5Ic9VPpuw=.57200d59-5b98-4dd7-b968-ae5bc080f081@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
 <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
 <V1TMme-MF1Ya0e28EMd2Dlsnl08myghyXR5Ic9VPpuw=.57200d59-5b98-4dd7-b968-ae5bc080f081@github.com>
Message-ID: <HjrX5cKDjN0mTb5_j8bd6-YUkwX1fykM5LyAOicUqGo=.16dbc986-09e9-422e-8187-e6aa1fa7e182@github.com>

On Tue, 15 Jul 2025 03:06:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 6233:
>> 
>>> 6231:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
>>> 6232:           The implementation is unable to set the frame locals
>>> 6233:           (e.g. the frame at <code>depth</code> is executing a native method).
>> 
>> The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here.
>
> @plummercj  Please, let me know if I've addressed your concern or you still want a spec update.

Yes, I think it looks fine. I thought the section you referred to that clarifies virtual threads was only for GetLocalXXX, but I see now it is also for SetLocalXXX.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206196187

From sspitsyn at openjdk.org  Tue Jul 15 04:27:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 04:27:44 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v6]
In-Reply-To: <HjrX5cKDjN0mTb5_j8bd6-YUkwX1fykM5LyAOicUqGo=.16dbc986-09e9-422e-8187-e6aa1fa7e182@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <L1QBbGKQ7rd3Rs9AReR_k0M2g3xRXL1fOq8cR5uN0Os=.87eb92e6-75fe-439f-b013-30b38443122b@github.com>
 <fk0uLMywfsxj6RJH843JMOgwO14fxpjuBGkf8qzdyHU=.7e19646e-fba9-402a-b48e-7de1570f286c@github.com>
 <V1TMme-MF1Ya0e28EMd2Dlsnl08myghyXR5Ic9VPpuw=.57200d59-5b98-4dd7-b968-ae5bc080f081@github.com>
 <HjrX5cKDjN0mTb5_j8bd6-YUkwX1fykM5LyAOicUqGo=.16dbc986-09e9-422e-8187-e6aa1fa7e182@github.com>
Message-ID: <TFKMDcCHOUalKnV7wyfHUicSA45snxCyBx7Xiw95yxA=.a1da7267-74ef-4882-880b-3db0116f40a4@github.com>

On Tue, 15 Jul 2025 03:19:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @plummercj  Please, let me know if I've addressed your concern or you still want a spec update.
>
> Yes, I think it looks fine. I thought the section you referred to that clarifies virtual threads was only for GetLocalXXX, but I see now it is also for SetLocalXXX.

Okay, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206257447

From sspitsyn at openjdk.org  Tue Jul 15 04:38:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 04:38:41 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <x2q7bmt5plziwAt8YH_Pl6B1ZwaiRCNfKhcAn7adMDM=.ca7d1ad9-4fe0-45c2-82ec-4a7f5876fc29@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
 <iBVJx62x5Da2N-DIJOumhnh4KrndBwP3SPziYYaLVxE=.332ba71b-e304-4187-9e15-299207af16fb@github.com>
 <W6un8zypMy1mz9n4lLzJqm5-IM400OKKFgkggWA_9Nw=.fa5495c0-51be-49b6-87a9-7294e07d32d6@github.com>
 <CubpXtvaLT6zJyemLm3JGfL_-uj9BxQqBSyDOqdcyJs=.75bc2b7e-9331-4bb9-8416-986074f2e1dc@github.com>
 <Oarlb75pfGnT-RQ7rJMJ0at7OCWURYnspHDYrMGWHdY=.7bdb8a17-0ba9-4c85-acb6-bea5f0db07c7@github.com>
 <x2q7bmt5plziwAt8YH_Pl6B1ZwaiRCNfKhcAn7adMDM=.ca7d1ad9-4fe0-45c2-82ec-4a7f5876fc29@github.com>
Message-ID: <EgiwqGdEc45nCyvBb10YJlU6SDqvlLEpm3HNXiPDzeY=.95f638ab-d574-4e10-a246-a1043c1b7879@github.com>

On Tue, 15 Jul 2025 03:12:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> So if a combination of a native method and invalid slot results in OPAQUE_FRAME, then we need to update the JDWP spec to reflect this.

Agreed

> And speaking of INVALID_SLOT, it missing in the JDWP spec for SetValues, but is there for GetValues. It seems that should be fixed.

Agreed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206313896

From sspitsyn at openjdk.org  Tue Jul 15 04:38:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 04:38:40 GMT
Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method [v7]
In-Reply-To: <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
 <Ao8bBCg7SPv4QQopdOFmTfYXuNPNn5pQ6a8FzT-_TNY=.8abc0f14-cb93-47da-a3e7-7cf172dadb08@github.com>
Message-ID: <kuEDe2x_eK8QQgKGvSoAG9CmJ3j1Hy58RjPOEdSrAjA=.8aefaee9-86c1-4700-aaba-eb219ad2f417@github.com>

On Fri, 11 Jul 2025 20:08:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI spec sections:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>>   - `GetLocal<Type>`
>>   - `SetLocal<Type>`
>>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>>   
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn 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
>  - review: minor tweak of previous change
>  - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
>  - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>  - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>  - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
>  - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

Thank you for review, Chris!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26111#issuecomment-3071864368

From duke at openjdk.org  Tue Jul 15 06:26:09 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Tue, 15 Jul 2025 06:26:09 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v6]
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

Guanqiang Han 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:

 - move UseSSE42Intrinsics check outside of the CPU-specific sections
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - Update full name
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - update regression test
 - Update Test8358592.java
   
   run on x86_64
 - add regression test for JDK-8358592
 - Merge remote-tracking branch 'upstream/master' into 8358592
 - 8358592: Assert in Assembler::ptest due to missing SSE42 support
   
   Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26151/files
  - new: https://git.openjdk.org/jdk/pull/26151/files/563b4f7a..1154c860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26151&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26151&range=04-05

  Stats: 3717 lines in 99 files changed: 436 ins; 3035 del; 246 mod
  Patch: https://git.openjdk.org/jdk/pull/26151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26151/head:pull/26151

PR: https://git.openjdk.org/jdk/pull/26151

From duke at openjdk.org  Tue Jul 15 06:32:42 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Tue, 15 Jul 2025 06:32:42 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v5]
In-Reply-To: <zvWINLgxifTb5eNz4kvO6_4C21pFRAyKqbIKUNGAE-g=.ea9703a1-3dc9-4402-85a5-475666e64704@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <VI_EFhZgZuRRPvSciHmWxZ0NLn6p--5tQ-kAdA416E0=.3e08bb6f-f9db-41b9-a517-2f2a80e26424@github.com>
 <zvWINLgxifTb5eNz4kvO6_4C21pFRAyKqbIKUNGAE-g=.ea9703a1-3dc9-4402-85a5-475666e64704@github.com>
Message-ID: <0yhFrQLXtOcrVwpcYy5KRlkYkSH4URW0xN7On3eNIes=.23c36be6-1c03-4c3d-9dbd-2f6f09057ca0@github.com>

On Mon, 14 Jul 2025 18:18:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Guanqiang Han 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:
>> 
>>  - Update full name
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - update regression test
>>  - Update Test8358592.java
>>    
>>    run on x86_64
>>  - add regression test for JDK-8358592
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>>    
>>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.
>
> Okay, forget about other flags. My proposal regarding SSE4_2 for re-writing was because we should not have such sets under specific CPU's families.  SSE4_2 features bit set regardless that: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L2930
> 
> We also check `supports_sse4_2` outside CPUs specific codes for `UseCRC32CIntrinsics` for example.
> Originally only Intel supported, that is why it was placed there. And then code was copied for AMD. We don't need to do it separately.
> 
> An other reason to put such code under specific CPU if on other cpus it is slow/broken. sse4_2 is very old, I think we should not worry about that.

hi @vnkozlov , Thank you for the clarification and background ? that makes sense.

I?ve also reviewed the code, and I agree that supports_sse4_2 can be moved outside of the CPU-specific sections. However, I?d suggest applying this change only for the UseCRC32CIntrinsics flag at this time. Some of the other flags depend not only on supports_sse4_2, but also on additional conditions or CPU-specific characteristics. To avoid unintended side effects and to keep the change minimal and well-scoped, I think it?s safer to limit the refactoring to this one flag for now.

Let me know if that sounds good to you ? I can update the patch accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3072183557

From sspitsyn at openjdk.org  Tue Jul 15 07:22:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Jul 2025 07:22:39 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <pDotH5TKHs1HV7YmcSdiJ6n1W6awwy5CtPYStiTSO_c=.3e80748b-8aca-4860-b976-83ba8793bf1d@github.com>

On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

This looks good in general. Thank you for catching with Kitchensink and fixing this issue!
I've posted a couple of nits.

src/hotspot/share/prims/jvmtiThreadState.cpp line 1046:

> 1044: void JvmtiThreadState::update_thread_oop_during_vm_start(JavaThread* thread) {
> 1045:   assert(thread->threadObj() != nullptr, "santity check");
> 1046:   if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {

Nit: Replace `thread->jvmti_thread_state()->get_thread_oop()` with `get_thread_oop()`.

src/hotspot/share/prims/jvmtiThreadState.cpp line 1047:

> 1045:   assert(thread->threadObj() != nullptr, "santity check");
> 1046:   if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {
> 1047:     _thread_oop_h.release(JvmtiExport::jvmti_oop_storage());

Nit: This line needs a comment explaining we are releasing an `OopHandle` pointing to `null`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3019013676
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206621244
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206627052

From lmesnik at openjdk.org  Tue Jul 15 07:57:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 07:57:53 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v2]
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <TPzpcVEI9YLOllMvwelmlxTEXXdKTVFBI4XLRpFzv3M=.b7cc3c35-2fc5-4fac-8efd-fcadbc80ae1e@github.com>

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  simplified the update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26303/files
  - new: https://git.openjdk.org/jdk/pull/26303/files/19e76aa9..a8d5e277

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=00-01

  Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303

PR: https://git.openjdk.org/jdk/pull/26303

From lmesnik at openjdk.org  Tue Jul 15 07:57:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 07:57:53 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v2]
In-Reply-To: <pDotH5TKHs1HV7YmcSdiJ6n1W6awwy5CtPYStiTSO_c=.3e80748b-8aca-4860-b976-83ba8793bf1d@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <pDotH5TKHs1HV7YmcSdiJ6n1W6awwy5CtPYStiTSO_c=.3e80748b-8aca-4860-b976-83ba8793bf1d@github.com>
Message-ID: <6N3jM4b8JwxgRo-TaPTtKotne-noij-EFc0ZuPA9Suo=.b30387b7-8564-4871-946f-1a115db7d89d@github.com>

On Tue, 15 Jul 2025 07:17:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified the update
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 1046:
> 
>> 1044: void JvmtiThreadState::update_thread_oop_during_vm_start(JavaThread* thread) {
>> 1045:   assert(thread->threadObj() != nullptr, "santity check");
>> 1046:   if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {
> 
> Nit: Replace `thread->jvmti_thread_state()->get_thread_oop()` with `get_thread_oop()`.

I realised that thread is already in this state, so no need to set it as a parameter.

> src/hotspot/share/prims/jvmtiThreadState.cpp line 1047:
> 
>> 1045:   assert(thread->threadObj() != nullptr, "santity check");
>> 1046:   if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {
>> 1047:     _thread_oop_h.release(JvmtiExport::jvmti_oop_storage());
> 
> Nit: This line needs a comment explaining we are releasing an `OopHandle` pointing to `null`.

I realized that  there is replace method and use it instead of release/update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206722425
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206725694

From coleenp at openjdk.org  Tue Jul 15 11:39:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 11:39:39 GMT
Subject: [jdk25] RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
References: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
Message-ID: <PGV9QMCAXaGGP0zXI3umdii5eMblnLtUhwUv1rouuT4=.3bd31b22-526a-4e03-b622-836421fbbabe@github.com>

On Tue, 15 Jul 2025 00:31:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.
> 
> Thanks!

Backport looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26304#pullrequestreview-3019925077

From coleenp at openjdk.org  Tue Jul 15 12:13:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Jul 2025 12:13:42 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <MNP_vi0hZXvmnPctCEW8m4R-VQfO6wcRikz0TggRhTQ=.2d64d5d1-7b96-4be9-a37a-2e35de559c9e@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

Okay, looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-3020022181

From xpeng at openjdk.org  Tue Jul 15 15:07:57 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 15 Jul 2025 15:07:57 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v8]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <i_M9Ho3c8ZisGId8wN9N4uzuuH6kKteTMJFuABn8naY=.5da5aacb-6fc5-4c25-b93e-564aece85859@github.com>

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> For the test, I have manually tested different GCs with Flight Recording enabled and verified the events:
> G1:
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0108 ms
>   gcId = 0
>   gcWorkerId = 8
>   name = "Termination"
>   eventThread = "GC Thread#4" (osThreadId = 20483)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0467 ms
>   gcId = 0
>   gcWorkerId = 2
>   name = "Termination"
>   eventThread = "GC Thread#2" (osThreadId = 21251)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0474 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination"
>   eventThread = "GC Thread#8" (osThreadId = 36359)
> }
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000834 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000166 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> 
> Shenandoah: 
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0202 ms
>   gcId = 0
>   gcWorkerId = 0
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0205 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0127 ms
>   gcId = 0
>   gcWorkerId = 5
>   name = "Termination: Final Mark"
>   eventThread = "Shenandoah G...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Fix jft test failure
 - Merge branch 'master' into JDK-8354555
 - Patch to fix the PR concerns
 - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
 - Add include "workerThread.hpp"
 - Touch up
 - ... and 22 more: https://git.openjdk.org/jdk/compare/b65fdf5a...7dd5ebf5

-------------

Changes: https://git.openjdk.org/jdk/pull/24676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=07
  Stats: 90 lines in 10 files changed: 68 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

PR: https://git.openjdk.org/jdk/pull/24676

From tschatzl at openjdk.org  Tue Jul 15 15:22:19 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Jul 2025 15:22:19 GMT
Subject: RFR: 8347051: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
Message-ID: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>

Hi all,

  please review this small fix to the man pages that previously stated that `UseNUMA` is only available with Parallel GC. To minimize future update problems, the text has been modified to just say that the default value is dependent on the collector.

Testing: local compilation

Thanks,
  Thomas

-------------

Commit messages:
 - 8347051

Changes: https://git.openjdk.org/jdk/pull/26321/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26321&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347051
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26321/head:pull/26321

PR: https://git.openjdk.org/jdk/pull/26321

From duke at openjdk.org  Tue Jul 15 16:53:51 2025
From: duke at openjdk.org (duke)
Date: Tue, 15 Jul 2025 16:53:51 GMT
Subject: Withdrawn: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <Hs6lFryNvYGFsTS74rEt9x0REX3yKAGpPOUneVsNCx8=.64dbf973-9d6e-4625-9588-d4495d46a6e9@github.com>
References: <Hs6lFryNvYGFsTS74rEt9x0REX3yKAGpPOUneVsNCx8=.64dbf973-9d6e-4625-9588-d4495d46a6e9@github.com>
Message-ID: <3A3M8QTIFNcWepv6AF85ylIFyLToxvdA7WBzWNKpePM=.aa3a76ee-806c-4527-adb6-faeb0b9ac2ad@github.com>

On Tue, 25 Feb 2025 21:52:48 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this addition of an internal benchmark, mostly of interest to those working with NMT.
> 
> This benchmark allows us to record a pattern of memory allocation operations (i.e. `malloc`, `realloc` and `free`) as well as the virtual memory allocations (i.e. `VirtualMemoryTracker::add_reserved_region`, etc.) and record those into files.
> 
> Later we can use that recording to _play back_ the pattern with different code or settings to compare the performance (i.e. memory usage as well as time).
> 
> The goal of this benchmark is for anyone working on NMT to be able to measure and prove whether their improvement helps or regresses the performance.
> 
> ### To use it:
> 
> To record pattern of allocations of memory calls:
> 
> `NMTRecordMemoryAllocations=0x7FFFFFFF ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> OR to record pattern of allocations of virtual memory calls:
> 
> `NMTRecordVirtualMemoryAllocations=0x7FFFFFFF ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will result in the file:
> -  hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> OR
> - hs_nmt_pid22770_virtual_allocs_record.log (is the chronological record of the desired operations)
> 
> And 2 additional files:
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> 
> then to actually run the benchmark:
> 
> NMTBenchmarkRecordedPID=22770 ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary
> 
> ### Usage:
> 
> See the issue for more details and the design document.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23786

From kvn at openjdk.org  Tue Jul 15 16:56:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 15 Jul 2025 16:56:44 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v6]
In-Reply-To: <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>
Message-ID: <jvo0B19JENlUr6jALcW0C323_dxPl0WDvPLo5O-UG5w=.b40d907c-b8bb-4b51-8500-7f84318978ac@github.com>

On Tue, 15 Jul 2025 06:26:09 GMT, Guanqiang Han <duke at openjdk.org> wrote:

>> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
>> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
>> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
>> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
>> The above code causes the ptest instruction to be invoked.
>> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
>> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
>> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
>> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
>> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
>> all of these above cause this issue.
>> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.
>
> Guanqiang Han 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:
> 
>  - move UseSSE42Intrinsics check outside of the CPU-specific sections
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - Update full name
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - update regression test
>  - Update Test8358592.java
>    
>    run on x86_64
>  - add regression test for JDK-8358592
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>    
>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

Looks good

src/hotspot/cpu/x86/vm_version_x86.cpp line 1637:

> 1635:         }
> 1636:       } else {
> 1637:         if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) {

Ha, there was bug in all these checks: checking `UseAESIntrinsics` instead of `UseSSE42Intrinsics`!

Thank you for fixing it in your changes

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26151#pullrequestreview-3021263315
PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2208025830

From kbarrett at openjdk.org  Tue Jul 15 17:01:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Jul 2025 17:01:02 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17
In-Reply-To: <XZ0eput8Sd6wpIquG_2qHBiSAkUhkYPdhwYtteiPhRo=.f30af8b1-9d92-4794-85f8-57957fa51d0c@github.com>
References: <XZ0eput8Sd6wpIquG_2qHBiSAkUhkYPdhwYtteiPhRo=.f30af8b1-9d92-4794-85f8-57957fa51d0c@github.com>
Message-ID: <nrnCtnFVyYXorTLRQ4IasCtwgwtLN6jRGg66OOQYcPI=.fb44587a-e13a-4635-b5e2-6e7377a574fe@github.com>

On Thu, 26 Jun 2025 02:01:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can
> be more easily structured and captured than bare email. Once discussion
> settles down I'll turn the results into HotSpot Style Guide changes. I don't
> intend to integrate any version of this document to the OpenJDK repository.

Any comments?  I know a lot of Oracle folks are on vacation, but I got
comments from many of them before making this public.

If I don't hear anything soon-ish I'm going to proceed as if everyone likes this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25992#issuecomment-3074432992

From thartmann at openjdk.org  Tue Jul 15 18:12:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 15 Jul 2025 18:12:21 GMT
Subject: [jdk25] RFR: 8361952: Installation of MethodData::extra_data_lock()
 misses synchronization on reader side
Message-ID: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>

Hi all,

This pull request contains a backport of commit [272e66d0](https://github.com/openjdk/jdk/commit/272e66d017a3497d9af4df6f042c741ad8a59dd6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Thomas Schatzl on 14 Jul 2025 and was reviewed by Aleksey Shipilev, Coleen Phillimore and David Holmes.

Thanks!

-------------

Commit messages:
 - Backport 272e66d017a3497d9af4df6f042c741ad8a59dd6

Changes: https://git.openjdk.org/jdk/pull/26326/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361952
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26326/head:pull/26326

PR: https://git.openjdk.org/jdk/pull/26326

From drwhite at openjdk.org  Tue Jul 15 18:16:39 2025
From: drwhite at openjdk.org (Derek White)
Date: Tue, 15 Jul 2025 18:16:39 GMT
Subject: RFR: 8347052: Update java man page documentation to reflect
 current state of the UseNUMA flag
In-Reply-To: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
References: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
Message-ID: <C9kqM4ydhlscL2LHa_NVL_l_qSJlmtZ94hNQ2wws9pQ=.465857f8-49db-417a-b06b-e6a003f9dca0@github.com>

On Tue, 15 Jul 2025 15:16:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to the man pages that previously stated that `UseNUMA` is only available with Parallel GC. To minimize future update problems, the text has been modified to just say that the default value is dependent on the collector.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Looks good. Thanks Thomas.

Marked as reviewed by drwhite (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26321#pullrequestreview-3021721154
PR Review: https://git.openjdk.org/jdk/pull/26321#pullrequestreview-3021722192

From amenkov at openjdk.org  Tue Jul 15 18:42:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Jul 2025 18:42:40 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v2]
In-Reply-To: <TPzpcVEI9YLOllMvwelmlxTEXXdKTVFBI4XLRpFzv3M=.b7cc3c35-2fc5-4fac-8efd-fcadbc80ae1e@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <TPzpcVEI9YLOllMvwelmlxTEXXdKTVFBI4XLRpFzv3M=.b7cc3c35-2fc5-4fac-8efd-fcadbc80ae1e@github.com>
Message-ID: <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com>

On Tue, 15 Jul 2025 07:57:53 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problem happens if post_early_vm_start is triggered.
>> The fix is to complete initialization once threadObj become available.
>> 
>> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified the update

test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java line 32:

> 30:  * @run main/othervm/native -agentlib:AllowedFunctions AllowedFunctions
> 31:  * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart AllowedFunctions
> 32:  * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart  -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n AllowedFunctions

Do I understand correctly this test case reproduces the issue?
- there is extra space before `-Xrunjdwp`
- would be better to use automatic port (address=0) to avoid "port in use"
- need to update (c) years in the file

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2208336956

From vyazici at openjdk.org  Tue Jul 15 19:21:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:28 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:

 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/6af98646..7c042b35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=00-01

  Stats: 14 lines in 5 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Tue Jul 15 19:21:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:29 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <Jx0DTrwcRbgYJzQ0rbfBGQhVy1OEVU2gFJDAh32YpcQ=.07327b3c-e0b0-4a93-9d9e-03416abde256@github.com>

On Mon, 14 Jul 2025 08:49:44 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/opto/c2_globals.hpp line 666:
> 
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
>> 666:           "Verify that Java level checks in intrinsics work as expected")   \
> 
> To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

Changed as suggested in c331fbfa.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208455093

From vyazici at openjdk.org  Tue Jul 15 19:27:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:27:44 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <pnD36-qHKsrbrg38-Znz4lP8Erb06nrjkamauxQ8PPw=.d9f91fbe-d4de-499e-8b39-4e5283456ba8@github.com>

On Mon, 14 Jul 2025 10:27:45 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 417:
> 
>> 415:                                                                                                                         \
>> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
>> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \
> 
> It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

Fixed in 7c042b35.

I completely agree with your point. In fact, I'm opposed to _"vertical alignment"_ due to its obvious maintainability and version control hygiene issues. Alas, that is the existing style, and I tried to adhere to it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208469532

From mli at openjdk.org  Tue Jul 15 19:29:42 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 15 Jul 2025 19:29:42 GMT
Subject: RFR: 8360000: RISC-V: implement aot [v2]
In-Reply-To: <2wMV3f3LhAT16le7lOvo1G4HMuGBHMVMg56257cf3qw=.10dfc519-b499-4cb6-8a6c-ecfe23e8879c@github.com>
References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com>
 <66eX3pwSY50dL4CBv8YjeN4uxcFa4PBaPF5hOHI9WM4=.8c3a650f-8888-4f5d-97c8-ba707a49b61f@github.com>
 <2wMV3f3LhAT16le7lOvo1G4HMuGBHMVMg56257cf3qw=.10dfc519-b499-4cb6-8a6c-ecfe23e8879c@github.com>
Message-ID: <yhA1RYzotgesu1j_Y_CLBytXzEvwSWfC3Suu7OKdgDE=.c8d0868e-159b-4664-82a9-2e08749bac5f@github.com>

On Mon, 7 Jul 2025 12:29:44 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - pass msg via a0 in stop
>>  - comment
>
> @Hamlin-Li @RealFYang I think it might be better to discuss this with on the leyden-dev mailing list before trying to implement the changes needed to match what has been done for AArch64 and x86_64. One good reason for caution is that the Leyden premain project is planning to add further code save/restore capabilities to mainline that have already been prototyped in the Leyden premain branch. So, if you enable AOT code cache initialization for RISCV then you will need to be able/ready to provide all the other parts of the implementation when they arrive.
> 
> It might be safer to implement what is needed in premain (or in a downstream clone) after discussing both what is needed and why it is needed with the Leyden devs. It would also help if you were to use the testing and benchmark programs that the project is using to check that the aot code cache is working correctly and actually boosting performance.

> The updated changes seems fine to me. But I am not an AOT expert. I agree with @adinn that it might be more reasonable & safer to implement this in the Leyden premain branch. I see the Leyden people are upstreaming work regularly. Especially, this enables existing AOT tests which might break if we cannot sync in time with latest work in that branch which may involve more tweaks on the CPU side and bring more AOT tests.

Thank you for reviewing.

I've sent an email to the leyden-dev to discuss the port of aot on riscv last week, till now received no response.

I think both @adinn and @RealFYang are right in the sense of stability.
I'll keep an eye on discussion and pr in leyden-dev, and as it's not enable by default (i.e. you need to record/create/use aot explicilty), seems we are still safe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26101#issuecomment-3075207551

From vyazici at openjdk.org  Tue Jul 15 19:31:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:31:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <wgs1GVG69QfKChew9MwaIrJQx4aVaEXnhs1P0rqa3FE=.60f3724b-d34e-4604-9b2b-86352e4c5049@github.com>

On Mon, 14 Jul 2025 09:11:08 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:
> 
>> 6012: }
>> 6013: 
>> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII
> 
> Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

No, we don't. Since Markdown has become ubiquitous in text-based typesetting, I find it easier to read and, whenever needed, share it in other mediums; Slack, GitHub, JIRA, Javadoc, Microsoft Office 365, Google Docs, etc. I presume you prefer without backticks ? removed them in b60ff457.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208477825

From vyazici at openjdk.org  Tue Jul 15 19:34:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:34:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <0Rbm6JuupxK9iYkXljWRpmdCAg_fmf_92FUckntpQ3A=.7c633679-c46c-4395-8431-8564301b0dbb@github.com>

On Mon, 14 Jul 2025 10:32:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> I left a couple of minor comments. I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

@dafedafe, thanks so much for the review! I've implemented the changes you requested, and shared some benchmark figures in the associated ticket. I am still actively working on evaluating the performance impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075223785

From rriggs at openjdk.org  Tue Jul 15 19:50:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:50:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
Message-ID: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>

On Tue, 15 Jul 2025 19:21:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag

src/java.base/share/classes/java/lang/StringCoding.java line 36:

> 34: import static java.util.Objects.requireNonNull;
> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
Just import Preconditions.

src/java.base/share/classes/java/lang/StringCoding.java line 162:

> 160:             if (c > '\u00FF')
> 161:                 break;
> 162:             da[dp++] = (byte) c;

Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
Here and at line 195:

src/java.base/share/classes/java/lang/StringCoding.java line 189:

> 187: 
> 188:     @IntrinsicCandidate
> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {

I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
Suggestion:

    private static int encodeAsciiArray0(char[] sa, int sp, 
                                         byte[] da, int dp, int len) {

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:

> 41: import static java.util.Objects.requireNonNull;
> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:

> 175:                 if (c > '\u00FF')
> 176:                     break;
> 177:                 da[dp++] = (byte) c;

Revert extra space.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:

> 199:             int len  = (dlen < slen) ? dlen : slen;
> 200:             try {
> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);

Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208470957
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208491363
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208494207
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208503099
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208504829
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208510343

From vyazici at openjdk.org  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici 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 remote-tracking branch 'upstream/master' into strIntrinCheck
 - Apply review feedback (styling changes)
 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
 - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
   
   This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
 - Improve intrinsics in `StringCoding`
 - Add `StringCodingCountPositives` benchmark
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b424f31d...85f19864

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/7c042b35..85f19864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=01-02

  Stats: 7104 lines in 199 files changed: 2886 ins; 3418 del; 800 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <ugG_C0UBIiUOJV2vcib89uno7vn292iwp3rvVwMfQA4=.e30be329-5eee-4587-961d-8453bf1b3ce3@github.com>

On Tue, 15 Jul 2025 19:25:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/java/lang/StringCoding.java line 36:
> 
>> 34: import static java.util.Objects.requireNonNull;
>> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
> Just import Preconditions.

Fixed in 2672f7c1ada.

> src/java.base/share/classes/java/lang/StringCoding.java line 162:
> 
>> 160:             if (c > '\u00FF')
>> 161:                 break;
>> 162:             da[dp++] = (byte) c;
> 
> Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
> Here and at line 195:

I've actually made these changes to match the code shared in intrinsics, e.g., `macroAssembler_x86.cpp`. Reverted them in 2672f7c1ada as you requested.

> src/java.base/share/classes/java/lang/StringCoding.java line 189:
> 
>> 187: 
>> 188:     @IntrinsicCandidate
>> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 
> I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
> Suggestion:
> 
>     private static int encodeAsciiArray0(char[] sa, int sp, 
>                                          byte[] da, int dp, int len) {

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:
> 
>> 41: import static java.util.Objects.requireNonNull;
>> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:
> 
>> 175:                 if (c > '\u00FF')
>> 176:                     break;
>> 177:                 da[dp++] = (byte) c;
> 
> Revert extra space.

Changed as requested in 2672f7c1ada.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208575103
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208578241
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579144
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579489
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579689

From vyazici at openjdk.org  Tue Jul 15 20:26:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:26:41 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>

On Tue, 15 Jul 2025 19:45:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
> 
>> 199:             int len  = (dlen < slen) ? dlen : slen;
>> 200:             try {
>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
> 
> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208585771

From rriggs at openjdk.org  Tue Jul 15 20:32:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 20:32:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
 <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
Message-ID: <97fQvq2H2iV-UmT7CnECiBAza6fhFXdexNzkyPOaThc=.482af2ba-78a5-4201-b1b5-476d24c93f39@github.com>

On Tue, 15 Jul 2025 20:24:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
>> 
>>> 199:             int len  = (dlen < slen) ? dlen : slen;
>>> 200:             try {
>>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
>> 
>> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).
>
> I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

The wrapper is the method actually called, the intrinsic `encodeISOArray0` intrinsic would be inlined into it.
I don't have a compelling reason to change it, given the solitary caller.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208599130

From dholmes at openjdk.org  Tue Jul 15 20:59:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Jul 2025 20:59:44 GMT
Subject: [jdk25] RFR: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <PGV9QMCAXaGGP0zXI3umdii5eMblnLtUhwUv1rouuT4=.3bd31b22-526a-4e03-b622-836421fbbabe@github.com>
References: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
 <PGV9QMCAXaGGP0zXI3umdii5eMblnLtUhwUv1rouuT4=.3bd31b22-526a-4e03-b622-836421fbbabe@github.com>
Message-ID: <EKQicavj9cfYIka3BIXvcfIg7BBZzZSCOeg5gd4Y1_U=.ed145923-5ab0-45bc-ae0d-5286af3ee3f2@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.
>> 
>> Thanks!
>
> Backport looks good.

Thanks @coleenp !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26304#issuecomment-3075609273

From dholmes at openjdk.org  Tue Jul 15 20:59:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Jul 2025 20:59:45 GMT
Subject: [jdk25] Integrated: 8356942:
 =?UTF-8?B?aW52b2tlaW50ZXJmYWNlwqBUaHJvd3PCoEFic3RyYWN0TWV0aG9kRXJyb3LCoEluc3RlYWQ=?=
 =?UTF-8?B?IA==?= =?UTF-8?B?b2bCoEluY29tcGF0aWJsZUNsYXNzQ2hhbmdlRXJyb3I=?=
In-Reply-To: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
References: <rxOom4yb4zYARHmXRSPcmT_bp072u2Vx6Qvg5yCxR-g=.c1f59fbe-9984-48e0-9794-1094987bff90@github.com>
Message-ID: <Eva4gb51Au62tz6V-KIeR3JYKQnYoSYjuq325Rh81cU=.59854982-7db9-4b86-8a0b-3fbb11dba811@github.com>

On Tue, 15 Jul 2025 00:31:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f36147b3](https://github.com/openjdk/jdk/commit/f36147b3263662229e9a0ec712b9748711d2d85d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 14 Jul 2025 and was reviewed by Coleen Phillimore and Ioi Lam.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 03a67a96
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03a67a969b938dced45917c39491442c460eb7ac
Stats:     71 lines in 2 files changed: 12 ins; 2 del; 57 mod

8356942: invokeinterface?Throws?AbstractMethodError?Instead of?IncompatibleClassChangeError

Reviewed-by: iklam, coleenp
Backport-of: f36147b3263662229e9a0ec712b9748711d2d85d

-------------

PR: https://git.openjdk.org/jdk/pull/26304

From rriggs at openjdk.org  Tue Jul 15 21:52:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 21:52:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <K5Vuk4SylBZ50flNAkTaUQp6fkTGYVcxiK5ZUuo9pxE=.7ecf49f9-00d0-4052-82ec-898125113034@github.com>

On Tue, 15 Jul 2025 20:24:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/611f6cea...85f19864

Looks good, thanks for the updates.
A Hotspot reviewer should approve also.

/Reviewers 2 reviewer

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3022453251
PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075835741

From duke at openjdk.org  Tue Jul 15 22:44:43 2025
From: duke at openjdk.org (duke)
Date: Tue, 15 Jul 2025 22:44:43 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v6]
In-Reply-To: <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>
Message-ID: <I-8p-U1eIJI0q-HFVOOes1HD7r5X7AoG_umf48B-pB0=.4154e936-7790-4aa7-b3ed-920e075ac749@github.com>

On Tue, 15 Jul 2025 06:26:09 GMT, Guanqiang Han <duke at openjdk.org> wrote:

>> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
>> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
>> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
>> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
>> The above code causes the ptest instruction to be invoked.
>> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
>> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
>> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
>> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
>> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
>> all of these above cause this issue.
>> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.
>
> Guanqiang Han 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:
> 
>  - move UseSSE42Intrinsics check outside of the CPU-specific sections
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - Update full name
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - update regression test
>  - Update Test8358592.java
>    
>    run on x86_64
>  - add regression test for JDK-8358592
>  - Merge remote-tracking branch 'upstream/master' into 8358592
>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>    
>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.

@hgqxjj 
Your change (at version 1154c860782324419c2f47405228ac6e0fc22f27) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3075969920

From duke at openjdk.org  Tue Jul 15 22:44:44 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Tue, 15 Jul 2025 22:44:44 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v6]
In-Reply-To: <jvo0B19JENlUr6jALcW0C323_dxPl0WDvPLo5O-UG5w=.b40d907c-b8bb-4b51-8500-7f84318978ac@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <9aDiLYe4J8MqfMVbgOk7xD9l4y7UKWerElzJPRzo5vE=.b4f3240d-303a-45b7-bf5a-6d2add2ac9e4@github.com>
 <jvo0B19JENlUr6jALcW0C323_dxPl0WDvPLo5O-UG5w=.b40d907c-b8bb-4b51-8500-7f84318978ac@github.com>
Message-ID: <WPZklyLqpbIoBiljLysLIIYA-yky6547F-0gg58d6lg=.bda9db84-c14c-4f0a-ab70-85888021361f@github.com>

On Tue, 15 Jul 2025 16:51:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Guanqiang Han 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:
>> 
>>  - move UseSSE42Intrinsics check outside of the CPU-specific sections
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - Update full name
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - update regression test
>>  - Update Test8358592.java
>>    
>>    run on x86_64
>>  - add regression test for JDK-8358592
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>>    
>>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1637:
> 
>> 1635:         }
>> 1636:       } else {
>> 1637:         if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) {
> 
> Ha, there was bug in all these checks: checking `UseAESIntrinsics` instead of `UseSSE42Intrinsics`!
> 
> Thank you for fixing it in your changes

@vnkozlov 
You're welcome! I noticed the inconsistency while reviewing the existing logic, so I thought it?d be good to fix it as part of this cleanup.

Glad it helps!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26151#discussion_r2208844858

From duke at openjdk.org  Tue Jul 15 22:47:41 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Tue, 15 Jul 2025 22:47:41 GMT
Subject: RFR: 8358592: Assert in Assembler::ptest due to missing SSE42
 support [v5]
In-Reply-To: <zvWINLgxifTb5eNz4kvO6_4C21pFRAyKqbIKUNGAE-g=.ea9703a1-3dc9-4402-85a5-475666e64704@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
 <VI_EFhZgZuRRPvSciHmWxZ0NLn6p--5tQ-kAdA416E0=.3e08bb6f-f9db-41b9-a517-2f2a80e26424@github.com>
 <zvWINLgxifTb5eNz4kvO6_4C21pFRAyKqbIKUNGAE-g=.ea9703a1-3dc9-4402-85a5-475666e64704@github.com>
Message-ID: <Ua7IdqJGod49iXiblg6gzUHlEkaw6xct9I4uC4YZDEA=.3ddbb647-60c5-4c0d-86f1-0d0d53273e8d@github.com>

On Mon, 14 Jul 2025 18:18:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Guanqiang Han 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:
>> 
>>  - Update full name
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - update regression test
>>  - Update Test8358592.java
>>    
>>    run on x86_64
>>  - add regression test for JDK-8358592
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>>    
>>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.
>
> Okay, forget about other flags. My proposal regarding SSE4_2 for re-writing was because we should not have such sets under specific CPU's families.  SSE4_2 features bit set regardless that: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L2930
> 
> We also check `supports_sse4_2` outside CPUs specific codes for `UseCRC32CIntrinsics` for example.
> Originally only Intel supported, that is why it was placed there. And then code was copied for AMD. We don't need to do it separately.
> 
> An other reason to put such code under specific CPU if on other cpus it is slow/broken. sse4_2 is very old, I think we should not worry about that.

@vnkozlov Thanks a lot for the review.

The PR has been integrated ? I?d really appreciate your sponsorship when you have a moment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3075976404

From sviswanathan at openjdk.org  Tue Jul 15 23:22:41 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 15 Jul 2025 23:22:41 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
Message-ID: <7ldMQV8jpynvbli7ioHwQCB-_y0LkwphDmxKqu5r9E0=.9cfc493b-64cd-48aa-82c6-bc3c4b680814@github.com>

On Tue, 8 Jul 2025 22:44:55 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename to paired_push and paired_pop

src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 112:

> 110:     } else {
> 111:       if (_result != rax) {
> 112:         __ paired_push(rax);

No need to use paired_push on this else path as it is for non APX.

src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 198:

> 196:       }
> 197:     } else {
> 198:       __ paired_pop(r11);

No need to use paired pop on this else path as this is for non-APX.

src/hotspot/cpu/x86/vm_version_x86.cpp line 156:

> 154:     // rcx and rdx are first and second argument registers on windows
> 155: 
> 156:     __ paired_push(rbp);

We should not use paired push/pop in vm_version_x86.cpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2208843869
PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2208845470
PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2208815480

From lmesnik at openjdk.org  Tue Jul 15 23:37:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 23:37:55 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v3]
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26303/files
  - new: https://git.openjdk.org/jdk/pull/26303/files/a8d5e277..739b0c1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303

PR: https://git.openjdk.org/jdk/pull/26303

From lmesnik at openjdk.org  Tue Jul 15 23:41:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Jul 2025 23:41:39 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v2]
In-Reply-To: <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <TPzpcVEI9YLOllMvwelmlxTEXXdKTVFBI4XLRpFzv3M=.b7cc3c35-2fc5-4fac-8efd-fcadbc80ae1e@github.com>
 <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com>
Message-ID: <D17r4zvQVJ-WDGh11h7QOSNTV7TGkwG96znCAPP59A0=.16610c07-c843-4392-b341-e3c0a526152d@github.com>

On Tue, 15 Jul 2025 18:40:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplified the update
>
> test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java line 32:
> 
>> 30:  * @run main/othervm/native -agentlib:AllowedFunctions AllowedFunctions
>> 31:  * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart AllowedFunctions
>> 32:  * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart  -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n AllowedFunctions
> 
> Do I understand correctly this test case reproduces the issue?
> - there is extra space before `-Xrunjdwp`
> - would be better to use automatic port (address=0) to avoid "port in use"
> - need to update (c) years in the file

Thanks, I updated port, indentation and years.
Yes, it is the testcase reproducing the issue. It provokes asserition described in the issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2208900621

From sparasa at openjdk.org  Tue Jul 15 23:56:33 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 15 Jul 2025 23:56:33 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v3]
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <JiApmm0yPr7avMKSs9dTAnToA1FVMBwOfMW60zX__KI=.a2a3dcf0-b3c0-4a99-8c69-cb6762ff02b5@github.com>

> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
> 
> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
> 
> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  remove pushp/popp from vm_version_x86 and also when APX is not being used

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25889/files
  - new: https://git.openjdk.org/jdk/pull/25889/files/24e6da2c..2cc7c4b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25889&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25889&range=01-02

  Stats: 42 lines in 2 files changed: 0 ins; 0 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/25889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25889/head:pull/25889

PR: https://git.openjdk.org/jdk/pull/25889

From sparasa at openjdk.org  Tue Jul 15 23:56:34 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 15 Jul 2025 23:56:34 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <7ldMQV8jpynvbli7ioHwQCB-_y0LkwphDmxKqu5r9E0=.9cfc493b-64cd-48aa-82c6-bc3c4b680814@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <7ldMQV8jpynvbli7ioHwQCB-_y0LkwphDmxKqu5r9E0=.9cfc493b-64cd-48aa-82c6-bc3c4b680814@github.com>
Message-ID: <cat_t3Pe1dJ7D_lacYjbIau0ywD9x0e0SOPvxZpLjrs=.ea752a47-d72d-4d4d-b0c0-45a2bc4a303f@github.com>

On Tue, 15 Jul 2025 22:41:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename to paired_push and paired_pop
>
> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 198:
> 
>> 196:       }
>> 197:     } else {
>> 198:       __ paired_pop(r11);
> 
> No need to use paired pop on this else path as this is for non-APX.

Thanks for the catch! Removed the pushp/popp for the non-APX else path in the updated code.

> src/hotspot/cpu/x86/vm_version_x86.cpp line 156:
> 
>> 154:     // rcx and rdx are first and second argument registers on windows
>> 155: 
>> 156:     __ paired_push(rbp);
> 
> We should not use paired push/pop in vm_version_x86.cpp.

Please see the updated code removing the pushp/popp from vm_version_x86.cpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2208915438
PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2208913711

From amenkov at openjdk.org  Wed Jul 16 00:01:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Jul 2025 00:01:41 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v3]
In-Reply-To: <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>
Message-ID: <wmevR6NYEgNYlqL-WWndDx-TQUXsReUHKXpuNLmIlC8=.cd6c2206-88e1-42b7-a4ed-33fc51c956ad@github.com>

On Tue, 15 Jul 2025 23:37:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problem happens if post_early_vm_start is triggered.
>> The fix is to complete initialization once threadObj become available.
>> 
>> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed test

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3022656765

From sparasa at openjdk.org  Wed Jul 16 00:06:53 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 16 Jul 2025 00:06:53 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v4]
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <-V4hpHvXdaDjmEyYzHcEpDJ2bzPTqoz2Ao8FLobkmB8=.d9e3b962-ae8d-4e4b-8ddb-c3ab42a2a619@github.com>

> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
> 
> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
> 
> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.

Srinivas Vamsi Parasa 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 with master
 - remove pushp/popp from vm_version_x86 and also when APX is not being used
 - rename to paired_push and paired_pop
 - 8359965: Enable paired pushp and popp instruction usage for APX enabled CPUs

-------------

Changes: https://git.openjdk.org/jdk/pull/25889/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25889&range=03
  Stats: 341 lines in 22 files changed: 19 ins; 0 del; 322 mod
  Patch: https://git.openjdk.org/jdk/pull/25889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25889/head:pull/25889

PR: https://git.openjdk.org/jdk/pull/25889

From lmesnik at openjdk.org  Wed Jul 16 00:31:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Jul 2025 00:31:47 GMT
Subject: Integrated: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <fePKcKrkiJiAtJoETOAuJY7Cc9D5annncGdPMRCSjos=.147f29ae-aad2-432f-a88d-3a4ff10b91e5@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

This pull request has now been integrated.

Changeset: a5c9bc70
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453
Stats:     58 lines in 1 file changed: 0 ins; 58 del; 0 mod

8358004: Delete applications/scimark/Scimark.java test

Reviewed-by: syan, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/25316

From syan at openjdk.org  Wed Jul 16 02:53:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 02:53:25 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java test
Message-ID: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>

Hi all,

This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.

The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.

Thanks!

-------------

Commit messages:
 - Backport a5c9bc70324693e9d0b25bb2c51b91dfc750c453

Changes: https://git.openjdk.org/jdk/pull/26338/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358004
  Stats: 58 lines in 1 file changed: 0 ins; 58 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26338/head:pull/26338

PR: https://git.openjdk.org/jdk/pull/26338

From sspitsyn at openjdk.org  Wed Jul 16 03:35:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Jul 2025 03:35:48 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
Message-ID: <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>

On Fri, 11 Jul 2025 05:06:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Except I'm now discovering that can't work other than to abandon the virtual thread in question if you found the carrier has changed, otherwise you are in a handshake with the wrong carrier and so can't grab the stack - but that means you need to retry for this virtual thread.
>
> I see the current code just produces an empty stack trace if the virtual thread is found to have switched carriers. This seems wrong. We should be "pinning" the virtual thread whilst we try to get its stacktrace, such that it is unmounted or else mounted and fixed to a carrier. Other thread walking code uses the JvmtiVTMSTransitionDisabler to try and achieve this.

Sorry for being late to the party. I still need to walk through all the comments but it seems you have already caught the main problem with virtual threads. Nothing protects them from being concurrently mounted/unmounted/remounted. It is why the `JvmtiVTMSTransitionDisabler` is used in the JVMTI code. But, please, note that the `JvmtiVTMSTransitionDisabler` mechanism is enabled only when there is a JVMTI agent. Otherwise, it has been disabled for scalability purposes to exclude potentially high performance overhead at the VTMS transition points.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2209135122

From thartmann at openjdk.org  Wed Jul 16 05:32:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Jul 2025 05:32:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>

On Tue, 15 Jul 2025 20:24:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/32d96877...85f19864

Thanks a lot for working on this, Volkan! The changes look good to me, I just added two comments.

src/hotspot/share/opto/c2_globals.hpp line 665:

> 663:           "prints attempted and successful inlining of intrinsics")         \
> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \

We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

src/hotspot/share/opto/library_call.cpp line 971:

> 969:     } else {
> 970:       PreserveJVMState pjvms(this);
> 971:       set_control(_gvn.transform(bailout));

Suggestion:

    bailout = _gvn.transform(bailout);
    if (halt) {
      Node* frame = _gvn.transform(new ParmNode(C->start(), TypeFunc::FramePtr));
      Node* halt = _gvn.transform(new HaltNode(bailout, frame, "unexpected guard failure in intrinsic"));
      C->root()->add_req(halt);
    } else {
      PreserveJVMState pjvms(this);
      set_control(bailout);

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3023137214
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209259866
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209245394

From duke at openjdk.org  Wed Jul 16 05:34:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Jul 2025 05:34:54 GMT
Subject: Withdrawn: 8344270: Update tier1_common and hotspot_misc groups to
 better organize hotspot non-component tests
In-Reply-To: <HwmHlJBdtkCsNZB_K4Ap_5cLH0mxC8zGeMXpqH_FQ38=.73fadae6-64cb-4ae5-92ea-40b92e0870e7@github.com>
References: <HwmHlJBdtkCsNZB_K4Ap_5cLH0mxC8zGeMXpqH_FQ38=.73fadae6-64cb-4ae5-92ea-40b92e0870e7@github.com>
Message-ID: <yWWe92TapC0QWDh91OM94dlpdHRev95d-LWpOwplXlg=.d56972c7-8f9f-4119-9257-a96cf4f506d1@github.com>

On Tue, 6 May 2025 17:43:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Can you please review following PR that improve test groups.
> The bug was originally filed  to eliminate duplication between tier1_common and hotspot_misc test groups.  However while looked on the test content of these groups I realized that there are some other issues. 
> 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures.
> 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) 
> 3) testlibrary_tests and  sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds 
> 
> So tier1_common includes non-component tests that should be executed in tier1. 
> **all** sanity tests
> **all** gttest tests (were not all of them)
> testlibrary_tests (might be os/cpu specifc, so need to run them with all builds)
> source code checking tests (no need to run them an all builds, but it takes only few seconds)
> 
> And it doesn't makes any sense to execute  tier1_common with any external VM flags.
> 
> While hotspot_misc now includes on 2 sanity tests.  It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. 
> 
> The new test groups were added mostly to add comments explaining their specific.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25070

From duke at openjdk.org  Wed Jul 16 05:47:47 2025
From: duke at openjdk.org (Guanqiang Han)
Date: Wed, 16 Jul 2025 05:47:47 GMT
Subject: Integrated: 8358592: Assert in Assembler::ptest due to missing SSE42
 support
In-Reply-To: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
References: <1y8UZvyvFv1IHB_jS4bc1jnqvYdHtPfA_UMKY2Ljz2A=.53809e0b-6388-4c8f-a90e-b69400d9aaab@github.com>
Message-ID: <PB-ongBvwhMhQ_W0kJGPGBA4LbAm4hhfLk-IWIv-Abg=.e0e662c7-c6cb-4757-bdbd-5df64d3d28ed@github.com>

On Mon, 7 Jul 2025 02:52:10 GMT, Guanqiang Han <duke at openjdk.org> wrote:

> Setting "-XX:UseSSE=1" in command line prevents the code from entering the block shown below, which causes UseSSE42Intrinsics to not be correctly set. Because supports_sse3() return false.
> ![??1](https://github.com/user-attachments/assets/d3cdb1fe-f0e0-41dc-98c9-4427eaffdb0e)
> in addition , setting "-XX:+UseSSE42Intrinsics" in command line set UseVectorizedMismatchIntrinsic to True shown below.
> ![??2](https://github.com/user-attachments/assets/bbe623a3-453a-483d-b34c-1cdb394f2d4e)
> The above code causes the ptest instruction to be invoked.
> The assertion "assert(VM_Version::supports_sse4_1() || VM_Version::supports_avx(), "")" in ptest was triggered and caused the crash because of the following reason:
> Setting "-XX:UseSSE=1" in command line  cause "CPU_SSE4_1" was cleared and cause "VM_Version::supports_sse4_1()" return false ,related code as below:
> ![??3](https://github.com/user-attachments/assets/e9a8a690-dd4d-4216-b09f-be8439a9a73b)
> Setting "-XX:UseSSE=1" in command line  cause "UseAVX=0" and cause "VM_Version::supports_avx()" return false ,related code as below:
> ![image](https://github.com/user-attachments/assets/6d9e770b-0a7a-43cd-a4bc-d15247f6478e)
> all of these above cause this issue.
> i fix this issue by correcting UseSSE42Intrinsics to false when "UseSSE" in command line was set to 1, so that UseVectorizedMismatchIntrinsic will be set false and ptest was not triggered.

This pull request has now been integrated.

Changeset: e1b2229b
Author:    Guanqiang Han <yongheng_hgq at 126.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1b2229b0b1fe8560fcb1d6fc2cf01d69ed711ac
Stats:     79 lines in 2 files changed: 48 ins; 30 del; 1 mod

8358592: Assert in Assembler::ptest due to missing SSE42 support

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/jdk/pull/26151

From chagedorn at openjdk.org  Wed Jul 16 06:32:41 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Jul 2025 06:32:41 GMT
Subject: [jdk25] RFR: 8361952: Installation of
 MethodData::extra_data_lock() misses synchronization on reader side
In-Reply-To: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
References: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
Message-ID: <Fo_AoSciwkaNz4gGHWNg3QwPpYdgj_4SWd7DFoGghpU=.90ab3dbb-e30b-4fe0-a151-4ba517f13d48@github.com>

On Tue, 15 Jul 2025 18:06:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [272e66d0](https://github.com/openjdk/jdk/commit/272e66d017a3497d9af4df6f042c741ad8a59dd6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Schatzl on 14 Jul 2025 and was reviewed by Aleksey Shipilev, Coleen Phillimore and David Holmes.
> 
> Thanks!

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26326#pullrequestreview-3023350771

From thartmann at openjdk.org  Wed Jul 16 06:32:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Jul 2025 06:32:42 GMT
Subject: [jdk25] RFR: 8361952: Installation of
 MethodData::extra_data_lock() misses synchronization on reader side
In-Reply-To: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
References: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
Message-ID: <ADeaSyfzjpBkGo4_1UyXAzGQQVEAm6iwde5VwkWxfXw=.8858aa5f-90a2-4577-a4fb-bc0c3f8d5c75@github.com>

On Tue, 15 Jul 2025 18:06:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [272e66d0](https://github.com/openjdk/jdk/commit/272e66d017a3497d9af4df6f042c741ad8a59dd6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Schatzl on 14 Jul 2025 and was reviewed by Aleksey Shipilev, Coleen Phillimore and David Holmes.
> 
> Thanks!

Thanks Christian!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26326#issuecomment-3077065373

From thartmann at openjdk.org  Wed Jul 16 06:36:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Jul 2025 06:36:46 GMT
Subject: [jdk25] Integrated: 8361952: Installation of
 MethodData::extra_data_lock() misses synchronization on reader side
In-Reply-To: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
References: <ZfiXmOTbzGT0561C_KrUzWDPRjeZujQnPbnvoxPXpaA=.5fab9ae7-bff3-4661-8cf0-90ccc9d9ba60@github.com>
Message-ID: <0Yd-MdtkB_IvLw913CmNkq17oPUhsnGdvsHNjzsFjnM=.ca75f8b7-3266-41bb-bee4-49f86a0dceb5@github.com>

On Tue, 15 Jul 2025 18:06:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [272e66d0](https://github.com/openjdk/jdk/commit/272e66d017a3497d9af4df6f042c741ad8a59dd6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Schatzl on 14 Jul 2025 and was reviewed by Aleksey Shipilev, Coleen Phillimore and David Holmes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 60196a6b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60196a6b6f7bf5c0aac39cc02f65c454f7eb8dcf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361952: Installation of MethodData::extra_data_lock() misses synchronization on reader side

Reviewed-by: chagedorn
Backport-of: 272e66d017a3497d9af4df6f042c741ad8a59dd6

-------------

PR: https://git.openjdk.org/jdk/pull/26326

From sspitsyn at openjdk.org  Wed Jul 16 07:35:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Jul 2025 07:35:41 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
Message-ID: <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>

On Wed, 16 Jul 2025 03:33:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I see the current code just produces an empty stack trace if the virtual thread is found to have switched carriers. This seems wrong. We should be "pinning" the virtual thread whilst we try to get its stacktrace, such that it is unmounted or else mounted and fixed to a carrier. Other thread walking code uses the JvmtiVTMSTransitionDisabler to try and achieve this.
>
> Sorry for being late to the party. I still need to walk through all the comments but it seems you have already caught the main problem with virtual threads. Nothing protects them from being concurrently mounted/unmounted/remounted. It is why the `JvmtiVTMSTransitionDisabler` is used in the JVMTI code. But, please, note that the `JvmtiVTMSTransitionDisabler` mechanism is enabled only when there is a JVMTI agent. Otherwise, it has been disabled for scalability purposes to exclude potentially high performance overhead at the VTMS transition points.

With `JvmtiVTMSTransitionDisabler` there is normally no need in the carrier thread protection. A virtual thread is either mounted or unmounted. There is no carrier thread when virtual thread is unmounted. If virtual thread is mounted and VTMS transitions are disabled then the carrier thread is blocked until VTMS transitions are enabled again and the execution control is returned to the carrier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2209535782

From vyazici at openjdk.org  Wed Jul 16 07:51:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 07:51:26 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v4]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3L2KmYco1fW5Or9Lzhp17mW-Pk-ANOp5UYQ6sL3gZfs=.d7560969-8b3f-478f-a89d-2c34cf875ec9@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve `generate_string_range_check` changes
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/85f19864..2b89e880

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=02-03

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From dnsimon at openjdk.org  Wed Jul 16 08:43:49 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 08:43:49 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash
Message-ID: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>

This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

-------------

Commit messages:
 - fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

Changes: https://git.openjdk.org/jdk/pull/26346/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362306
  Stats: 68 lines in 5 files changed: 58 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From dnsimon at openjdk.org  Wed Jul 16 08:48:53 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 08:48:53 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/8c44d9ff..cca137a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From gdub at openjdk.org  Wed Jul 16 10:27:40 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 10:27:40 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
Message-ID: <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>

On Wed, 16 Jul 2025 08:48:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3000:

> 2998: }
> 2999: 
> 3000: C2V_VMENTRY_NULL(jobject, asReflectionField, (JNIEnv* env, jobject, ARGUMENT_PAIR(klass), jint index))

There is the same pattern in `getEncodedFieldAnnotationData`, we should probably defend there as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2209921506

From dnsimon at openjdk.org  Wed Jul 16 13:17:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 13:17:04 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - fixed bug in use of JVMCI traps
 - moved inject field check into check_field for benefit of get_encoded_annotation_data

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/cca137a3..c76efe51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=01-02

  Stats: 17 lines in 1 file changed: 8 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From dnsimon at openjdk.org  Wed Jul 16 13:17:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 13:17:04 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v2]
In-Reply-To: <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <QPWrs0RqLQbzToNUjlLNd49JQL6wWJFoKqL0shEJ1kQ=.7946aa77-6363-42d6-80a0-266043b8e6cc@github.com>
 <WJOsh4LepQ5kPY6xyd8m7jogFJvtPwQqaD_x01Z6lA8=.a3b71d6e-7c41-43ac-9ba1-ce8aae965aa6@github.com>
Message-ID: <XBJm4XJWGjaFGBkqE7N-D24GjXTXC3mLUtsYxjA3G4Q=.d903e1f4-29c0-43e2-9659-93d62746c17b@github.com>

On Wed, 16 Jul 2025 10:25:24 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

>> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   fixed bug in HotSpotJVMCIRuntime.getMirror for <clinit> and injected fields
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3000:
> 
>> 2998: }
>> 2999: 
>> 3000: C2V_VMENTRY_NULL(jobject, asReflectionField, (JNIEnv* env, jobject, ARGUMENT_PAIR(klass), jint index))
> 
> There is the same pattern in `getEncodedFieldAnnotationData`, we should probably defend there as well.

Good point: c2c41aa20ef214c5f63942cc5e257dfaaafb13ea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210397327

From stuefe at openjdk.org  Wed Jul 16 14:01:30 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Jul 2025 14:01:30 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
Message-ID: <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>

> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulnes:
> 
> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if its 0, we'd assert, if garbage, the resulting Klass* would be garbage.
> - In print_failure, we now check pointers for readability before handing them to print_obj
> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
> - In print_obj, we print a small hex dump of the header (32bytes). With little cost we get a glance at the raw header and the first members.
> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
> 
> Tests: I manually tested the patch with a number of manually broken oops of various flavours. 
> 
> Example output, invalid forwardee:
> 
> 
> Referenced from:
>   no interior location recorded (probably a plain heap scan, or detached oop)
> 
> Object:
>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
> 
>         allocated after mark start
>         after update watermark
>         marked strong
>         marked weak
>     not in collection set
>     mark:  marked(0xdeaddeaddeaddeaf)
>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
> 
>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
> 
> Forwardee:
>   0xdeaddeaddeaddeac - safe print, no details

Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
 - small revert
 - cosmetics
 - wip
 - wip
 - wip
 - wip
 - assert_correct

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26237/files
  - new: https://git.openjdk.org/jdk/pull/26237/files/94fe071e..c7a9c26e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26237&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26237&range=00-01

  Stats: 15182 lines in 458 files changed: 9331 ins; 3870 del; 1981 mod
  Patch: https://git.openjdk.org/jdk/pull/26237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26237/head:pull/26237

PR: https://git.openjdk.org/jdk/pull/26237

From gdub at openjdk.org  Wed Jul 16 14:42:49 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 14:42:49 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
Message-ID: <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>

On Wed, 16 Jul 2025 13:17:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed bug in use of JVMCI traps
>  - moved inject field check into check_field for benefit of get_encoded_annotation_data

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3084:

> 3082:   CompilerThreadCanCallJava canCallJava(thread, true); // Requires Java support
> 3083:   InstanceKlass* holder = InstanceKlass::cast(UNPACK_PAIR(Klass, klass));
> 3084:   return get_encoded_annotation_data(holder, holder->class_annotations(), true, filter_length, filter_klass_pointers, THREAD, JVMCI_CHECK_NULL);

Can `JVMCI_CHECK_` be used in `return` statements? i think the "check and return default value" part would be unreachable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210628575

From dnsimon at openjdk.org  Wed Jul 16 15:03:36 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:03:36 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  revert from JVMCI_CHECK_NULL back to JVMCIENV in final return statement of method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/c76efe51..7cf4b26c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From dnsimon at openjdk.org  Wed Jul 16 15:03:39 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:03:39 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v3]
In-Reply-To: <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <GcufEAiDcqThIrXq9RkfbER_cyPk4I4QPZnVU2fFolk=.39559e97-3fca-4bb7-b174-397c9b41ef92@github.com>
 <BzTFyTwxJgh4r8Rg37OP2YJ0i1Q17Xw6dbP0NewNb8U=.dc2b58e0-d23d-43fc-8037-766d14191361@github.com>
Message-ID: <wTckuo7OUxX0MLvREqMx4QKVu0kIMA_OiPjjfSWcodY=.1b889750-9534-4f9d-b08a-18d06ea2ed14@github.com>

On Wed, 16 Jul 2025 14:38:35 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed bug in use of JVMCI traps
>>  - moved inject field check into check_field for benefit of get_encoded_annotation_data
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3084:
> 
>> 3082:   CompilerThreadCanCallJava canCallJava(thread, true); // Requires Java support
>> 3083:   InstanceKlass* holder = InstanceKlass::cast(UNPACK_PAIR(Klass, klass));
>> 3084:   return get_encoded_annotation_data(holder, holder->class_annotations(), true, filter_length, filter_klass_pointers, THREAD, JVMCI_CHECK_NULL);
> 
> Can `JVMCI_CHECK_` be used in `return` statements? i think the "check and return default value" part would be unreachable.

Indeed - I've been bitten by this before! In this case, it's harmless given that the return statement is anyway the last statement in the method. Still, I'll revert my "fix".
I'm also wondering (again?) why the C++ compiler does not warning about unreachable code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2210679057

From gdub at openjdk.org  Wed Jul 16 15:12:40 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 15:12:40 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
Message-ID: <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>

On Wed, 16 Jul 2025 15:03:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert from JVMCI_CHECK_NULL back to JVMCIENV in final return statement of method

Maybe you could add a test in `TestResolvedJavaType.getClassInitializer` to check that `getMirror` doesn't crash on that and returns null?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26346#issuecomment-3079072065

From dnsimon at openjdk.org  Wed Jul 16 15:40:27 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:40:27 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  test that getMirror on clinit returns null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/7cf4b26c..fd44d95c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From dnsimon at openjdk.org  Wed Jul 16 15:40:27 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Jul 2025 15:40:27 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v4]
In-Reply-To: <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <oVcbnphj11M9T5DBo8zuCtInI8svIuQsgJbYOwVJKZM=.2aa4ad15-595d-4c5e-b1cf-e3d995c80507@github.com>
 <6dUGyR9-38wxACBU-qXBcUdNuChfSQjPXNHpKsAJ3Y4=.f2397b87-fd84-4e87-9d52-0cda901810df@github.com>
Message-ID: <D44-f5RYIfLYtEDwSdFczoigEzhDTvALsxWW2RDNA4w=.773d6fba-0f9c-4f15-b187-646facf34b7a@github.com>

On Wed, 16 Jul 2025 15:09:43 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

> Maybe you could add a test in `TestResolvedJavaType.getClassInitializer` to check that `getMirror` doesn't crash on that and returns null?

Done: https://github.com/openjdk/jdk/pull/26346/commits/fd44d95c83bb9160395b5fe94298f1a300233001

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26346#issuecomment-3079185834

From gdub at openjdk.org  Wed Jul 16 15:49:41 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Wed, 16 Jul 2025 15:49:41 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
Message-ID: <aFLGpme1BuCm0gK_fKFO9vn2H-A5-qH2VFB9PEPxXFE=.4220d3d6-4473-464e-a4d2-4b19afc2fa9c@github.com>

On Wed, 16 Jul 2025 15:40:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that getMirror on clinit returns null

Marked as reviewed by gdub (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3025670605

From vyazici at openjdk.org  Wed Jul 16 19:38:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:38:02 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v5]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <hqDqiIGVA7b4bjOO-QUsL-_7tB-3-MxUZoGZ1tBPozY=.3ca0eefe-80a1-4f1e-b01f-196f9770d51e@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/2b89e880..8941e6b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=03-04

  Stats: 110 lines in 3 files changed: 108 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Wed Jul 16 19:42:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:42:32 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <pozYBtbEcYQCqynctIMGBY_G3HJFLYXL8DOjrUudzsk=.ec4d7f03-938c-4728-a2c1-60f8fc549b69@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici 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:

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/8941e6b6..bcb073cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From sviswanathan at openjdk.org  Wed Jul 16 20:57:47 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 16 Jul 2025 20:57:47 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v4]
In-Reply-To: <-V4hpHvXdaDjmEyYzHcEpDJ2bzPTqoz2Ao8FLobkmB8=.d9e3b962-ae8d-4e4b-8ddb-c3ab42a2a619@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <-V4hpHvXdaDjmEyYzHcEpDJ2bzPTqoz2Ao8FLobkmB8=.d9e3b962-ae8d-4e4b-8ddb-c3ab42a2a619@github.com>
Message-ID: <nfruVw1S1E9REEa9HWHj5CCbTbDQ_b6sFn3Hadb-afY=.a1551c69-55c3-4f00-809c-2cae4010d4a3@github.com>

On Wed, 16 Jul 2025 00:06:53 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Srinivas Vamsi Parasa 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 with master
>  - remove pushp/popp from vm_version_x86 and also when APX is not being used
>  - rename to paired_push and paired_pop
>  - 8359965: Enable paired pushp and popp instruction usage for APX enabled CPUs

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 798:

> 796: }
> 797: 
> 798: void MacroAssembler::paired_push(Register src) {

Would be better to call these as push_ppx and pop_ppx.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2211592540

From cslucas at openjdk.org  Wed Jul 16 22:54:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 16 Jul 2025 22:54:47 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
Message-ID: <RdGKTvuSKrz_MrX0Brji8yD3c0P3qHA_-hRvtrPxthc=.179a3386-73ac-4378-a06d-7ee6054ade24@github.com>

On Wed, 16 Jul 2025 15:40:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that getMirror on clinit returns null

LGTM

-------------

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3027147958

From dholmes at openjdk.org  Thu Jul 17 01:16:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Jul 2025 01:16:51 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
Message-ID: <1kYpuC9fa1bCtTZ04msK8UjRmyCD_KNj9OYqMRwr-qg=.54d22cc5-ee3a-4a52-8af6-938aef1dd73c@github.com>

On Wed, 16 Jul 2025 07:33:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sorry for being late to the party. I still need to walk through all the comments but it seems you have already caught the main problem with virtual threads. Nothing protects them from being concurrently mounted/unmounted/remounted. It is why the `JvmtiVTMSTransitionDisabler` is used in the JVMTI code. But, please, note that the `JvmtiVTMSTransitionDisabler` mechanism is enabled only when there is a JVMTI agent. Otherwise, it has been disabled for scalability purposes to exclude potentially high performance overhead at the VTMS transition points.
>
> With `JvmtiVTMSTransitionDisabler` there is normally no need in the carrier thread protection. A virtual thread is either mounted or unmounted. There is no carrier thread when virtual thread is unmounted. If virtual thread is mounted and VTMS transitions are disabled then the carrier thread is blocked until VTMS transitions are enabled again and the execution control is returned to the carrier. But JVMTI is playing by the established rules and always using TLH to protect the JavaThread associated with the virtual thread and its carrier.

If transition disabling is only available with JVMTI then I think we have a significant problem trying to deal with virtual threads in a number of APIs. Without disabling transitions you would basically need a loop that safely extracts the current carrier, handshakes with it, checks the VT is still mounted, and if not repeat the process. At the moment it appears that if the carrier is seen to have changed then we can just skip the VT - which would be very wrong IMO for most APIs e.g. thread dumps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2211933753

From sspitsyn at openjdk.org  Thu Jul 17 01:33:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Jul 2025 01:33:54 GMT
Subject: Integrated: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is
 thrown for reasons other than a native method
In-Reply-To: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
References: <OZtttm3vgSZbdkaa5wXeqb3nZ3SoAG7XTIUqMKtEv_I=.550e9ffe-70b4-438a-81af-de2eecc653cb@github.com>
Message-ID: <UQp0MAukWGG0SnOn_8yZu3mqrqiaaIjFs-2-tbHCj8k=.46fc53f7-94c8-4179-870d-d584d5db3979@github.com>

On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
> This impacts the following JVMTI spec sections:
>   - `PopFrame`
>   - `NotifyFramePop`
>   - `ForceEarlyReturn<Type>`
>   - `GetLocal<Type>`
>   - `SetLocal<Type>`
>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>   
> A related CSR is going to be filed for this spec update.
> 
> Testing:
>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe

This pull request has now been integrated.

Changeset: a65d9532
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a65d9532ed454a0f70b1009181a25b23a38ccd4b
Stats:     85 lines in 1 file changed: 5 ins; 48 del; 32 mod

8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/26111

From sspitsyn at openjdk.org  Thu Jul 17 01:57:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Jul 2025 01:57:32 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v6]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <C-6Rn53RSv1ChRcncCox0_jAJgjtmHIasid4HmvNyzU=.c1140bae-8a24-46e0-93cd-ace6c817fa46@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn 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
 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/3900252d..80fc70ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=04-05

  Stats: 16210 lines in 455 files changed: 10361 ins; 3853 del; 1996 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From dholmes at openjdk.org  Thu Jul 17 02:03:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Jul 2025 02:03:49 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <1kYpuC9fa1bCtTZ04msK8UjRmyCD_KNj9OYqMRwr-qg=.54d22cc5-ee3a-4a52-8af6-938aef1dd73c@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
 <1kYpuC9fa1bCtTZ04msK8UjRmyCD_KNj9OYqMRwr-qg=.54d22cc5-ee3a-4a52-8af6-938aef1dd73c@github.com>
Message-ID: <oM1n452VKcDGei8EIdwRMu-bZxWMq5sqlskbn9O9SSM=.8a0fcf26-2b8d-43f8-b93a-5e07494cb5ac@github.com>

On Thu, 17 Jul 2025 01:13:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> With `JvmtiVTMSTransitionDisabler` there is normally no need in the carrier thread protection. A virtual thread is either mounted or unmounted. There is no carrier thread when virtual thread is unmounted. If virtual thread is mounted and VTMS transitions are disabled then the carrier thread is blocked until VTMS transitions are enabled again and the execution control is returned to the carrier. But JVMTI is playing by the established rules and always using TLH to protect the JavaThread associated with the virtual thread and its carrier.
>
> If transition disabling is only available with JVMTI then I think we have a significant problem trying to deal with virtual threads in a number of APIs. Without disabling transitions you would basically need a loop that safely extracts the current carrier, handshakes with it, checks the VT is still mounted, and if not repeat the process. At the moment it appears that if the carrier is seen to have changed then we can just skip the VT - which would be very wrong IMO for most APIs e.g. thread dumps.

> please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled only when there is a JVMTI agent.

@sspitsyn  can you clarify this please. When you take a thread dump via the HotsotDiagnosticMXBean is there a JVMTI agent involved? Because that code uses the transition disabler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2211991487

From stuefe at openjdk.org  Thu Jul 17 03:49:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Jul 2025 03:49:02 GMT
Subject: RFR: 8362088: CompressedKlassPointers::encode should be const correct
Message-ID: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>

Trivial change. CompressedKlassPointers::encode It should accept a const Klass* .

-------------

Commit messages:
 - start

Changes: https://git.openjdk.org/jdk/pull/26306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362088
  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26306/head:pull/26306

PR: https://git.openjdk.org/jdk/pull/26306

From dholmes at openjdk.org  Thu Jul 17 03:58:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Jul 2025 03:58:46 GMT
Subject: RFR: 8362088: CompressedKlassPointers::encode should be const
 correct
In-Reply-To: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
References: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
Message-ID: <C3jTsGzVwhM88moJp0BHCbZu5efYEShZ--p8eKMy9uA=.17d41fed-c6dd-419a-83cb-f0bd2f1455b6@github.com>

On Tue, 15 Jul 2025 05:30:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial change. CompressedKlassPointers::encode It should accept a const Klass* .

Yes that seems trivially fine.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26306#pullrequestreview-3027729043

From stuefe at openjdk.org  Thu Jul 17 04:03:52 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Jul 2025 04:03:52 GMT
Subject: RFR: 8362088: CompressedKlassPointers::encode should be const
 correct
In-Reply-To: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
References: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
Message-ID: <alCWOXlW3L8S3UXV3Vaqk4niwXhEK9oJBR6WLKOxRcQ=.c500d633-3c9c-4f92-b840-e3e7c1d428fb@github.com>

On Tue, 15 Jul 2025 05:30:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial change. CompressedKlassPointers::encode It should accept a const Klass* .

Thank you, David. Macos GHA errors unrelated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26306#issuecomment-3082391824

From stuefe at openjdk.org  Thu Jul 17 04:03:52 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Jul 2025 04:03:52 GMT
Subject: Integrated: 8362088: CompressedKlassPointers::encode should be const
 correct
In-Reply-To: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
References: <ZwpTrnDUdulrDOlCkYUgAHMn3bIAT8-J56FmlBcaksY=.7f7839a0-51d7-4ffa-b706-6532d9c29ec0@github.com>
Message-ID: <t2I8-8noSuw_jEgrpsfp8acjvzY79zgc91FcEUTzFfw=.d6bd89a0-f890-4711-b206-dcab02a6bf38@github.com>

On Tue, 15 Jul 2025 05:30:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial change. CompressedKlassPointers::encode It should accept a const Klass* .

This pull request has now been integrated.

Changeset: bc72f476
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc72f476d1281dae2adb2322004c9880c1a6b66c
Stats:     8 lines in 2 files changed: 0 ins; 0 del; 8 mod

8362088: CompressedKlassPointers::encode should be const correct

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26306

From lmesnik at openjdk.org  Thu Jul 17 04:11:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Jul 2025 04:11:50 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v6]
In-Reply-To: <C-6Rn53RSv1ChRcncCox0_jAJgjtmHIasid4HmvNyzU=.c1140bae-8a24-46e0-93cd-ace6c817fa46@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <C-6Rn53RSv1ChRcncCox0_jAJgjtmHIasid4HmvNyzU=.c1140bae-8a24-46e0-93cd-ace6c817fa46@github.com>
Message-ID: <ZYDTTk9wfnL6QNmsiyFcudfko3LEP41afnuCK3-fT-g=.26b8676a-67fa-4973-8af8-8f22fefbc56a@github.com>

On Thu, 17 Jul 2025 01:57:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
>> 
>> TBD: Need to submit a related CSR.
>> 
>> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>>  
>> Testing:
>>  - mach5 tiers 1-6 are good
>>  - may need to run mach5 tiers > 6
>
> Serguei Spitsyn 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
>  - Merge
>  - review: replace RESERVED flag with UNUSED
>  - review: keep right order of the obsoleted VM options
>  - corrected one assert message
>  - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

I commented the only test that seems to be still useful. 
All other tests are related to add/delete methods.
I think it is needed to check if any of remaining tests should be updated to negative tests that verifies correctness of thrown Exception. 
However, it could be done after final agreement is reached.

test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh line 2:

> 1: #
> 2: # Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved.

This test is still useful, it is needed to remove method deletion only. 
However, part of testing with redefined method is still useful. 
The test checks that old copy of redefined method is not removed.

-------------

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3027590373
PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2212081642

From vyazici at openjdk.org  Thu Jul 17 04:37:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 04:37:49 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>

On Thu, 10 Jul 2025 12:23:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici 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:
>> 
>>   Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>
> src/hotspot/share/opto/library_call.cpp line 963:
> 
>> 961: 
>> 962:   if (bailout->req() > 1) {
>> 963:     if (halt) {
> 
> Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.

@TobiHartmann, this change results in the following compiler error:


/home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
  958 |   generate_negative_guard(offset, bailout);
      |                                   ^~~~~~~
      |                                   |
      |                                   Node*


That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. I will locally amend this change as


bailout = (RegionNode*) _gvn.transform(bailout);


Let me know if you disagree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212232094

From vyazici at openjdk.org  Thu Jul 17 06:13:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:13:30 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
 - Fix compiler error in `generate_string_range_check`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/bcb073cb..abc0eeb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=05-06

  Stats: 61 lines in 4 files changed: 53 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Thu Jul 17 06:15:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:15:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
 <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
Message-ID: <tiD2-tEG9GB_6qJJuxMzR2V0qcrcEGjHaVme-D7fiUY=.404f5ff5-26d6-47ed-8315-532619554663@github.com>

On Wed, 16 Jul 2025 05:28:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volkan Yazici 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 remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Apply review feedback (styling changes)
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>>    
>>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>>  - Improve intrinsics in `StringCoding`
>>  - Add `StringCodingCountPositives` benchmark
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/921f85ab...85f19864
>
> src/hotspot/share/opto/c2_globals.hpp line 665:
> 
>> 663:           "prints attempted and successful inlining of intrinsics")         \
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 
> We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

@TobiHartmann, agreed. I've pushed two commits:

1. bcb073cbb41 adds `TestVerifyIntrinsicChecks` to verify the effectiveness of the `VerifyIntrinsicChecks` VM flag. That is, does VM indeed crash if intrinsic Java wrapper fails to properly validate the input?
2. abc0eeb3bfc adds a separate `/* @test ... @run ... -XX:+VerifyIntrinsicChecks` block to the tests using `StringCoding` intrinsics

Please let me know if these two address your remarks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212371103

From alanb at openjdk.org  Thu Jul 17 06:17:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Jul 2025 06:17:51 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <oM1n452VKcDGei8EIdwRMu-bZxWMq5sqlskbn9O9SSM=.8a0fcf26-2b8d-43f8-b93a-5e07494cb5ac@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
 <1kYpuC9fa1bCtTZ04msK8UjRmyCD_KNj9OYqMRwr-qg=.54d22cc5-ee3a-4a52-8af6-938aef1dd73c@github.com>
 <oM1n452VKcDGei8EIdwRMu-bZxWMq5sqlskbn9O9SSM=.8a0fcf26-2b8d-43f8-b93a-5e07494cb5ac@github.com>
Message-ID: <P9Egf_wVZZtQ9OM25pT-tOPEf2QFWWI5V4kyXPgBSKc=.56da5977-3d49-497a-926c-71dd25e11df4@github.com>

On Thu, 17 Jul 2025 02:01:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If transition disabling is only available with JVMTI then I think we have a significant problem trying to deal with virtual threads in a number of APIs. Without disabling transitions you would basically need a loop that safely extracts the current carrier, handshakes with it, checks the VT is still mounted, and if not repeat the process. At the moment it appears that if the carrier is seen to have changed then we can just skip the VT - which would be very wrong IMO for most APIs e.g. thread dumps.
>
>> please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled only when there is a JVMTI agent.
> 
> @sspitsyn  can you clarify this please. When you take a thread dump via the HotsotDiagnosticMXBean is there a JVMTI agent involved? Because that code uses the transition disabler.

Thread::getStackTrace handles this with a SUSPEND bit and loop. I think the only non-JVMTI API where we've got an issue right now is HotsotDiagnosticMXBean.dumpThreads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2212373645

From vyazici at openjdk.org  Thu Jul 17 06:21:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:21:56 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <66HgANGbmZLWZpH-g9ChFl_VX3WRq_WgYlq4edeVAIg=.7e3f06ab-ba80-4952-9ff5-168d64025783@github.com>

On Thu, 17 Jul 2025 06:13:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 84:

> 82:         char[] buffer = new char[length];
> 83:         for (int i = 0; i < length; i++) {
> 84:             buffer[i] = (char) (i % '\u0080');

ASCII (<= 0x7F) production

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212379110

From vyazici at openjdk.org  Thu Jul 17 06:31:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:31:55 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <oS4jbFRoOs0Gk7rzDmHCW3j0HJVv8ETSkiJuyS_ocCo=.4fc13412-aba3-4884-bbed-6c9dea3bdd29@github.com>

On Thu, 17 Jul 2025 06:13:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java line 44:

> 42:     @jdk.internal.vm.annotation.ForceInline
> 43:     public static int StringCodingEncodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 44:         return StringCoding.encodeAsciiArray0(sa, sp, da, dp, len);

`TestVerifyIntrinsicChecks` needs to have access to an intrinsic that uses the `VerifyIntrinsicChecks` VM flag. For that purpose, I chose `StringCoding::encodeAsciiArray`, which is the guarded public door to `@IntrinsicCandidate encodeAsciiArray0()` ? note the `0` suffix! `TestVerifyIntrinsicChecks` needs to feed invalid input to `encodeAsciiArray0()` to trip the checks in the compiler intrinsic. Though, `encodeAsciiArray0()` is, as is one of the main motivations of this PR, private. In `TestVerifyIntrinsicChecks`, I first tried accessing to `encodeAsciiArray0()` using reflection, but this blocked the method get inlined, which is a requirement for intrinsification. Hence, I made the  `encodeAsciiArray0()` package-private and exposed it via `StringCodingEncodeAsciiArray0` to allow inlining, and, eventually, intrinsification. This worked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212396003

From thartmann at openjdk.org  Thu Jul 17 07:06:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 07:06:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
Message-ID: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>

On Thu, 17 Jul 2025 04:35:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 963:
>> 
>>> 961: 
>>> 962:   if (bailout->req() > 1) {
>>> 963:     if (halt) {
>> 
>> Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input.
>
> @TobiHartmann, this change results in the following compiler error:
> 
> 
> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>   958 |   generate_negative_guard(offset, bailout);
>       |                                   ^~~~~~~
>       |                                   |
>       |                                   Node*
> 
> 
> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
> 
> 
> bailout = (RegionNode*) _gvn.transform(bailout);
> 
> 
> Let me know if you disagree.

Please use `->as_Region()` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212467404

From vyazici at openjdk.org  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Replace casting with `as_Region()` in `generate_string_range_check`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/abc0eeb3..db1ed388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
 <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
Message-ID: <ZF0kmTYixGF_s_Wv3IuCSXS4TUR3ocblRo_aisw1cRI=.32306c61-2fd2-43eb-9616-247d91b0146a@github.com>

On Thu, 17 Jul 2025 07:04:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann, this change results in the following compiler error:
>> 
>> 
>> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>>   958 |   generate_negative_guard(offset, bailout);
>>       |                                   ^~~~~~~
>>       |                                   |
>>       |                                   Node*
>> 
>> 
>> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
>> 
>> 
>> bailout = (RegionNode*) _gvn.transform(bailout);
>> 
>> 
>> Let me know if you disagree.
>
> Please use `->as_Region()` instead.

Changed as requested in db1ed388765.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212492666

From sspitsyn at openjdk.org  Thu Jul 17 07:39:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Jul 2025 07:39:56 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v3]
In-Reply-To: <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>
Message-ID: <ib0Kz9yCkvmgk43o4elt_UQ-yl_mJdBE7_9AWKwT-aw=.23aea65f-69e7-452b-8a01-22f74544136c@github.com>

On Tue, 15 Jul 2025 23:37:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problem happens if post_early_vm_start is triggered.
>> The fix is to complete initialization once threadObj become available.
>> 
>> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed test

Thank you for updates! Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3028291409

From sspitsyn at openjdk.org  Thu Jul 17 07:54:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Jul 2025 07:54:49 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
Message-ID: <0n3lTxam4BV78nLT72ReL5b-slMyXSOTwtklVChVLJg=.f639619a-0bea-4e7e-af28-e61adfae667c@github.com>

On Wed, 16 Jul 2025 07:33:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sorry for being late to the party. I still need to walk through all the comments but it seems you have already caught the main problem with virtual threads. Nothing protects them from being concurrently mounted/unmounted/remounted. It is why the `JvmtiVTMSTransitionDisabler` is used in the JVMTI code. But, please, note that the `JvmtiVTMSTransitionDisabler` mechanism is enabled only when there is a JVMTI agent. Otherwise, it has been disabled for scalability purposes to exclude potentially high performance overhead at the VTMS transition points.
>
> With `JvmtiVTMSTransitionDisabler` there is normally no need in the carrier thread protection. A virtual thread is either mounted or unmounted. There is no carrier thread when virtual thread is unmounted. If virtual thread is mounted and VTMS transitions are disabled then the carrier thread is blocked until VTMS transitions are enabled again and the execution control is returned to the carrier. But JVMTI is playing by the established rules and always using TLH to protect the JavaThread associated with the virtual thread and its carrier.

> @sspitsyn can you clarify this please. When you take a thread dump via the HotsotDiagnosticMXBean is there a JVMTI agent involved? Because that code uses the transition disabler.

Yes, we have this issue for `HotsotDiagnosticMXBean.dumpThreads` as Alan has pointed out. We are aware about it and will evaluate a couple of fixing approaches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2212582215

From thartmann at openjdk.org  Thu Jul 17 08:33:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 08:33:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <fuxrNfsUsBbXxW1KDYlCeDY7Qdi2CrM0C6aruF1Vv80=.91e6bee4-2828-49a8-b17c-d07716666099@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

That looks good to me. Thanks!

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028497094

From jpai at openjdk.org  Thu Jul 17 09:10:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 09:10:48 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <Y5KgALU_xIs40qkrtuGTXa6uaoL5jnzFSdfP5j2kad4=.783539e5-73e8-4895-9fb4-5bec92d8524c@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> 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 looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3028640169

From dfenacci at openjdk.org  Thu Jul 17 09:37:51 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 17 Jul 2025 09:37:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <zzkuyukdeX9XFwhjUDH1sRxly_VraGXe6lciLE1cWuQ=.fbf49cbe-9541-4676-92e0-be0cde765a29@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

Looks good to me too. Thanks @vy!

-------------

Marked as reviewed by dfenacci (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028731726

From ayang at openjdk.org  Thu Jul 17 10:29:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 17 Jul 2025 10:29:46 GMT
Subject: RFR: 8347052: Update java man page documentation to reflect
 current state of the UseNUMA flag
In-Reply-To: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
References: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
Message-ID: <bNgCJ-KnIOLrulY0p-pecELCWTywndoHruV3Nnyvy4g=.8ba1da4a-fc75-4070-82b2-ca816dbc9227@github.com>

On Tue, 15 Jul 2025 15:16:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to the man pages that previously stated that `UseNUMA` is only available with Parallel GC. To minimize future update problems, the text has been modified to just say that the default value is dependent on the collector.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26321#pullrequestreview-3028924062

From coleenp at openjdk.org  Thu Jul 17 12:05:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:05:49 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
Message-ID: <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>

On Wed, 16 Jul 2025 02:42:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.
> 
> The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.
> 
> Thanks!

Looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26338#pullrequestreview-3029231200

From syan at openjdk.org  Thu Jul 17 12:45:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:45:00 GMT
Subject: [jdk25] RFR: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
 <JJm-GnM7bUyUxaK9JPr-c98KLsVz7gXRbsmOCKWyEXI=.df63cfcd-1b62-4d81-9c1c-0155eca22be4@github.com>
Message-ID: <C75LyV7N0sGmO1HmoChcheorVymiBNaXiqmhBhcB-NA=.1fc10d97-94f0-4f88-99e0-90f193751440@github.com>

On Thu, 17 Jul 2025 12:03:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looks good.

Thanks for the reviews. @coleenp

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26338#issuecomment-3083920028

From syan at openjdk.org  Thu Jul 17 12:45:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 17 Jul 2025 12:45:01 GMT
Subject: [jdk25] Integrated: 8358004: Delete applications/scimark/Scimark.java
 test
In-Reply-To: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
References: <sZMOLVpuyS1bMiVSRvuzMK35bivA3q4PckpIVRQqccE=.fbcde97f-397e-490a-a5bf-137d02f5e3fc@github.com>
Message-ID: <wRwPL4r8f4KobI4TzGTcQ1yySnPAk8531hvh3nIczNM=.70125543-6ce4-4f08-9305-48369ebb91f7@github.com>

On Wed, 16 Jul 2025 02:42:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a5c9bc70](https://github.com/openjdk/jdk/commit/a5c9bc70324693e9d0b25bb2c51b91dfc750c453) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The Scimark is not maintained, this backport PR remove this useless tests which cause test failure. Test-fix only, no risk.
> 
> The commit being backported was authored by Leonid Mesnik on 16 Jul 2025 and was reviewed by SendaoYan and Coleen Phillimore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f1f6452e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1f6452e01e5a4521cb333d7456333f00cd9680c
Stats:     58 lines in 1 file changed: 0 ins; 58 del; 0 mod

8358004: Delete applications/scimark/Scimark.java test

Reviewed-by: coleenp
Backport-of: a5c9bc70324693e9d0b25bb2c51b91dfc750c453

-------------

PR: https://git.openjdk.org/jdk/pull/26338

From tschatzl at openjdk.org  Thu Jul 17 13:50:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 13:50:53 GMT
Subject: RFR: 8347052: Update java man page documentation to reflect
 current state of the UseNUMA flag
In-Reply-To: <C9kqM4ydhlscL2LHa_NVL_l_qSJlmtZ94hNQ2wws9pQ=.465857f8-49db-417a-b06b-e6a003f9dca0@github.com>
References: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
 <C9kqM4ydhlscL2LHa_NVL_l_qSJlmtZ94hNQ2wws9pQ=.465857f8-49db-417a-b06b-e6a003f9dca0@github.com>
Message-ID: <F9HARagUt8hH861zwZ_i6Isq9rlFKnBeyXa_JUcClec=.49ca990a-e1fe-4a2f-b3e5-430be415b5e3@github.com>

On Tue, 15 Jul 2025 18:14:03 GMT, Derek White <drwhite at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this small fix to the man pages that previously stated that `UseNUMA` is only available with Parallel GC. To minimize future update problems, the text has been modified to just say that the default value is dependent on the collector.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by drwhite (Committer).

Thanks @dwhite-intel @albertnetymk for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26321#issuecomment-3084147928

From tschatzl at openjdk.org  Thu Jul 17 13:50:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 13:50:54 GMT
Subject: Integrated: 8347052: Update java man page documentation to reflect
 current state of the UseNUMA flag
In-Reply-To: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
References: <zwB4atnCz9WR-5S7vRBsH8AoEufQU6uKvz79WeFFD6I=.f7357049-4fc5-4219-9fd7-e613ee6c06bf@github.com>
Message-ID: <SqI41Zm5snbPCMhk0fkauMdL3YvYtg4qg0h-D_z1xJ4=.a710d5a7-8f80-40b2-b0f4-a168c7dab565@github.com>

On Tue, 15 Jul 2025 15:16:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this small fix to the man pages that previously stated that `UseNUMA` is only available with Parallel GC. To minimize future update problems, the text has been modified to just say that the default value is dependent on the collector.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ea774b74
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea774b74e819e6db607204c05fd1c8f57d508213
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8347052: Update java man page documentation to reflect current state of the UseNUMA flag

Reviewed-by: drwhite, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/26321

From rgiulietti at openjdk.org  Thu Jul 17 14:16:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:16:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

src/java.base/share/classes/java/lang/StringCoding.java line 130:

> 128:      * <p>
> 129:      * This method assumes that {@code sa} is encoded in UTF-16, and hence,
> 130:      * each {@code char} maps to 2 bytes.

Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph?

src/java.base/share/classes/java/lang/StringCoding.java line 132:

> 130:      * each {@code char} maps to 2 bytes.
> 131:      * </p><p>
> 132:      * {@code sp} is encoded in ISO-8859-1. There each {@code byte} corresponds

As this is an index, it doesn't make sense to state that it is encoded in ISO-8859-1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213428956
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213429091

From rgiulietti at openjdk.org  Thu Jul 17 14:16:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:16:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <gO2q1V0LZuXhcboQGWSJTzP4_VFEQ6r4deaKX6bcpv4=.206710a6-3f28-430b-93c3-bbb1c0aee977@github.com>

On Thu, 10 Jul 2025 12:18:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringCoding.java line 140:
> 
>> 138:      *
>> 139:      * @param sa the source byte array containing characters encoded in UTF-16
>> 140:      * @param sp the index of the <em>byte (not character!)</em> from the source array to start reading from
> 
> Note the `byte (not character!)` emphasis here and below.

I think this is incorrect.
This is the index of a character (two bytes).
As it is used in `encodeISOArray0()`, it is incremented by 1 and passed to `StringUTF16.getChar()`, where it is multiplied by 2 to obtain the real `byte[]` index.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213466146

From rgiulietti at openjdk.org  Thu Jul 17 14:31:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:31:56 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method?
Which part is responsible for the checks?

For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.

So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3084301249

From rriggs at openjdk.org  Thu Jul 17 14:35:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Jul 2025 14:35:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <hkX-Krx5Kn-vkpQ5gstaiBAiClrFWp4epdpdH0ZW6pQ=.c0f112b9-81eb-4d9a-976d-6e0062812596@github.com>

On Thu, 10 Jul 2025 12:20:45 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringCoding.java line 150:
> 
>> 148:      */
>> 149:     static int encodeISOArray(byte[] sa, int sp, byte[] da, int dp, int len) {
>> 150:         checkFromIndexSize(sp, len << 1, requireNonNull(sa, "sa").length, AIOOBE_FORMATTER);
> 
> `sa` contains 2-byte `char`s, and `sp` points to an index of this inflated array. Though, `len` denotes the codepoint count, hence the `len << 1` while checking `sp` and `len` bounds.

The reference of `sa.length` is likely wrong also, as it is the source length in bytes but for the index check should be checking the source length in chars.
It might be worth trying to find or create a test for the accidental incorrect interpretation of length in bytes vs chars..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213528045

From never at openjdk.org  Thu Jul 17 14:37:53 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 17 Jul 2025 14:37:53 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v5]
In-Reply-To: <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <pRTJLLP00jI_ct61mPAbAWd5Oe8Bw8M1yZPAHtfyumY=.ca8abc3d-cde9-4903-8638-aacd96b0558b@github.com>
Message-ID: <8q5bw4B4Yd36332fWAOPO18XzJOPdQUlpCg9M9eBWVA=.d6d45d7d-f3a4-4105-8f1d-f800d8100d2a@github.com>

On Wed, 16 Jul 2025 15:40:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test that getMirror on clinit returns null

Marked as reviewed by never (Reviewer).

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3011:

> 3009:   requireInHotSpot("asReflectionField", JVMCI_CHECK_NULL);
> 3010:   Klass* klass = UNPACK_PAIR(Klass, klass);
> 3011:   InstanceKlass* iklass = check_field(klass, index, JVMCI_CHECK_NULL);

There's another copy of this idiom in getDeclaredFieldsInfo which might be worth fixing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3029824400
PR Review Comment: https://git.openjdk.org/jdk/pull/26346#discussion_r2213530140

From rgiulietti at openjdk.org  Thu Jul 17 14:42:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:42:55 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <gVwo5i2-Xm3OpSnQvI0SGlOpGJ6MXhOLplcdwtCEuoc=.aac35f48-c408-4c7e-b22b-1432737da015@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

src/java.base/share/classes/java/lang/StringCoding.java line 150:

> 148:         Objects.requireNonNull(sa, "sa");
> 149:         Objects.requireNonNull(da, "da");
> 150:         Preconditions.checkFromIndexSize(sp, len << 1, sa.length, Preconditions.AIOOBE_FORMATTER);

Since `sp` is a character index and `len` counts characters but `sa.length` is in bytes, this should look like so
Suggestion:

        Preconditions.checkFromIndexSize(sp, len, sa.length >>> 1, Preconditions.AIOOBE_FORMATTER);

or something similar.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213543167

From tschatzl at openjdk.org  Thu Jul 17 14:50:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 14:50:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v43]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <TtV0oPZQZrjta5-y-4_GqT7Xk0Qpxt2BlASdcJYFrP4=.78b09f04-0cd9-453d-8ca1-23805bca7982@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - ... and 49 more: https://git.openjdk.org/jdk/compare/ea774b74...4b21868a

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=42
  Stats: 7120 lines in 112 files changed: 2589 ins; 3590 del; 941 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From dnsimon at openjdk.org  Thu Jul 17 15:00:11 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 17 Jul 2025 15:00:11 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v6]
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  replaced use of JVMCIENV with JVMCI_CHECK_NULL in getDeclaredFieldsInfo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26346/files
  - new: https://git.openjdk.org/jdk/pull/26346/files/fd44d95c..d62c74d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26346&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26346/head:pull/26346

PR: https://git.openjdk.org/jdk/pull/26346

From yzheng at openjdk.org  Thu Jul 17 15:04:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 17 Jul 2025 15:04:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>

On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 25:

> 23: 
> 24: /*
> 25:  * @test

could you please add ` * @requires !vm.graal.enabled`? Graal is failing this test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213601907

From gdub at openjdk.org  Thu Jul 17 15:05:50 2025
From: gdub at openjdk.org (Gilles Duboscq)
Date: Thu, 17 Jul 2025 15:05:50 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v6]
In-Reply-To: <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
Message-ID: <HKx2F4RMa2xp5j38S1CjDCjYIWPsatAaBr-vlrlYhT4=.b66dd6a2-bcc9-4f7d-a06e-030848890e63@github.com>

On Thu, 17 Jul 2025 15:00:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replaced use of JVMCIENV with JVMCI_CHECK_NULL in getDeclaredFieldsInfo

Marked as reviewed by gdub (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3029932165

From rgiulietti at openjdk.org  Thu Jul 17 15:35:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 15:35:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
Message-ID: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>

On Thu, 17 Jul 2025 14:29:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
> 
> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
> 
> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?

To reformulate my confusing question for the above example, there are apparently around 75-80 invocations of `getChar()`. How to make sure that they are all safe? Some are easy to verify, but others are not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3084525709

From never at openjdk.org  Thu Jul 17 16:06:50 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 17 Jul 2025 16:06:50 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v6]
In-Reply-To: <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
Message-ID: <QFoNiaCAikRev0Fs_s7u3_6beLOUe0Tp2DFfYFX3QAY=.7c47e54d-d891-48d0-89ca-06f478380565@github.com>

On Thu, 17 Jul 2025 15:00:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replaced use of JVMCIENV with JVMCI_CHECK_NULL in getDeclaredFieldsInfo

Marked as reviewed by never (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26346#pullrequestreview-3030157052

From dnsimon at openjdk.org  Thu Jul 17 16:22:54 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 17 Jul 2025 16:22:54 GMT
Subject: RFR: 8362306: HotSpotJVMCIRuntime.getMirror can crash [v6]
In-Reply-To: <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
 <V9r9ArehXayu7p13LroPKqdIvNzH_MLQK4pl8DX5JCg=.58acb1cd-bf69-4974-8917-f323c216012a@github.com>
Message-ID: <kPA1E0nyQOr8Vl7NBMdlDLUX4Vww-xzocud_Z61T4fg=.63bd3d2b-bc51-42d0-9926-a6ac729d5345@github.com>

On Thu, 17 Jul 2025 15:00:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replaced use of JVMCIENV with JVMCI_CHECK_NULL in getDeclaredFieldsInfo

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26346#issuecomment-3084663685

From dnsimon at openjdk.org  Thu Jul 17 16:22:54 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 17 Jul 2025 16:22:54 GMT
Subject: Integrated: 8362306: HotSpotJVMCIRuntime.getMirror can crash
In-Reply-To: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
References: <X2gk11BzMbRiJ2_7dee6VH1g0Ca0RJG6T8A5PLBrMGo=.4546ea3a-f8b3-4cf1-94fc-a086a62b6736@github.com>
Message-ID: <_ZZSxTjw3aPpjDUUwSQprjwqRqmcsNrfbcJg7FyI9uA=.35e55ffd-bdeb-4032-8604-b6b381dd1e76@github.com>

On Wed, 16 Jul 2025 08:35:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR fixes `HotSpotJVMCIRuntime.getMirror(ResolvedJavaMethod method)` and `HotSpotJVMCIRuntime.getMirror(ResolvedJavaField field)` so that they return null for `<clinit>` and an injected field respectively instead of crashing.

This pull request has now been integrated.

Changeset: 2b11a289
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b11a28997ad7ca424ad5595f9a7c7a9af530727
Stats:     77 lines in 6 files changed: 64 ins; 1 del; 12 mod

8362306: HotSpotJVMCIRuntime.getMirror can crash

Reviewed-by: gdub, never, cslucas

-------------

PR: https://git.openjdk.org/jdk/pull/26346

From lmesnik at openjdk.org  Thu Jul 17 16:28:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Jul 2025 16:28:57 GMT
Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop()
 != nullptr) failed: incomplete state [v3]
In-Reply-To: <ib0Kz9yCkvmgk43o4elt_UQ-yl_mJdBE7_9AWKwT-aw=.23aea65f-69e7-452b-8a01-22f74544136c@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
 <Hl7HowDq4SJ8ufrvovsMS1wc19xnhHnHfKqC-50Ofhk=.add313ec-31ad-4d6d-8da7-3b97c31ec1ec@github.com>
 <ib0Kz9yCkvmgk43o4elt_UQ-yl_mJdBE7_9AWKwT-aw=.23aea65f-69e7-452b-8a01-22f74544136c@github.com>
Message-ID: <0Ln5DfuXrOVhzTpTF_eNcYACNnubv9i-DIYRO-P_KJQ=.13b4c837-3547-4057-b3b0-efb5c8765a94@github.com>

On Thu, 17 Jul 2025 07:36:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed test
>
> Thank you for updates! Looks good.

@sspitsyn, @alexmenkov Thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26303#issuecomment-3084679519

From lmesnik at openjdk.org  Thu Jul 17 16:28:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Jul 2025 16:28:58 GMT
Subject: Integrated: 8362203: assert(state == nullptr ||
 state->get_thread_oop() != nullptr) failed: incomplete state
In-Reply-To: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
References: <UwsSGZPhAHnyMRC8ViWlM6W8pRlJIrhhnWixw6Ts_ps=.bc1b717e-dc4a-4f46-913b-63a4d0bca70b@github.com>
Message-ID: <ja2R5BgRtFTneN5Cc1EToXwS7amHcoZ16Uz-EL_5pYE=.a916308f-6b8f-49d5-918a-20cfa2749d2b@github.com>

On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
> 
> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed.

This pull request has now been integrated.

Changeset: bd55d7a4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd55d7a49514da9fa4de0d4a372956e21deab4d2
Stats:     20 lines in 4 files changed: 17 ins; 1 del; 2 mod

8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state

Reviewed-by: sspitsyn, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/26303

From jkratochvil at openjdk.org  Thu Jul 17 16:30:24 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 17 Jul 2025 16:30:24 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
Message-ID: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>

The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.

-------------

Commit messages:
 - 8362524: Fix confusing but harmless typos in x86 CPU Features

Changes: https://git.openjdk.org/jdk/pull/26371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362524
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26371/head:pull/26371

PR: https://git.openjdk.org/jdk/pull/26371

From rkennke at openjdk.org  Thu Jul 17 16:49:51 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Jul 2025 16:49:51 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
Message-ID: <AUuYFmIZ4RoHOcvPSJQGs-IOQLf-DFsIqwOsREY2xQg=.5a241abd-93ef-439d-862f-ab29f8734a03@github.com>

On Wed, 16 Jul 2025 14:01:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulnes:
>> 
>> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
>> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if its 0, we'd assert, if garbage, the resulting Klass* would be garbage.
>> - In print_failure, we now check pointers for readability before handing them to print_obj
>> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
>> - In print_obj, we print a small hex dump of the header (32bytes). With little cost we get a glance at the raw header and the first members.
>> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
>> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
>> 
>> Tests: I manually tested the patch with a number of manually broken oops of various flavours. 
>> 
>> Example output, invalid forwardee:
>> 
>> 
>> Referenced from:
>>   no interior location recorded (probably a plain heap scan, or detached oop)
>> 
>> Object:
>>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
>> 
>>         allocated after mark start
>>         after update watermark
>>         marked strong
>>         marked weak
>>     not in collection set
>>     mark:  marked(0xdeaddeaddeaddeaf)
>>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
>> 
>>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
>> 
>> Forwardee:
>>   0xdeaddeaddeaddeac - safe print, no details
>
> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>  - small revert
>  - cosmetics
>  - wip
>  - wip
>  - wip
>  - wip
>  - assert_correct

This looks really useful! I have only two comments/questions.

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 97:

> 95:   }
> 96:   const_address loc = cast_from_oop<const_address>(obj);
> 97:   os::print_hex_dump(&ss, loc, loc + 64, 4, true, 32, loc);

Does this need to check for heap-end boundary? Otherwise it may crash trying to print bytes from after the heap, which may not be mapped?

src/hotspot/share/utilities/ostream.hpp line 185:

> 183: 
> 184:  public:
> 185:   StreamIndentor(outputStream* os, int indentation = 2) :

Why do we need/want a default value here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26237#pullrequestreview-3030283146
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2213828033
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2213834183

From stuefe at openjdk.org  Thu Jul 17 17:15:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Jul 2025 17:15:50 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <AUuYFmIZ4RoHOcvPSJQGs-IOQLf-DFsIqwOsREY2xQg=.5a241abd-93ef-439d-862f-ab29f8734a03@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <AUuYFmIZ4RoHOcvPSJQGs-IOQLf-DFsIqwOsREY2xQg=.5a241abd-93ef-439d-862f-ab29f8734a03@github.com>
Message-ID: <25P0bDMiRExAxxdLwFbpsRQZOEnFfUkN9tLlmGJgycE=.9ce325b9-de0c-47b5-9b99-d4571cf7158b@github.com>

On Thu, 17 Jul 2025 16:42:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>>  - small revert
>>  - cosmetics
>>  - wip
>>  - wip
>>  - wip
>>  - wip
>>  - assert_correct
>
> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 97:
> 
>> 95:   }
>> 96:   const_address loc = cast_from_oop<const_address>(obj);
>> 97:   os::print_hex_dump(&ss, loc, loc + 64, 4, true, 32, loc);
> 
> Does this need to check for heap-end boundary? Otherwise it may crash trying to print bytes from after the heap, which may not be mapped?

No, that function is safe to use on any memory. It uses SafeFetch and prints dots for unreadable parts.

> src/hotspot/share/utilities/ostream.hpp line 185:
> 
>> 183: 
>> 184:  public:
>> 185:   StreamIndentor(outputStream* os, int indentation = 2) :
> 
> Why do we need/want a default value here?

Ease of use, and less code. And it softly enforces 2 as a standard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2213878925
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2213881467

From sparasa at openjdk.org  Thu Jul 17 17:17:07 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 17 Jul 2025 17:17:07 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>

> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
> 
> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
> 
> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  change to push_ppx/pop_ppx

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25889/files
  - new: https://git.openjdk.org/jdk/pull/25889/files/8e6e96c2..78cbf243

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25889&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25889&range=03-04

  Stats: 325 lines in 22 files changed: 0 ins; 0 del; 325 mod
  Patch: https://git.openjdk.org/jdk/pull/25889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25889/head:pull/25889

PR: https://git.openjdk.org/jdk/pull/25889

From sparasa at openjdk.org  Thu Jul 17 17:19:51 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 17 Jul 2025 17:19:51 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <OUqBL8hUqHNeYCVwHrMQf-PnhQPtNj50La_Z6hQNqTE=.c32f2e5f-a075-4d2e-afe5-6c378448f30b@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <OUqBL8hUqHNeYCVwHrMQf-PnhQPtNj50La_Z6hQNqTE=.c32f2e5f-a075-4d2e-afe5-6c378448f30b@github.com>
Message-ID: <3LY0CQRtD6KU5wYpQSaCA9Cbey8yV7epET1OSUjngSw=.052051e9-138d-490f-80e8-226c0a4dd4a5@github.com>

On Mon, 14 Jul 2025 17:44:15 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> My concerns have been addressed; thanks Vamsi for changing the names!

Thank you Vlad for the reviewing the PR!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25889#issuecomment-3084838188

From sparasa at openjdk.org  Thu Jul 17 17:19:54 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 17 Jul 2025 17:19:54 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v4]
In-Reply-To: <nfruVw1S1E9REEa9HWHj5CCbTbDQ_b6sFn3Hadb-afY=.a1551c69-55c3-4f00-809c-2cae4010d4a3@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <-V4hpHvXdaDjmEyYzHcEpDJ2bzPTqoz2Ao8FLobkmB8=.d9e3b962-ae8d-4e4b-8ddb-c3ab42a2a619@github.com>
 <nfruVw1S1E9REEa9HWHj5CCbTbDQ_b6sFn3Hadb-afY=.a1551c69-55c3-4f00-809c-2cae4010d4a3@github.com>
Message-ID: <2Br9Fr3vnPluq7XaWc9PPrDvRgVF6UAOYdUFJ4IO23w=.f8ac1e39-dc16-429a-a8a0-c68a4f2a44ea@github.com>

On Wed, 16 Jul 2025 20:55:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa 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 with master
>>  - remove pushp/popp from vm_version_x86 and also when APX is not being used
>>  - rename to paired_push and paired_pop
>>  - 8359965: Enable paired pushp and popp instruction usage for APX enabled CPUs
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 798:
> 
>> 796: }
>> 797: 
>> 798: void MacroAssembler::paired_push(Register src) {
> 
> Would be better to call these as push_ppx and pop_ppx.

Please see the updated code changed to push_ppx/pop_ppx.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2213890625

From jbhateja at openjdk.org  Thu Jul 17 17:29:49 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Jul 2025 17:29:49 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
Message-ID: <89ItZsQ_nWl3KWuRwdAqu3cMeostYVb1sO6qurvJ5qw=.2640ac03-ea33-4938-86c1-40033dea04a8@github.com>

On Thu, 17 Jul 2025 17:17:07 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to enhance the existing x86 assembly stubs using PUSH and POP instructions with paired PUSHP/POPP instructions which are part of Intel APX technology.
>> 
>> In Intel APX, the PUSHP and POPP instructions are modern, compact replacements for the legacy PUSH and POP, designed to work seamlessly with the expanded set of 32 general-purpose registers (R0?R31). Unlike their predecessors, they use the new APX (REX2-based) encoding, enabling more uniform and efficient instruction formats. These instructions improve code density, simplify register access, and are optimized for performance on APX-enabled CPUs.
>> 
>> Pairing PUSHP and POPP in Intel APX provides CPU-level benefits such as more efficient instruction decoding, better stack pointer tracking, and improved register dependency management. Their uniform encoding allows for streamlined execution, reduced pipeline stalls, and potential micro-op fusion, all of which enhance performance and power efficiency. This pairing helps the processor optimize speculative execution and register lifetimes, making code faster and more scalable on modern architectures.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to push_ppx/pop_ppx

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 806:

> 804: }
> 805: 
> 806: void MacroAssembler::pop_ppx(Register dst) {

Hi @vamsi-parasa , If you rename pop_ppx to pop and push_ppx to push, it will cut down the changes in this patch significantly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2213907529

From sparasa at openjdk.org  Thu Jul 17 18:41:55 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 17 Jul 2025 18:41:55 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <89ItZsQ_nWl3KWuRwdAqu3cMeostYVb1sO6qurvJ5qw=.2640ac03-ea33-4938-86c1-40033dea04a8@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
 <89ItZsQ_nWl3KWuRwdAqu3cMeostYVb1sO6qurvJ5qw=.2640ac03-ea33-4938-86c1-40033dea04a8@github.com>
Message-ID: <rjnWHcr6ZdXxk0jneoL9eMUt2izoT42UUcd0ZZiXGlU=.39d4ab25-5178-4011-8db7-2ab63e7f95ff@github.com>

On Thu, 17 Jul 2025 17:26:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change to push_ppx/pop_ppx
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 806:
> 
>> 804: }
>> 805: 
>> 806: void MacroAssembler::pop_ppx(Register dst) {
> 
> Hi @vamsi-parasa , If you rename pop_ppx to pop and push_ppx to push, it will cut down the changes in this patch significantly.

Hi Jatin (@jatin-bhateja), the intent is to make the use of the `pushp/popp` instructions explicit to the user, as not all `push` or `pop` instructions require the PPX feature.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2214035483

From missa at openjdk.org  Thu Jul 17 18:46:06 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 17 Jul 2025 18:46:06 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:

  Move error bound to separate section in comment header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26152/files
  - new: https://git.openjdk.org/jdk/pull/26152/files/9c5cc60c..c0adc8b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26152/head:pull/26152

PR: https://git.openjdk.org/jdk/pull/26152

From missa at openjdk.org  Thu Jul 17 18:51:47 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 17 Jul 2025 18:51:47 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
 <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
 <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>
Message-ID: <ia-MhOd66FkoS1hpvWHK_jGlQt_G9cytK6vK4zN9q-I=.ad70d25f-3d9e-4461-ad6b-744c33fc9edc@github.com>

On Thu, 10 Jul 2025 21:23:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > What is the accuracy of the algorithm in ulps (units the last place)?
> > > The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet.
> > 
> > 
> > 0.51 ulps
> 
> Please add that as a comment to the changeset.
> 
> Also, if the worst-case inputs for this algorithm are known, they should the added as part of the core libraries regression tests for the math library.

I included the error bound as a separate section of the comment header in the stub generator source file. Also, the input ranges are covered in `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3085084538

From jbhateja at openjdk.org  Thu Jul 17 19:04:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Jul 2025 19:04:53 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
Message-ID: <PBASmG3QVrMBsWrG16gr57QpNADErH--WFHfvDjGxHY=.5911e346-7a9e-4bf7-b8cf-4e554c5d0eec@github.com>

On Mon, 14 Jul 2025 08:15:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename to paired_push and paired_pop
>
> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 114:
> 
>> 112:         __ paired_push(rax);
>> 113:       }
>> 114:       __ paired_push(rcx);
> 
> Hi @vamsi-parasa , for consecutive push/pop we can use push2/pop2 and 16byte alignment can be  guaranteed using following technique 
> https://github.com/openjdk/jdk/pull/25351/files#diff-d5d721ebf93346ba66e81257e4f6c5e6268d59774313c61e97353c0dfbf686a5R94

> Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?
> 
> Thanks, Vamsi

Please create a new RFE for this for tracking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2214075909

From jbhateja at openjdk.org  Thu Jul 17 19:38:50 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Jul 2025 19:38:50 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <rjnWHcr6ZdXxk0jneoL9eMUt2izoT42UUcd0ZZiXGlU=.39d4ab25-5178-4011-8db7-2ab63e7f95ff@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
 <89ItZsQ_nWl3KWuRwdAqu3cMeostYVb1sO6qurvJ5qw=.2640ac03-ea33-4938-86c1-40033dea04a8@github.com>
 <rjnWHcr6ZdXxk0jneoL9eMUt2izoT42UUcd0ZZiXGlU=.39d4ab25-5178-4011-8db7-2ab63e7f95ff@github.com>
Message-ID: <MpWQ4LbHq_wOJNFeuwz8uRsI5LkXdQe9Id5Ixvbc-e4=.5ef2cc60-c45d-4c57-9b9a-ed9591e83cb2@github.com>

On Thu, 17 Jul 2025 18:39:04 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change to push_ppx/pop_ppx
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 806:
> 
>> 804: }
>> 805: 
>> 806: void MacroAssembler::pop_ppx(Register dst) {
> 
> Hi Jatin (@jatin-bhateja), the intent is to make the use of the `pushp/popp` instructions explicit to the user, as not all `push` or `pop` instructions require the PPX feature.

BTW, push/popp are meager optimization hints, if other constraints for balancing are not met the it will prevent value forwarding, so it's ok to keep the macro-assembly name same as the assembler name, fully qualified names Assembler::pop/push are sufficient to disambiguate in applicable scenarios or iff there is any such need.

I would have preferred keeping the same name to limit the changes in this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2214135683

From sviswanathan at openjdk.org  Thu Jul 17 19:52:59 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 17 Jul 2025 19:52:59 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
Message-ID: <hleKkjE_9b7rtEVKXNmNdU2YXGHKUoFfi0FAUgs8OBo=.5cdc6f02-482d-482d-b731-8f2965281eb2@github.com>

On Thu, 17 Jul 2025 17:17:07 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR adds support for the Push-Pop Acceleration (PPX) hint to legacy PUSH and POP instructions, enabling the PUSHP and POPP forms. The PPX hint improves performance by accelerating register value forwarding between matching push/pop pairs.
>> 
>> **Purpose:** PPX is a performance hint that allows the processor to bypass memory and the training loop of Fast Store Forwarding Predictor (FSFP) by directly forwarding data between paired PUSHP and POPP instructions.
>> 
>> **Requirements:** Both the PUSH and its matching POP must be marked with PPX. A "matching" pair accesses the same stack address (e.g., typical function prolog/epilog). Standalone PUSH instructions (e.g. for argument passing) must not be marked.
>> 
>> **Encoding:** PUSHP/POPP is a replacement for legacy PUSH/POP (0x50+rd / 0x58+rd) and uses REX2.W = 1 (implies 64-bit operand size). PPX cannot be encoded with 16-bit operand size as REX2.W overrides the 0x66 prefix.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to push_ppx/pop_ppx

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25889#pullrequestreview-3030827697

From sviswanathan at openjdk.org  Thu Jul 17 19:58:48 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 17 Jul 2025 19:58:48 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
Message-ID: <Nkj9DYmGX0zqhqM8AFgchM8E5kfl9Cttlx7hQyBKnUU=.01adbb7c-3c4d-4a4a-acc3-b19333144288@github.com>

On Thu, 17 Jul 2025 17:17:07 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR adds support for the Push-Pop Acceleration (PPX) hint to legacy PUSH and POP instructions, enabling the PUSHP and POPP forms. The PPX hint improves performance by accelerating register value forwarding between matching push/pop pairs.
>> 
>> **Purpose:** PPX is a performance hint that allows the processor to bypass memory and the training loop of Fast Store Forwarding Predictor (FSFP) by directly forwarding data between paired PUSHP and POPP instructions.
>> 
>> **Requirements:** Both the PUSH and its matching POP must be marked with PPX. A "matching" pair accesses the same stack address (e.g., typical function prolog/epilog). Standalone PUSH instructions (e.g. for argument passing) must not be marked.
>> 
>> **Encoding:** PUSHP/POPP is a replacement for legacy PUSH/POP (0x50+rd / 0x58+rd) and uses REX2.W = 1 (implies 64-bit operand size). PPX cannot be encoded with 16-bit operand size as REX2.W overrides the 0x66 prefix.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to push_ppx/pop_ppx

@vnkozlov Would it be possible for you to run this PR through your testing before we integrate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25889#issuecomment-3085295891

From iklam at openjdk.org  Thu Jul 17 22:24:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Jul 2025 22:24:09 GMT
Subject: RFR: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
Message-ID: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>

When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.

We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.

After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)

-------------

Commit messages:
 - 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking"

Changes: https://git.openjdk.org/jdk/pull/26374/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26374&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361725
  Stats: 65 lines in 5 files changed: 57 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26374/head:pull/26374

PR: https://git.openjdk.org/jdk/pull/26374

From kbarrett at openjdk.org  Fri Jul 18 00:32:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 18 Jul 2025 00:32:49 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
In-Reply-To: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
Message-ID: <yPmK-tnUgRQ3vcNstlkBogPk2A0GHltm8BiYhvS3AmE=.3bae4f5a-d829-425a-92d8-c832d8a4f5e4@github.com>

On Thu, 17 Jul 2025 16:24:43 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.

Changes requested by kbarrett (Reviewer).

src/hotspot/cpu/x86/vm_version_x86.cpp line 50:

> 48: VM_Version::CpuidInfo VM_Version::_cpuid_info = { 0, };
> 49: 
> 50: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) name,

I think the "typo" here is in the `#undef` rather than the define.  Calling this `xxx_NAME` seems
appropriate, since it is providing the name for the feature for collection in `_features_names[]`.
Places that are using `xxx_FLAG` are constructing the enumerator for the feature. There is no
requirement that all uses of an X-macro use the same name for the passed in macro, and indeed
it is quite normal to not do so.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26371#pullrequestreview-3031385928
PR Review Comment: https://git.openjdk.org/jdk/pull/26371#discussion_r2214569387

From jkratochvil at openjdk.org  Fri Jul 18 06:32:35 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 18 Jul 2025 06:32:35 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
 [v2]
In-Reply-To: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
Message-ID: <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>

> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Call it DECLARE_CPU_FEATURE_NAME

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26371/files
  - new: https://git.openjdk.org/jdk/pull/26371/files/56c13975..eb8a5261

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26371&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26371&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26371/head:pull/26371

PR: https://git.openjdk.org/jdk/pull/26371

From jkratochvil at openjdk.org  Fri Jul 18 06:32:36 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 18 Jul 2025 06:32:36 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
 [v2]
In-Reply-To: <yPmK-tnUgRQ3vcNstlkBogPk2A0GHltm8BiYhvS3AmE=.3bae4f5a-d829-425a-92d8-c832d8a4f5e4@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
 <yPmK-tnUgRQ3vcNstlkBogPk2A0GHltm8BiYhvS3AmE=.3bae4f5a-d829-425a-92d8-c832d8a4f5e4@github.com>
Message-ID: <bKOmaHvYxDRvAbIxXO5m61i3z93yia9mmq52pilbaHw=.380d78fa-ef21-4266-bffd-f465791c2efd@github.com>

On Fri, 18 Jul 2025 00:23:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Call it DECLARE_CPU_FEATURE_NAME
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 50:
> 
>> 48: VM_Version::CpuidInfo VM_Version::_cpuid_info = { 0, };
>> 49: 
>> 50: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) name,
> 
> I think the "typo" here is in the `#undef` rather than the define.  Calling this `xxx_NAME` seems
> appropriate, since it is providing the name for the feature for collection in `_features_names[]`.
> Places that are using `xxx_FLAG` are constructing the enumerator for the feature. There is no
> requirement that all uses of an X-macro use the same name for the passed in macro, and indeed
> it is quite normal to not do so.

Yes but then this typo has happened. Anyway it is changed now, thanks for the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26371#discussion_r2215092851

From kbarrett at openjdk.org  Fri Jul 18 08:04:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 18 Jul 2025 08:04:55 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
 [v2]
In-Reply-To: <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
 <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
Message-ID: <zoUtBSBQrlQmPaecGO-f1NXotYDCaL11NuMUG4NX7Gk=.4c2d907a-dea5-40f6-bb40-970d96956667@github.com>

On Fri, 18 Jul 2025 06:32:35 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call it DECLARE_CPU_FEATURE_NAME

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26371#pullrequestreview-3032455563

From lliu at openjdk.org  Fri Jul 18 10:15:53 2025
From: lliu at openjdk.org (Liming Liu)
Date: Fri, 18 Jul 2025 10:15:53 GMT
Subject: RFR: 8358032: Use crypto pmull for CRC32(C) on Ampere CPU and
 improve for short inputs [v5]
In-Reply-To: <VH-vgYI_OKfcQTVVrnakT_Zis6dGSHtWZg1Z_nRGwa8=.8761a86e-9bed-43f7-a8b3-20c169bc0f62@github.com>
References: <wOv8ZdTAm9-Krf90U16D5us21UbITIyg4Y6ujvABnFY=.e34a5cc9-d6ea-4de1-a539-e7f31559f291@github.com>
 <VH-vgYI_OKfcQTVVrnakT_Zis6dGSHtWZg1Z_nRGwa8=.8761a86e-9bed-43f7-a8b3-20c169bc0f62@github.com>
Message-ID: <aRsl-SGaVe_bq-KsrAOx4SMwGXfEseUfaU4KZwjGZNE=.a8bacb5b-e88f-4f16-826a-6bca08144130@github.com>

On Mon, 7 Jul 2025 06:21:24 GMT, Liming Liu <lliu at openjdk.org> wrote:

>> This PR is to enable the use of crypto pmull for CRC32/CRC32C intrinsics on Ampere CPU. There is an option UseCryptoPmullForCRC32 that can enable crypto pmull, but directly enabling it on Ampere CPU will cause the following problems.
>> 
>> 1. There will be regressions (-14% ~ -8%) on Ampere1 when the length is 64. When <= 128, both kernel_crc32_using_crc32 and kernel_crc32_using_crypto_pmull use the loop labeled as CRC_by32_loop, but their implements are a little different, and the loop in kernel_crc32_using_crc32 is better at hiding latency on Ampere1. So this PR takes the loop in kernel_crc32_using_crc32 to kernel_crc32_using_crypto_pmull, and does the same for CRC32C intrinsic.
>> 
>> 2. The intrinsics only use crypto pmull when the length is higher than 383, while the loop in kernel_crc32_common_fold_using_crypto_pmull looks able to handle 256, and if it handles 256 on Ampere1, the improvements can be as high as 110% compared with kernel_crc32_using_crc32/kernel_crc32c_using_crc32c. However, there are regressions (~-6%) on Neoverse V1 when the length is 256. So this PR introduces a new option named CryptoPmullForCRC32LowLimit. It defaults to 256 since the code could handle 256, while it is set to 384 for V1/V2 to keep the old behavior on these platforms.
>> 
>> The performance regressions and improvements were measured with the following microbenchmarks:
>> org.openjdk.bench.java.util.TestCRC32.testCRC32Update
>> org.openjdk.bench.java.util.TestCRC32C.testCRC32CUpdate
>> 
>> Ran the following JTReg tests on Ampere1 and did not find problems:
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java
>
> Liming Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Briefly explain the requirement of the option

Ping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25609#issuecomment-3088913963

From ayang at openjdk.org  Fri Jul 18 10:23:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 10:23:36 GMT
Subject: RFR: 8362592: Remove unused argument in nmethod::oops_do
Message-ID: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>

Trivial removing dead code.

-------------

Commit messages:
 - nmethod-trivial

Changes: https://git.openjdk.org/jdk/pull/26385/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362592
  Stats: 7 lines in 5 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26385/head:pull/26385

PR: https://git.openjdk.org/jdk/pull/26385

From duke at openjdk.org  Fri Jul 18 10:33:28 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 18 Jul 2025 10:33:28 GMT
Subject: RFR: 8362587: Sort share/oops includes
Message-ID: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>

This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

Passes tier1 and tier2 tests.

-------------

Commit messages:
 - sort includes in oops

Changes: https://git.openjdk.org/jdk/pull/26386/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26386&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362587
  Stats: 62 lines in 25 files changed: 34 ins; 27 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26386/head:pull/26386

PR: https://git.openjdk.org/jdk/pull/26386

From shade at openjdk.org  Fri Jul 18 10:33:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 10:33:29 GMT
Subject: RFR: 8362587: Sort share/oops includes
In-Reply-To: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
Message-ID: <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>

On Fri, 18 Jul 2025 10:25:41 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
> 
> Passes tier1 and tier2 tests.

Let's see if this breaks any builds. Meanwhile, see comments.

Also, can you please explicitly run `make test TEST=sources/TestIncludesAreSorted.java` to make sure it works?

test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 51:

> 49:                     "share/jvmci",
> 50:                     "share/opto",
> 51:                     "share/oops"

This order does not look lexicographic? `oops` < `opto`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26386#pullrequestreview-3033030746
PR Review Comment: https://git.openjdk.org/jdk/pull/26386#discussion_r2215695844

From duke at openjdk.org  Fri Jul 18 10:57:47 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 18 Jul 2025 10:57:47 GMT
Subject: RFR: 8362587: Sort share/oops includes
In-Reply-To: <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
Message-ID: <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>

On Fri, 18 Jul 2025 10:30:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Also, can you please explicitly run make test TEST=sources/TestIncludesAreSorted.java to make sure it works?

Yeah I did that before opening the PR, the test is running happily:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   jtreg:test/hotspot/jtreg/sources/TestIncludesAreSorted.java
                                                         1     1     0     0     0   
==============================
TEST SUCCESS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3089062214

From duke at openjdk.org  Fri Jul 18 11:12:40 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 18 Jul 2025 11:12:40 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
Message-ID: <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>

> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
> 
> Passes tier1 and tier2 tests.

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 three additional commits since the last revision:

 - lexycographic order in TestIncludesAreSorted
 - Merge branch 'master' into JDK-8362587-sort-oops-includes
 - sort includes in oops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26386/files
  - new: https://git.openjdk.org/jdk/pull/26386/files/5659fe92..06978ac6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26386&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26386&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26386/head:pull/26386

PR: https://git.openjdk.org/jdk/pull/26386

From duke at openjdk.org  Fri Jul 18 11:12:40 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 18 Jul 2025 11:12:40 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
Message-ID: <CAhcqyyUWyO-8n37ByiU-R4bLaLtOuR9QJb6NpGMRwc=.aa4e5541-948f-4a0a-a78a-3a0ae6a89244@github.com>

On Fri, 18 Jul 2025 10:28:32 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 three additional commits since the last revision:
>> 
>>  - lexycographic order in TestIncludesAreSorted
>>  - Merge branch 'master' into JDK-8362587-sort-oops-includes
>>  - sort includes in oops
>
> test/hotspot/jtreg/sources/TestIncludesAreSorted.java line 51:
> 
>> 49:                     "share/jvmci",
>> 50:                     "share/opto",
>> 51:                     "share/oops"
> 
> This order does not look lexicographic? `oops` < `opto`?

06978ac

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26386#discussion_r2215776199

From zgu at openjdk.org  Fri Jul 18 12:57:47 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 18 Jul 2025 12:57:47 GMT
Subject: RFR: 8362592: Remove unused argument in nmethod::oops_do
In-Reply-To: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
References: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
Message-ID: <ergg_91IpNL27ESNTUbrCM__mWoV4X-OHXP00fYLj3Q=.b17f5211-881b-4765-9e81-5d601c5a1eeb@github.com>

On Fri, 18 Jul 2025 10:17:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

LGTM and trivial

-------------

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26385#pullrequestreview-3033457173

From ayang at openjdk.org  Fri Jul 18 13:13:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:13:38 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - merge
 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=21
  Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Fri Jul 18 13:51:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:51:52 GMT
Subject: RFR: 8362592: Remove unused argument in nmethod::oops_do
In-Reply-To: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
References: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
Message-ID: <gNgji7nDH7SwtlyJRdeO7z5WO5CxZyTvVlyBuZN3Mjc=.c272ec7b-a0a1-424e-a422-93cf426e65f1@github.com>

On Fri, 18 Jul 2025 10:17:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26385#issuecomment-3089538753

From ayang at openjdk.org  Fri Jul 18 13:51:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 18 Jul 2025 13:51:53 GMT
Subject: Integrated: 8362592: Remove unused argument in nmethod::oops_do
In-Reply-To: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
References: <E6q8JSPdOZYxHWiztCWSTguPluUidVG6WcW_kYxnoOI=.2204ec1f-1b78-4ffe-ab05-6cea1f70e8b2@github.com>
Message-ID: <45Iv8tAvhm38PTIqU5i5YQEDvra10BiRMDRHMjjFabk=.6c9417e5-e46f-4eac-bbda-82b9180e3c4d@github.com>

On Fri, 18 Jul 2025 10:17:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

Changeset: 6949e345
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6949e345757b010790b2a6f5a975fc1c6bd0e8c6
Stats:     7 lines in 5 files changed: 0 ins; 1 del; 6 mod

8362592: Remove unused argument in nmethod::oops_do

Reviewed-by: zgu

-------------

PR: https://git.openjdk.org/jdk/pull/26385

From shade at openjdk.org  Fri Jul 18 14:00:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 14:00:48 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
Message-ID: <RzW5pEWedbMUK0nsNu11Gd9438voSw50ShtDb5nIrcI=.ddd02328-950e-4e2e-bb82-699b58b55996@github.com>

On Fri, 18 Jul 2025 11:12:40 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
>> 
>> Passes tier1 and tier2 tests, and GHA tests.
>
> 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 three additional commits since the last revision:
> 
>  - lexycographic order in TestIncludesAreSorted
>  - Merge branch 'master' into JDK-8362587-sort-oops-includes
>  - sort includes in oops

Seems like we are good! Let's see if anyone from Runtime team agrees as well.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26386#pullrequestreview-3033647445

From kvn at openjdk.org  Fri Jul 18 15:09:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 18 Jul 2025 15:09:48 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
 [v2]
In-Reply-To: <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
 <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
Message-ID: <SzkhYBiNbHjEj7QJbkJy69h7VwvDPsksqfwSxLIPCeA=.ee7149d7-452c-470b-aa60-63561259bd30@github.com>

On Fri, 18 Jul 2025 06:32:35 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call it DECLARE_CPU_FEATURE_NAME

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26371#pullrequestreview-3033915669

From duke at openjdk.org  Fri Jul 18 16:59:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 18 Jul 2025 16:59:39 GMT
Subject: RFR: 8362524: Fix confusing but harmless typos in x86 CPU Features
 [v2]
In-Reply-To: <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
 <eYYeVijhcEt89Pu09u67d2BUiQWgLV31Ay6uaUc0Utg=.5ab83fdd-e3e9-4cbb-a069-9f26b6daac02@github.com>
Message-ID: <hnvcQ16182nPeYjKgYxy_TCTcDdd62CjwFaVbPYBkns=.ad6d4c06-81d2-4c8f-bf29-7066123e3f7a@github.com>

On Fri, 18 Jul 2025 06:32:35 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call it DECLARE_CPU_FEATURE_NAME

@jankratochvil 
Your change (at version eb8a5261346bcd0e78e47f455fe8d2ef36911671) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26371#issuecomment-3089902470

From matsaave at openjdk.org  Fri Jul 18 16:59:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 18 Jul 2025 16:59:49 GMT
Subject: RFR: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
In-Reply-To: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
References: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
Message-ID: <P7ToVMleQclLS8IINHva8GXgt-HOcWKHAbXtg6bco2A=.b85cb902-e69a-40f6-b130-cbaba8201571@github.com>

On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.
> 
> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.
> 
> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)

LGTM!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26374#pullrequestreview-3034015196

From ccheung at openjdk.org  Fri Jul 18 16:59:59 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 18 Jul 2025 16:59:59 GMT
Subject: RFR: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
In-Reply-To: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
References: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
Message-ID: <wRc9biddKIXnOT9Lqw7i9BgZsyVsQ_tUWvr1VxBbUBg=.0ff67159-43e6-4395-8d3d-cb7bae5684ec@github.com>

On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.
> 
> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.
> 
> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)

Looks good.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgentTransformer.java line 41:

> 39:         savedInstrumentation = instrumentation;
> 40: 
> 41:         LOGGER.log(Level.WARNING, "JavaAgentTransformer::premain() is finished");

Just curious why not use `Level.INFO` instead. Is it because the log won't be printed with product build if `Level.INFO` is used?

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26374#pullrequestreview-3034175116
PR Review Comment: https://git.openjdk.org/jdk/pull/26374#discussion_r2216471537

From jkratochvil at openjdk.org  Fri Jul 18 17:19:45 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 18 Jul 2025 17:19:45 GMT
Subject: Integrated: 8362524: Fix confusing but harmless typos in x86 CPU
 Features
In-Reply-To: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
References: <YY431MAznFymvd5AUCgePXxz6NDySTNmk8R_CrFjDpU=.cdeb6692-25af-45d7-be82-aa716cef5061@github.com>
Message-ID: <8CBTIbYdAjDgt_Uo8Y1Fl4qiAlPxJoYSRCu9EnZZ2_M=.83041cc3-e7ea-46d1-9029-0b74295af0b8@github.com>

On Thu, 17 Jul 2025 16:24:43 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`.

This pull request has now been integrated.

Changeset: 60c29ff5
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60c29ff57b22fa7c0bedb38316067e8e1988a24b
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8362524: Fix confusing but harmless typos in x86 CPU Features

Reviewed-by: kbarrett, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/26371

From jiangli at openjdk.org  Fri Jul 18 19:41:33 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 18 Jul 2025 19:41:33 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions
Message-ID: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>

Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.

Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.

-------------

Commit messages:
 - - Change 'do_arch_blob' to use 'PRODUCT_ONLY(20000) NOT_PRODUCT(21000)' for size estimate.

Changes: https://git.openjdk.org/jdk/pull/26395/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26395&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362564
  Stats: 9 lines in 2 files changed: 5 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26395/head:pull/26395

PR: https://git.openjdk.org/jdk/pull/26395

From iklam at openjdk.org  Fri Jul 18 21:32:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Jul 2025 21:32:55 GMT
Subject: RFR: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
In-Reply-To: <P7ToVMleQclLS8IINHva8GXgt-HOcWKHAbXtg6bco2A=.b85cb902-e69a-40f6-b130-cbaba8201571@github.com>
References: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
 <P7ToVMleQclLS8IINHva8GXgt-HOcWKHAbXtg6bco2A=.b85cb902-e69a-40f6-b130-cbaba8201571@github.com>
Message-ID: <X8g54sLBqPtn_QTaWuxXyp40NRlLp-IpffTIJ2wZn5Q=.d540f1e2-16e3-4acd-aae3-0d1e3308d5e9@github.com>

On Fri, 18 Jul 2025 15:41:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.
>> 
>> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.
>> 
>> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)
>
> LGTM!

Thanks @matias9927 @calvinccheung for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26374#issuecomment-3090763537

From iklam at openjdk.org  Fri Jul 18 21:32:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Jul 2025 21:32:56 GMT
Subject: RFR: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
In-Reply-To: <wRc9biddKIXnOT9Lqw7i9BgZsyVsQ_tUWvr1VxBbUBg=.0ff67159-43e6-4395-8d3d-cb7bae5684ec@github.com>
References: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
 <wRc9biddKIXnOT9Lqw7i9BgZsyVsQ_tUWvr1VxBbUBg=.0ff67159-43e6-4395-8d3d-cb7bae5684ec@github.com>
Message-ID: <B-2-PAL50QzZMdzVoE8sXpPp8acOhKIgtsPyAMXz_80=.4b2fe745-08f7-443f-93d3-944f141f22b7@github.com>

On Fri, 18 Jul 2025 16:43:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.
>> 
>> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.
>> 
>> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgentTransformer.java line 41:
> 
>> 39:         savedInstrumentation = instrumentation;
>> 40: 
>> 41:         LOGGER.log(Level.WARNING, "JavaAgentTransformer::premain() is finished");
> 
> Just curious why not use `Level.INFO` instead. Is it because the log won't be printed with product build if `Level.INFO` is used?

I copied this code from the original reproducer. If this code was executed inside the assembly phase, then we will get a CDSHeapVerifier error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26374#discussion_r2216943972

From iklam at openjdk.org  Fri Jul 18 21:32:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Jul 2025 21:32:56 GMT
Subject: Integrated: 8361725: Do not load Java agent with
 "-Xshare:dump -XX:+AOTClassLinking"
In-Reply-To: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
References: <CoM4pNz-Wj4o7KHFrSTFe7ChVLqtTXxHF7AyhRksnfg=.a1169436-f57d-4092-9c21-1f672fa748eb@github.com>
Message-ID: <SKFfmUAfX9VD26OA8UmLQ3i62ysK5YcMgwfeZ2zzyhY=.9233df96-25d6-42d5-a589-7691f81205f9@github.com>

On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe.
> 
> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`.
> 
> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561)

This pull request has now been integrated.

Changeset: 9334fe2e
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9334fe2eca05e852875ed6aad42b5094a32e9b15
Stats:     65 lines in 5 files changed: 57 ins; 1 del; 7 mod

8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking"

Reviewed-by: matsaave, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/26374

From jrose at openjdk.org  Fri Jul 18 23:20:40 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 18 Jul 2025 23:20:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
Message-ID: <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>

On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?

This is a good question.  Suppose IC1 calls IC2 and both are intrinsic candidates, and suppose that M1 and M2 are their checked "front doors".

I think the answer has to be that, once you start executing IC1, you cannot expect any further checks.  Probably some assembler macro implements IC2 and it may be called from more than one place.  The tricky thing to prove is that all uses of IC2's intrinsic code, whether direct (via M2) or indirect (via things like M1) have adequate checks.

If intrinsics are factored this way (as they are for string methods) I think that IC1 has to advertise that it calls IC2, so that the front door method M1 is responsible for validity checks for both IC1 and IC2.  That is because after intrinsic expansion, IC2 is reached without going through M2; the entry was indirectly from M1.  So M1 has to duplicate M2's front door checks.

To make this workable, it may be that M2's front door checks are factored into a subroutine FD2, so that M1 can refer to FD2, rather than do risky code duplication.

If (as in this case) IC2 loops over calls to IC1, then perhaps M2 should have a companion method FD2R which checks a range a range of inputs to IC2, so that M1 can call FD2R.  If all goes well, then FD2R has a range check that duplicates the front door logic of M1, so that the JIT can remove the duplicate checking.

In the case of `StringUTF16.getChar`, I see it is marked as trusted, and it does not have a front-door method, and does have many callers.  In the terms of this PR, perhaps it should be renamed `getChar0` (or the like) to make it more clear (at non-local use points) that it must be called from trusted code.  Perhaps it should also have a range check method associated with it, so that some callers can use that range check method, so that the non-local responsibility is more clearly fulfilled.

Maybe some callers (if less performance critical) should be changed to call a properly checked front-door method, `getChar` (as opposed to `getChar0`).  Remaining callers of `getChar0` should be clearly linked to the front-door checks required by `getChar0`.

The above seems to be the principled way to deal with an unchecked intrinsic called from many trusted use sites.  The basic idea is that every trusted use site should reaffirm its responsibility locally, not just hope that a non-local assert will catch a bug.  We want some kind of reviewable (static/local) proof that each use site (of an unchecked private intrinsics) has correct checks.

Some examples:  A new front-door `getChar` method can be used in less important places like `AbstractStringBuilder::getChar`.

In trusted loops over `getChar` like `String::encodeASCII`, the loop containing `getChar` can be prefaced by a range check which is batched for all the loop iterations, something like `StringUTF16.getCharChecks(val, 0, len)`.  The same pattern occurs in `String::encode8859_1` and `encodeUTF8_UTF16` and `computeSizeUTF8_UTF16` and maybe elsewhere.  The `val` reference and limit variable `len` or `sl` should be marked `final` to ensure that the batched range check remains correct (because it should not take loop-variant inputs).

As I read through `String.java` I see that a batched range check would cover a lot of use cases?  I haven't read though all the uses of `getChar`, however.

The intrinsic `encodeISOArray0` (was `implEncodeISOArray`) calls `getChar`.  This is an example where its front door method (now `encodeISOArray` with no "0") should call a batched check method like `getCharBatchChecks`.  Let's look at this in detail.  The `getCharBatchChecks` method could look like this:


//non-public
void getCharBatchChecks(byte[] val, int charStart, int charSize) {
  Objects.requireNonNull(val, "val");  // *** what style guide mandates this line??
  Preconditions.checkFromIndexSize(charStart << 1, charSize << 1, val.length, Preconditions.AIOOBE_FORMATTER);
  // *** using "char" in the names helps reduce confusion from the mix of byte and char indexes
}
?
static int encodeISOArray(?) {
    ?
    StringUTF16.getCharBatchChecks(sa, sp, len);  // next method loops over getChar(sa, sp++)
    return encodeISOArray0(sa, sp, da, dp, len);
}


Note that after inlining, the batch checks exactly match pre-existing checks for the caller intrinsic.  Perhaps the caller's checks could be removed manually, or perhaps the JIT removes the duplication.

Actually, I think you got this documentation wrong:


@param sp the index of the <em>byte (not character!)</em> from the source array to start reading from


AFAICT, `sp` is a char index; note that `getChar` scales it as `(index=sp)<<1`.

Note that `getChar` has zero javadoc, so you are left to guess helplessly about its index operand.

This stuff is complicated to get right.  The above exercise in wiring up the checking logic tends to uncover bugs and misconceptions, I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3091231708

From iklam at openjdk.org  Sat Jul 19 01:59:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 19 Jul 2025 01:59:36 GMT
Subject: RFR: 8362829: Exclude CDS test cases after JDK-8361725
Message-ID: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>

These two test cases uses Java agents. Since [JDK-8361725](https://bugs.openjdk.org/browse/JDK-8361725) disallows Java agents with `-XX:+AOTClassLinking`, these two tests be excluded from the test group `test/hotspot/jtreg:hotspot_aot_classlinking`

-------------

Commit messages:
 - 8362829: Exclude CDS test cases after JDK-8361725

Changes: https://git.openjdk.org/jdk/pull/26400/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362829
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26400.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26400/head:pull/26400

PR: https://git.openjdk.org/jdk/pull/26400

From ccheung at openjdk.org  Sat Jul 19 02:07:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 19 Jul 2025 02:07:48 GMT
Subject: RFR: 8362829: Exclude CDS test cases after JDK-8361725
In-Reply-To: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>
References: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>
Message-ID: <zFSVMFqBb_LWon5S6jwHNPoMwYeFBcaNi4iPbkKZ8Gg=.21779c8e-95d2-41b9-ab14-71e483fd80f5@github.com>

On Sat, 19 Jul 2025 01:52:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> These two test cases uses Java agents. Since [JDK-8361725](https://bugs.openjdk.org/browse/JDK-8361725) disallows Java agents with `-XX:+AOTClassLinking`, these two tests be excluded from the test group `test/hotspot/jtreg:hotspot_aot_classlinking`

Looks good and trivial to me.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26400#pullrequestreview-3035063871

From iklam at openjdk.org  Sat Jul 19 02:07:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 19 Jul 2025 02:07:48 GMT
Subject: RFR: 8362829: Exclude CDS test cases after JDK-8361725
In-Reply-To: <zFSVMFqBb_LWon5S6jwHNPoMwYeFBcaNi4iPbkKZ8Gg=.21779c8e-95d2-41b9-ab14-71e483fd80f5@github.com>
References: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>
 <zFSVMFqBb_LWon5S6jwHNPoMwYeFBcaNi4iPbkKZ8Gg=.21779c8e-95d2-41b9-ab14-71e483fd80f5@github.com>
Message-ID: <e_3weSytw7fGBnMj02smcx6YftPUl70e2EpI6si4tdY=.2ac419f8-680b-4d53-92d0-a84e230f1a89@github.com>

On Sat, 19 Jul 2025 02:03:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> These two test cases uses Java agents. Since [JDK-8361725](https://bugs.openjdk.org/browse/JDK-8361725) disallows Java agents with `-XX:+AOTClassLinking`, these two tests be excluded from the test group `test/hotspot/jtreg:hotspot_aot_classlinking`
>
> Looks good and trivial to me.

Thanks @calvinccheung for the review. Local testing shows that these two tests are no longer executed with `test/hotspot/jtreg:hotspot_aot_classlinking`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26400#issuecomment-3091383785

From iklam at openjdk.org  Sat Jul 19 02:07:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 19 Jul 2025 02:07:48 GMT
Subject: Integrated: 8362829: Exclude CDS test cases after JDK-8361725
In-Reply-To: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>
References: <oKel4xHkJleiwP-f4X-8VF4FJVvtDF526SypH-bioQ4=.e096f5e0-5ee0-4fe4-bd64-c1b22a3e75c2@github.com>
Message-ID: <8ZX52ZUel6NF4XsEoobcOUfiFOQnZNc6nMbCHUsirjU=.e170e9c5-cf16-4f83-b42c-f143feb624f0@github.com>

On Sat, 19 Jul 2025 01:52:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> These two test cases uses Java agents. Since [JDK-8361725](https://bugs.openjdk.org/browse/JDK-8361725) disallows Java agents with `-XX:+AOTClassLinking`, these two tests be excluded from the test group `test/hotspot/jtreg:hotspot_aot_classlinking`

This pull request has now been integrated.

Changeset: ceb51d44
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ceb51d44449977ecc142f6af03f93162b98adaf6
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8362829: Exclude CDS test cases after JDK-8361725

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/26400

From jrose at openjdk.org  Sat Jul 19 06:25:46 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 19 Jul 2025 06:25:46 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
 <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>
Message-ID: <-Slk7vUMDszUJMCmtPgaiWeUdmBszJpUOmkkxTGTe38=.f460e240-44d5-4e44-b0c3-ad073315c8c8@github.com>

On Fri, 18 Jul 2025 23:18:16 GMT, John R Rose <jrose at openjdk.org> wrote:

> If (as in this case) IC2 loops over calls to IC1
Correction; I meant IC1 calls IC2, in a loop, N times.  We don't want a pre-loop in M1 that checks each of N distinct arguments to IC2 (like N calls to M2 would), but rather a batch check routine which checks all of the arguments to IC2, in O(1) time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3091934621

From stuefe at openjdk.org  Sun Jul 20 05:30:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 20 Jul 2025 05:30:54 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space
Message-ID: <e7K9hloTVns_L6mpJEgB192r_5jRUm0zyO6ThMl8ti0=.068e7e7f-bd03-48e5-98bd-66a3dd61868a@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 (the latter still ongoing). Test were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing 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.

-------------

Commit messages:
 - copyrights
 - fix big-endian problem on AIX
 - Update klass.cpp
 - Update metaspace.hpp
 - Update metaspace.hpp
 - Update metaspace.hpp
 - fix rebase error
 - fix mac build
 - rebase, fixes

Changes: https://git.openjdk.org/jdk/pull/25891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340297
  Stats: 482 lines in 26 files changed: 398 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 eastigeevich at openjdk.org  Sun Jul 20 13:46:22 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 20 Jul 2025 13:46:22 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
Message-ID: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>

### Background

With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.

On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.

### Summary of changes

* Rewrote Mac AArch64 `SpinPause` not to use a jump table.
* Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
* Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
* `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
* Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
* Added a gtest to verify the functionality of `SpinPause`.
* Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.

### Testing results: fastdebug, release

- Linux, Graviton 2
   - tier1: Passed
   - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
   - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
- MacOS, M3 Pro
   - tier1, OnSpinWaitInst=default: Passed
   - tier1, OnSpinWaitInst=sb: Passed
   - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
   - `test/hotspot/jtreg/compiler/onSpinWait`: Passed

-------------

Commit messages:
 - Add missing include
 - Update SpinWait constraints; Add test ids
 - Fix mac compile errors
 - Fix mac compile errors
 - Fix mac compile errors
 - Remove spin_wait_aarch64.inline.hpp; Combine TestSpinPauseAArch64 and TestSpinPauseSBAArch64
 - Clarify assert message
 - Fix whitespace error
 - Assert SB support
 - Correct call of exec_spin_wait_inst
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7da274de...d47fa11b

Changes: https://git.openjdk.org/jdk/pull/26387/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26387&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362193
  Stats: 238 lines in 10 files changed: 183 ins; 15 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/26387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26387/head:pull/26387

PR: https://git.openjdk.org/jdk/pull/26387

From shade at openjdk.org  Sun Jul 20 13:46:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 20 Jul 2025 13:46:23 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <fkUvxikC-uepAyD08AfeLSAcEli902q5E_0yoDXsSi4=.3231982b-871e-45ac-8aa8-196ef17ae0d0@github.com>

On Fri, 18 Jul 2025 13:11:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

Overall, I think it is not very reasonable to pull things into shared parts, when that deviates significantly from the common Hotspot way of handling things. I don't think it even saves us any duplication to move implementations to `spin_wait_aarch64.(inline.)pp`? So I suggest we don't.

More reviews. 

I think the PR drifted from my initial "oh, just assert range problem" to "Re-work MacOS/AArch64 spin-waits to handle SB". Rewrite the JBS/PR title accordingly?

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 118:

> 116:           "Value -1 means off.")                                        \
> 117:           range(-1, 4096)                                               \
> 118:   product(ccstr, OnSpinWaitInst, DEFAULT_SPIN_WAIT_INST, DIAGNOSTIC,    \

It is somewhat weird to introduce references to macros here. At some point, this might lead to _interesting_ include circularities, as I think `globals.*` are supposed to be at the leaves of include trees. Other options do not do this, see for example `UseBranchProtection` below. So, keep this part intact?

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 54:

> 52: 
> 53: static SpinWait get_spin_wait_desc() {
> 54:   if (!SpinWait::supports(OnSpinWaitInst)) {

So this is not about the actual spin-wait hints support, correct? This only checks the option string is in expected domain? A common way to deal with this is to use constraint functions, see for example:


  product(ccstr, AOTCache, nullptr,                                         \
          "Cache for improving start up and warm up")                       \
          constraint(AOTCacheConstraintFunc, AtParse)                       \
                                                                            \

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 546:

> 544:     assert(inst_id != SpinWait::SB || VM_Version::supports_sb(), "current CPU does not support SB instruction");
> 545:     if (inst_id > SpinWait::NOP) {
> 546:       warining("Unsupported type of SpinWait::Inst: %d", inst_id);

`warning`

Also, I think we want to minimize the amount of code we actually execute in `SpinPause`, since it likely sits in the hot loop. So checking this here is probably counter-productive.

test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java line 25:

> 23: 
> 24: /*
> 25:  * @test TestSpinPauseAArch64

A common way to tag the tests:


@test id=default


I assume all these are supported in ARMv8.0 (default? baseline?) profile. That's why I put `default`. Put something else if that is incorrect.

Same for the second `@test` block.

test/hotspot/jtreg/gtest/TestSpinPauseSBAArch64.java line 32:

> 30:  * @requires os.arch=="aarch64"
> 31:  * @requires vm.cpu.features ~= ".*sb.*"
> 32:  * @run main/native GTestWrapper --gtest_filter=SpinPause* -XX:+UnlockDiagnosticVMOptions -XX:OnSpinWaitInst=sb

This configuration is for `@requires vm.cpu.features ~= ".*sb.*"`, correct?

If so, you can put this entire `@test` block in the `TestSpinPauseAArch64.java`, then jtreg would just execute them as subtests. Here is an inspiration: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java

-------------

PR Review: https://git.openjdk.org/jdk/pull/26387#pullrequestreview-3033656122
PR Review: https://git.openjdk.org/jdk/pull/26387#pullrequestreview-3034111169
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216124860
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216440371
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216466816
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216117779
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216427945
PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2216117555

From eastigeevich at openjdk.org  Sun Jul 20 13:46:23 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 20 Jul 2025 13:46:23 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <fkUvxikC-uepAyD08AfeLSAcEli902q5E_0yoDXsSi4=.3231982b-871e-45ac-8aa8-196ef17ae0d0@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <fkUvxikC-uepAyD08AfeLSAcEli902q5E_0yoDXsSi4=.3231982b-871e-45ac-8aa8-196ef17ae0d0@github.com>
Message-ID: <IVJhFIRyUMtklP0b4319G4S2_gvaVjzyfRV6p9rV8-s=.a342f188-3c46-4b2d-88d4-555f4449f400@github.com>

On Fri, 18 Jul 2025 14:07:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Overall, I think it is not very reasonable to pull things into shared parts, when that deviates significantly from the common Hotspot way of handling things. I don't think it even saves us any duplication to move implementations to `spin_wait_aarch64.(inline.)pp`? So I suggest we don't.

Do I understand you correctly we should not have `exec_spin_wait_inst` and `generate_spin_wait`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3089631917

From shade at openjdk.org  Sun Jul 20 13:46:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 20 Jul 2025 13:46:23 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <IVJhFIRyUMtklP0b4319G4S2_gvaVjzyfRV6p9rV8-s=.a342f188-3c46-4b2d-88d4-555f4449f400@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <fkUvxikC-uepAyD08AfeLSAcEli902q5E_0yoDXsSi4=.3231982b-871e-45ac-8aa8-196ef17ae0d0@github.com>
 <IVJhFIRyUMtklP0b4319G4S2_gvaVjzyfRV6p9rV8-s=.a342f188-3c46-4b2d-88d4-555f4449f400@github.com>
Message-ID: <3zGeaaA_3KT4ZpznupT_H3nJzRKPRzTpgfkRAVK5jfQ=.27e4daba-0872-4032-809c-9b6613e8ea27@github.com>

On Fri, 18 Jul 2025 14:17:55 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Overall, I think it is not very reasonable to pull things into shared parts, when that deviates significantly from the common Hotspot way of handling things. I don't think it even saves us any duplication to move implementations to `spin_wait_aarch64.(inline.)pp`? So I suggest we don't.
> 
> Do I understand you correctly we should not have `exec_spin_wait_inst` and `generate_spin_wait`?

Yes. I don't see a benefit for them? Collecting everything related to spin wait implementation is not worth it, IMO. We have duplication by asm-stubs, macroassembler, c1_assembler, c2.ad rules for the arch-specific code already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3089741127

From dholmes at openjdk.org  Mon Jul 21 04:30:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 04:30:42 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <0n3lTxam4BV78nLT72ReL5b-slMyXSOTwtklVChVLJg=.f639619a-0bea-4e7e-af28-e61adfae667c@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
 <0n3lTxam4BV78nLT72ReL5b-slMyXSOTwtklVChVLJg=.f639619a-0bea-4e7e-af28-e61adfae667c@github.com>
Message-ID: <PMSu_hNK3qeEoKAEuzC4DQtG0POU25dKrWU9lsr-w54=.50fd13fc-124b-4a53-83f2-065adbb12574@github.com>

On Thu, 17 Jul 2025 07:51:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With `JvmtiVTMSTransitionDisabler` there is normally no need in the carrier thread protection. A virtual thread is either mounted or unmounted. There is no carrier thread when virtual thread is unmounted. If virtual thread is mounted and VTMS transitions are disabled then the carrier thread is blocked until VTMS transitions are enabled again and the execution control is returned to the carrier. But JVMTI is playing by the established rules and always using TLH to protect the JavaThread associated with the virtual thread and its carrier.
>
>> @sspitsyn can you clarify this please. When you take a thread dump via the HotsotDiagnosticMXBean is there a JVMTI agent involved? Because that code uses the transition disabler.
> 
> Yes, we have this issue for `HotsotDiagnosticMXBean.dumpThreads` as Alan has pointed out. We are aware about it and will evaluate a couple of fixing approaches.

> Thread::getStackTrace handles this with a SUSPEND bit and loop.

Okay so that loop keeps retrying any time we get a null stacktrace from the VM, and unless we are extremely unlucky it should only take a couple of attempts to get an actual stack.

So that just leaves the issue of the carrier thread terminating, which is what this current fix was trying to address. So we need to ensure the carrier is protected by the TLH, which is what my other fix will address.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2218159540

From dholmes at openjdk.org  Mon Jul 21 04:30:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 04:30:42 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v4]
In-Reply-To: <PMSu_hNK3qeEoKAEuzC4DQtG0POU25dKrWU9lsr-w54=.50fd13fc-124b-4a53-83f2-065adbb12574@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <iUhkJplRSal88njqnx8Huz9SJBcdZaTGao5CuU-evhU=.5caf2c20-32db-4a1b-bc28-d502a9d51033@github.com>
 <kbcuHkTWao2U63D1yPQ31X-IUHW7SnTFO-cgvdhKW08=.8c60b58a-ab53-4ad6-8cc0-5ad9a1066d6c@github.com>
 <sQkngImXVzt0DVQ76ibWQ2Mndiye1Dj2H-Ey-IUZmeA=.c186e238-d1e0-406f-9718-5f4a6c2a1cf4@github.com>
 <koCQDk9gCynl0Tf2YPMxUZjPqLVUu6h2ibUECamUSf4=.492ecb00-4e8e-432a-bff5-081739cdf153@github.com>
 <PHyOHSl9fkVnINUNz2sy4Ra_-o6SxmWOakQVE8F81X0=.f3343ad8-5571-4719-aaae-0275f629b9ad@github.com>
 <V2DibyKzrphCKT0bntLU6gN5qsgwvDuoEpAI8SGH46c=.979e7019-d657-472c-a2bf-b5c96057101f@github.com>
 <5gUy1zmrWNwF4uWzFPkh6fX4ONJqdfH7yM9k_rhepl4=.05943db3-cff5-48e2-a91d-9bacbad48e29@github.com>
 <0n3lTxam4BV78nLT72ReL5b-slMyXSOTwtklVChVLJg=.f639619a-0bea-4e7e-af28-e61adfae667c@github.com>
 <PMSu_hNK3qeEoKAEuzC4DQtG0POU25dKrWU9lsr-w54=.50fd13fc-124b-4a53-83f2-065adbb12574@github.com>
Message-ID: <xs-we0YV_WV1ThFufXSFhbjZLhdFOKo2CY9TWCwDBRI=.4e1f0a2b-c28e-4659-8ef8-f79c5775a981@github.com>

On Mon, 21 Jul 2025 04:27:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> @sspitsyn can you clarify this please. When you take a thread dump via the HotsotDiagnosticMXBean is there a JVMTI agent involved? Because that code uses the transition disabler.
>> 
>> Yes, we have this issue for `HotsotDiagnosticMXBean.dumpThreads` as Alan has pointed out. We are aware about it and will evaluate a couple of fixing approaches.
>
>> Thread::getStackTrace handles this with a SUSPEND bit and loop.
> 
> Okay so that loop keeps retrying any time we get a null stacktrace from the VM, and unless we are extremely unlucky it should only take a couple of attempts to get an actual stack.
> 
> So that just leaves the issue of the carrier thread terminating, which is what this current fix was trying to address. So we need to ensure the carrier is protected by the TLH, which is what my other fix will address.

BTW we need some comments making it clear that all null returns are handled via a retry at the higher level Java code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26119#discussion_r2218160074

From dholmes at openjdk.org  Mon Jul 21 05:42:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 05:42:39 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
 <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>
Message-ID: <YJadQQ15apYcUY1lrjTUzD1aG8vTNsICCGN7zloFDCg=.308f144e-1ce8-42ad-8118-d9c393b3e7c6@github.com>

On Fri, 18 Jul 2025 10:55:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Yeah I did that before opening the PR, the test is running happily:

And yet you had an error in the order as @shipilev  pointed out - so how does that work?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3095278126

From dholmes at openjdk.org  Mon Jul 21 05:53:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 05:53:42 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
Message-ID: <iLP6mm0cjPwHQoK85lz9HwP_ehyXdpCOF4JAGYB0fj8=.885813d4-ffbb-453d-8af4-c907e20a2edc@github.com>

On Fri, 18 Jul 2025 11:12:40 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
>> 
>> Passes tier1 and tier2 tests, and GHA tests.
>
> 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 three additional commits since the last revision:
> 
>  - lexycographic order in TestIncludesAreSorted
>  - Merge branch 'master' into JDK-8362587-sort-oops-includes
>  - sort includes in oops

That all seems fine to me. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26386#pullrequestreview-3036629793

From jiangli at openjdk.org  Mon Jul 21 07:18:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 21 Jul 2025 07:18:55 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
Message-ID: <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>

On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - Some more from reviews
>  - Reviewed the diff on github
>  - Stage
>  - Missed comment updates
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b

@liach Sorry for the delay. I looked through your changes and it's good to see that we are moving away from the hard-code list of classes, etc in the VM code for archiving/caching initialized states. The mechanism of marking class/methods/fields in the Java source is a good start for the more general support.

A few suggestions (or comments) for future considerations not don't necessarily to be included in your current PR:

- heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.
- There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.
- As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.
- It's important to enhance the heap archiving mechanism to safeguard the cached object graphs to make sure they can be materialized safely for runtime usages without any unexpected side-effects. Restrictions/assumptions such as the ones that you documented in AOTSafeClassInitializer.java should be built into the heap archiving and ensured at AOT assembling phase or CDS archive time. We can look into extracting some of the parts from https://github.com/jianglizhou/jdk11u-fast-startup-incubator for the heap archiving related enhancements.


/// `@AOTSafeClassInitializer`. This should be done when:
///
/// 1. It's possible for an artifact used in the linking java.lang.invoke primitives
///    (usually a MethodHandle) to directly or indirectly remember the value of a static
///    field in this class.
/// 2. You have validated that the static initializer of this class doesn't depend on
///    transient states (i.e., names of temporary directories) that cannot be carried over
///    to a future production run.
/// 3. All supertypes of this class must also have the `@AOTSafeClassInitializer`
///    annotation.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3036852633

From shade at openjdk.org  Mon Jul 21 07:37:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 07:37:49 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <YJadQQ15apYcUY1lrjTUzD1aG8vTNsICCGN7zloFDCg=.308f144e-1ce8-42ad-8118-d9c393b3e7c6@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
 <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>
 <YJadQQ15apYcUY1lrjTUzD1aG8vTNsICCGN7zloFDCg=.308f144e-1ce8-42ad-8118-d9c393b3e7c6@github.com>
Message-ID: <u7SEgpCFhVzNueQgSq25Bt3vaAgClYviec-iR80raG8=.c0920ee7-2948-4131-a37f-d8bb2ffca7e9@github.com>

On Mon, 21 Jul 2025 05:40:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Yeah I did that before opening the PR, the test is running happily:
> 
> And yet you had an error in the order as @shipilev pointed out - so how does that work?

The test does not test its own declared package order, and it is not even supposed to, I think. So that one was purely cosmetic :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3095572845

From shade at openjdk.org  Mon Jul 21 07:47:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 07:47:40 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions
In-Reply-To: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
Message-ID: <FNF467sNBDc2FR1Letp_7NkIVEZ-KVLswmv3k7dc0AA=.13b9722a-b122-47be-bfa0-ddd135666d37@github.com>

On Fri, 18 Jul 2025 19:33:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
> 
> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.

@adinn  ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3095611281

From duke at openjdk.org  Mon Jul 21 08:27:39 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 21 Jul 2025 08:27:39 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <u7SEgpCFhVzNueQgSq25Bt3vaAgClYviec-iR80raG8=.c0920ee7-2948-4131-a37f-d8bb2ffca7e9@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
 <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>
 <YJadQQ15apYcUY1lrjTUzD1aG8vTNsICCGN7zloFDCg=.308f144e-1ce8-42ad-8118-d9c393b3e7c6@github.com>
 <u7SEgpCFhVzNueQgSq25Bt3vaAgClYviec-iR80raG8=.c0920ee7-2948-4131-a37f-d8bb2ffca7e9@github.com>
Message-ID: <3VBmLzoK6Mgk25SYOXgToAv2bUFgJM_xadW0kVHvkMs=.168a4d68-14a5-44f1-b0f7-f4c29a1ecf40@github.com>

On Mon, 21 Jul 2025 07:35:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Yeah I did that before opening the PR, the test is running happily:
>> 
>> And yet you had an error in the order as @shipilev  pointed out - so how does that work?
>
>> > Yeah I did that before opening the PR, the test is running happily:
>> 
>> And yet you had an error in the order as @shipilev pointed out - so how does that work?
> 
> The test does not test its own declared package order, and it is not even supposed to, I think. So that one was purely cosmetic :)

Thank you @shipilev and @dholmes-ora for your reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3095704316

From duke at openjdk.org  Mon Jul 21 08:27:42 2025
From: duke at openjdk.org (duke)
Date: Mon, 21 Jul 2025 08:27:42 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <K6tPBtdxwOKHXDGeAp2esGp9-qiPf7xKHLrbW4WUYcY=.0eba9b35-029f-48b6-a338-5895904613e2@github.com>
Message-ID: <UPNakBpjqLn88znpMCqhS889hA3cBvwfo_jBt56iP0I=.df559783-5659-43f9-b4fd-30195140df9a@github.com>

On Fri, 18 Jul 2025 11:12:40 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
>> 
>> Passes tier1 and tier2 tests, and GHA tests.
>
> 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 three additional commits since the last revision:
> 
>  - lexycographic order in TestIncludesAreSorted
>  - Merge branch 'master' into JDK-8362587-sort-oops-includes
>  - sort includes in oops

@fandreuz 
Your change (at version 06978ac6c021fe693e100f0d038bcbd7c079b802) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3095708446

From dholmes at openjdk.org  Mon Jul 21 08:32:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 08:32:16 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does
 not deal with a virtual thread's carrier thread
Message-ID: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>

The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).

It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.

Testing:
- tiers 1-4

Thanks

-------------

Commit messages:
 - Revert to simpler fix without new API
 - Revert "Adapt ThreadSnapshotFactory::get_thread_snapshot to use the new API"
 - Remove unused JvmtiExport::cv_oop_to_JavaThread API
 - Adapt ThreadSnapshotFactory::get_thread_snapshot to use the new API
 - Adapt thread conversion routines to return (and protect) the carrier

Changes: https://git.openjdk.org/jdk/pull/26287/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361912
  Stats: 87 lines in 4 files changed: 19 ins; 54 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287

PR: https://git.openjdk.org/jdk/pull/26287

From duke at openjdk.org  Mon Jul 21 08:46:47 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 21 Jul 2025 08:46:47 GMT
Subject: Integrated: 8362587: Sort share/oops includes
In-Reply-To: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
Message-ID: <CwAwAzlSr4QC3SEtP-i6J7LQ3GkWG__KKwMNAIfzxhA=.7138c8e0-7482-427e-b57f-9e3fc2a7afbd@github.com>

On Fri, 18 Jul 2025 10:25:41 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/oops` using `test/hotspot/jtreg/sources/SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.
> 
> Passes tier1 and tier2 tests, and GHA tests.

This pull request has now been integrated.

Changeset: 37b70707
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37b70707bd9d4c1eb2db6ed438b5f4f5b49fa202
Stats:     61 lines in 25 files changed: 34 ins; 27 del; 0 mod

8362587: Sort share/oops includes

Reviewed-by: shade, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26386

From aph at openjdk.org  Mon Jul 21 08:51:40 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 08:51:40 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>

On Fri, 18 Jul 2025 13:11:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 577:

> 575:         "4:                      \n"
> 576:         :
> 577:         : [id]"r"(inst_id)

There's no good reason to handle all this logic in asm. Please use a switch statement instead, and we can also get rid of most of the assertions by adding a ShouldNotReachHere() in the default clause.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2218554094

From aph at openjdk.org  Mon Jul 21 09:04:44 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 09:04:44 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>

On Fri, 18 Jul 2025 13:11:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

Do you not think we should implement the Arm-recommended solution in https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3095806217

From dholmes at openjdk.org  Mon Jul 21 12:03:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 12:03:59 GMT
Subject: RFR: 8362587: Sort share/oops includes [v2]
In-Reply-To: <u7SEgpCFhVzNueQgSq25Bt3vaAgClYviec-iR80raG8=.c0920ee7-2948-4131-a37f-d8bb2ffca7e9@github.com>
References: <AbcWDTU53b9VwKCy9A6-LKXcIkJPsSE0c5vjCuZMKyE=.a75952a5-223a-4ed8-ab6d-37eb9779cac5@github.com>
 <Dg7IrquLDZbJLgPG6DMps5CWMhxd01Pamhj6B7h4kA0=.bfb86d03-6464-4878-b034-3b269242ef26@github.com>
 <x-gEhA1ICef8N59P3bdOdFueTz-P_F9nDExVKKSJYzk=.29a674d3-51ac-46ad-a964-5d31310b3d47@github.com>
 <YJadQQ15apYcUY1lrjTUzD1aG8vTNsICCGN7zloFDCg=.308f144e-1ce8-42ad-8118-d9c393b3e7c6@github.com>
 <u7SEgpCFhVzNueQgSq25Bt3vaAgClYviec-iR80raG8=.c0920ee7-2948-4131-a37f-d8bb2ffca7e9@github.com>
Message-ID: <EJxsScldvcuuQxaMHwA7lmiwyAM3HaqEtqT5w031vOo=.e805fea0-4990-4e07-8c32-df7891d37fcb@github.com>

On Mon, 21 Jul 2025 07:35:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The test does not test its own declared package order,

Sorry - yes completely misread that one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26386#issuecomment-3096452370

From vyazici at openjdk.org  Mon Jul 21 12:33:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:33:30 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici 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:

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Make `StringCoding` encoding intrinsics lenient
 - Fix `encodeISOArray` bounds checks and Javadoc
 - Disable `TestVerifyIntrinsicChecks` for GraalVM
 - Relax target array capacity check for intrinsic Java wrappers
   
   It's not possible to determine the required capacity of the target
   array in constant time, as Unicode code points may occupy either one
   or two `char` values. As a result, existing implementations typically
   invoke encoding methods in a loop, handling each unmappable character
   on a case-by-case basis. For an example, see
   `sun.nio.cs.DoubleByte.Encoder::encode`.
 - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
 - Replace casting with `as_Region()` in `generate_string_range_check`
 - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
 - Fix compiler error in `generate_string_range_check`
 - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
 - ... and 13 more: https://git.openjdk.org/jdk/compare/c179d680...f69374fb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/db1ed388..f69374fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=07-08

  Stats: 13609 lines in 414 files changed: 10649 ins; 1054 del; 1906 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Mon Jul 21 12:41:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:41:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
 <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
Message-ID: <vTTemkuBpipqCFqjjT42XgDO3LKVEhSwCZFLgiYYu5o=.600dfb3b-f433-4783-98a3-be207b52241b@github.com>

On Wed, 16 Jul 2025 05:28:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volkan Yazici 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 remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Apply review feedback (styling changes)
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename
>>  - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases
>>    
>>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>>  - Improve intrinsics in `StringCoding`
>>  - Add `StringCodingCountPositives` benchmark
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c4b2ddec...85f19864
>
> src/hotspot/share/opto/c2_globals.hpp line 665:
> 
>> 663:           "prints attempted and successful inlining of intrinsics")         \
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 
> We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

Given @TobiHartmann's later approval, I'm marking this as resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219089077

From vyazici at openjdk.org  Mon Jul 21 12:46:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:46:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
Message-ID: <hRPSasIDVR6ergOr_PqzMio-teConjBQ3eb0qXMyEmk=.2aaec7cb-36b3-4f9d-949d-e81c8f3f55df@github.com>

On Thu, 17 Jul 2025 13:58:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringCoding.java line 130:
> 
>> 128:      * <p>
>> 129:      * This method assumes that {@code sa} is encoded in UTF-16, and hence,
>> 130:      * each {@code char} maps to 2 bytes.
> 
> Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph?

It might be obvious to some, but some (incl. myself) got really confused on what input arguments actually denote, and how they are operated. I'm inclined to keep the for-dummies explanation, unless there is a strong objection.

> src/java.base/share/classes/java/lang/StringCoding.java line 150:
> 
>> 148:         Objects.requireNonNull(sa, "sa");
>> 149:         Objects.requireNonNull(da, "da");
>> 150:         Preconditions.checkFromIndexSize(sp, len << 1, sa.length, Preconditions.AIOOBE_FORMATTER);
> 
> Since `sp` is a character index and `len` counts characters but `sa.length` is in bytes, this should look like so
> Suggestion:
> 
>         Preconditions.checkFromIndexSize(sp, len, sa.length >>> 1, Preconditions.AIOOBE_FORMATTER);
> 
> or something similar.

Very sharp of you @rgiulietti! Thanks so much! ? Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219097580
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219099452

From vyazici at openjdk.org  Mon Jul 21 12:46:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:46:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>
Message-ID: <z5DWubj_VZ1lPSLtqXMxZ2eLA_O293UoO7a75VVb4B4=.728ced9b-a203-47fa-8c6f-a8ce7f5361d4@github.com>

On Thu, 17 Jul 2025 15:02:21 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> could you please add ` * @requires !vm.graal.enabled`? Graal is failing this test

@mur47x111 added in 4016c7a1fe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219101443

From vyazici at openjdk.org  Mon Jul 21 12:52:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:52:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <LtJhO7a1IgjmD5zAKXBEdQFkrat31lyzQCmDicOJIls=.8b45fc4f-5d9d-494f-8bb3-1f2070dd0807@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Remove superseded `@throws` Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/f69374fb..86e3ed8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Mon Jul 21 12:52:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:52:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
Message-ID: <IEqpJSNVHphgf3oTw6QcCE_T6xlQjxhx5CTv-KvxWOY=.1e27b168-f0fa-4bc6-8712-c1b371f0e489@github.com>

On Mon, 21 Jul 2025 12:33:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - Fix `encodeISOArray` bounds checks and Javadoc
>  - Disable `TestVerifyIntrinsicChecks` for GraalVM
>  - Relax target array capacity check for intrinsic Java wrappers
>    
>    It's not possible to determine the required capacity of the target
>    array in constant time, as Unicode code points may occupy either one
>    or two `char` values. As a result, existing implementations typically
>    invoke encoding methods in a loop, handling each unmappable character
>    on a case-by-case basis. For an example, see
>    `sun.nio.cs.DoubleByte.Encoder::encode`.
>  - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
>  - Replace casting with `as_Region()` in `generate_string_range_check`
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`
>  - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/514f29e4...f69374fb

Needed to replace all `Preconditions` invocations throwing `AIOOB` on failure with a more lenient approach that returns 0 on out-of-bounds, because,

1. this matches the compiler intrinsic behavior
2. there are several (i.e., ~7) `sun.nio.cs` classes that depend on this lenient behavior. I needed to either fix(?) these 7 classes or make the intrinsic wrappers more lenient

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096649239

From vyazici at openjdk.org  Mon Jul 21 12:54:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:54:50 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
Message-ID: <yY_P2SdSfsmzi5cbyKNGc9SDG51PucXPQkIXSBqIJwQ=.c8f111a9-13e6-458e-8695-0a8009421689@github.com>

On Mon, 21 Jul 2025 12:33:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - Fix `encodeISOArray` bounds checks and Javadoc
>  - Disable `TestVerifyIntrinsicChecks` for GraalVM
>  - Relax target array capacity check for intrinsic Java wrappers
>    
>    It's not possible to determine the required capacity of the target
>    array in constant time, as Unicode code points may occupy either one
>    or two `char` values. As a result, existing implementations typically
>    invoke encoding methods in a loop, handling each unmappable character
>    on a case-by-case basis. For an example, see
>    `sun.nio.cs.DoubleByte.Encoder::encode`.
>  - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
>  - Replace casting with `as_Region()` in `generate_string_range_check`
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`
>  - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/343fc72a...f69374fb

> > What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
> 
> ...
> In the case of `StringUTF16.getChar`, ...

@rgiulietti, thanks so much for this crucial question. @rose00, thanks so much for the elaborate response. I will work on `StringUTF16` in a separate PR and use these guidelines provided. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096668620

From eastigeevich at openjdk.org  Mon Jul 21 12:57:40 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 12:57:40 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>
Message-ID: <7AIC7kPYWB133weIDM4wtwDat4H4dfuNqH_alS5wkh4=.f9aa934d-689c-4991-86af-7d61fc4d12d3@github.com>

On Mon, 21 Jul 2025 09:02:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Do you not think we should implement the Arm-recommended solution in https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm?

When we get armv8.7 hardware, I'd like to try their solution.
`ISB`-based solution is looked tuned for Graviton 2/3/4. I see it is implemented to support delays requested in ns. Do we request ns delays in Hotspot?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3096687839

From eastigeevich at openjdk.org  Mon Jul 21 13:04:57 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 13:04:57 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
Message-ID: <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>

On Mon, 21 Jul 2025 08:49:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> ### Background
>> 
>> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
>> 
>> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
>> 
>> ### Summary of changes
>> 
>> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
>> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
>> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
>> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
>> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
>> * Added a gtest to verify the functionality of `SpinPause`.
>> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
>> 
>> ### Testing results: fastdebug, release
>> 
>> - Linux, Graviton 2
>>    - tier1: Passed
>>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
>> - MacOS, M3 Pro
> ...
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 577:
> 
>> 575:         "4:                      \n"
>> 576:         :
>> 577:         : [id]"r"(inst_id)
> 
> There's no good reason to handle all this logic in asm. Please use a switch statement instead, and we can also get rid of most of the assertions by adding a ShouldNotReachHere() in the default clause.

I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655

Frederick (@fbredber) wanted to avoid branches: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219152883

From vyazici at openjdk.org  Mon Jul 21 13:28:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 13:28:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix bit shifting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/86e3ed8d..025c7ef7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From eastigeevich at openjdk.org  Mon Jul 21 13:46:24 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 13:46:24 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <gWtYeYjpv8_fIwmBwNPKTlQDKXm8_olkkpjaHLbO_wU=.c796b90b-34b0-4e96-bf0c-155f591e7e57@github.com>

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Reimplement with switch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26387/files
  - new: https://git.openjdk.org/jdk/pull/26387/files/d47fa11b..e984fdeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26387&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26387&range=00-01

  Stats: 56 lines in 2 files changed: 1 ins; 31 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/26387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26387/head:pull/26387

PR: https://git.openjdk.org/jdk/pull/26387

From eastigeevich at openjdk.org  Mon Jul 21 13:50:40 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 13:50:40 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
Message-ID: <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>

On Mon, 21 Jul 2025 13:01:56 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 577:
>> 
>>> 575:         "4:                      \n"
>>> 576:         :
>>> 577:         : [id]"r"(inst_id)
>> 
>> There's no good reason to handle all this logic in asm. Please use a switch statement instead, and we can also get rid of most of the assertions by adding a ShouldNotReachHere() in the default clause.
>
> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655
> 
> Frederick (@fbredber) wanted to avoid branches: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740

The switch-based version is committed: https://github.com/openjdk/jdk/pull/26387/commits/e984fdeb10cc91a04860cbdbe45aacb05c4ffd3e

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219270154

From vyazici at openjdk.org  Mon Jul 21 13:56:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 13:56:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
Message-ID: <Blo9pDxu4WBRhzk6vqcKJ75-W1BhkhONP-zoBDM182Y=.40b7806b-d5b8-49b1-83fe-62f8745fac71@github.com>

On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method?
>> Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
>
>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
> 
> To reformulate my confusing question for the above example, there are apparently around 75-80 invocations of `getChar()`. How to make sure that they are all safe? Some are easy to verify, but others are not.

Even though the `tier1,tier2,tier3,tier4,tier5,hs-comp-stress,hs-precheckin-comp` tests pass on several platforms, @rgiulietti pointed me other shortcomings regarding the recent lenient approach taken. Please allow me some time with this PR. I will keep this PR updated. :popcorn:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096882515

From myankelevich at openjdk.org  Mon Jul 21 15:42:27 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 21 Jul 2025 15:42:27 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
Message-ID: <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>

On Mon, 21 Jul 2025 13:28:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit shifting

Minor: could you please add a bug id to the `@bug` annotations in tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3097286276

From jbhateja at openjdk.org  Mon Jul 21 15:48:28 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Jul 2025 15:48:28 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
 <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
Message-ID: <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>

On Mon, 14 Jul 2025 17:27:35 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 114:
>> 
>>> 112:         __ paired_push(rax);
>>> 113:       }
>>> 114:       __ paired_push(rcx);
>> 
>> Hi @vamsi-parasa , for consecutive push/pop we can use push2/pop2 and 16byte alignment can be  guaranteed using following technique 
>> https://github.com/openjdk/jdk/pull/25351/files#diff-d5d721ebf93346ba66e81257e4f6c5e6268d59774313c61e97353c0dfbf686a5R94
>
> Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?
> 
> Thanks,
> Vamsi

Hi @vamsi-parasa , I think it's ok not to expose pop_ppx / push_ppx as separate interfaces, and let processor forward the values b/w push and matching pop if balancing constraints are satisfied.

<img width="1055" height="151" alt="image" src="https://github.com/user-attachments/assets/6923ca1b-11eb-4fae-8d51-14f1bfe27cea" />

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2219586716

From shade at openjdk.org  Mon Jul 21 16:13:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 16:13:33 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
Message-ID: <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>

On Mon, 21 Jul 2025 13:48:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655
>> 
>> Frederick (@fbredber) wanted to avoid branches: https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740
>
> The switch-based version is committed: https://github.com/openjdk/jdk/pull/26387/commits/e984fdeb10cc91a04860cbdbe45aacb05c4ffd3e

OK, so this inline assembly was to optimize `SpinPause`, since it sits in hot loop. Have you looked at disassembly for `SpinPause` before/after? On my M1, I see this:


% lldb -o "disassemble -n SpinPause" -o quit -- build/macosx-aarch64-server-release/images/jdk/lib/server/libjvm.dylib

# Before
libjvm.dylib`::SpinPause():
libjvm.dylib[0x89f0d4] <+0>:  stp    x29, x30, [sp, #-0x10]!
libjvm.dylib[0x89f0d8] <+4>:  mov    x29, sp
libjvm.dylib[0x89f0dc] <+8>:  adrp   x8, 1409
libjvm.dylib[0x89f0e0] <+12>: add    x8, x8, #0x80 ; VM_Version::_spin_wait
libjvm.dylib[0x89f0e4] <+16>: ldrsw  x8, [x8]
libjvm.dylib[0x89f0e8] <+20>: lsl    x8, x8, #3
libjvm.dylib[0x89f0ec] <+24>: adr    x9, 0x89f100 ; <+44> at os_bsd_aarch64.cpp:545:5
libjvm.dylib[0x89f0f0] <+28>: add    x9, x9, x8
libjvm.dylib[0x89f0f4] <+32>: br     x9
libjvm.dylib[0x89f0f8] <+36>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
libjvm.dylib[0x89f0fc] <+40>: nop    
libjvm.dylib[0x89f100] <+44>: nop    
libjvm.dylib[0x89f104] <+48>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
libjvm.dylib[0x89f108] <+52>: isb    
libjvm.dylib[0x89f10c] <+56>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
libjvm.dylib[0x89f110] <+60>: yield  
libjvm.dylib[0x89f114] <+64>: mov    w0, #0x1 ; =1 
libjvm.dylib[0x89f118] <+68>: ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x89f11c] <+72>: ret  

# After
libjvm.dylib`::SpinPause():
libjvm.dylib[0x89f074] <+0>:   stp    x29, x30, [sp, #-0x10]!
libjvm.dylib[0x89f078] <+4>:   mov    x29, sp
libjvm.dylib[0x89f07c] <+8>:   adrp   x8, 1409
libjvm.dylib[0x89f080] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
libjvm.dylib[0x89f084] <+16>:  ldr    w8, [x8]
libjvm.dylib[0x89f088] <+20>:  add    w8, w8, #0x1
libjvm.dylib[0x89f08c] <+24>:  cmp    w8, #0x4
libjvm.dylib[0x89f090] <+28>:  b.hi   0x89f0ec       ; <+120> at os_bsd_aarch64.cpp:551:7
libjvm.dylib[0x89f094] <+32>:  adrp   x9, 0
libjvm.dylib[0x89f098] <+36>:  add    x9, x9, #0xfc ; ___lldb_unnamed_symbol66913
libjvm.dylib[0x89f09c] <+40>:  adr    x10, 0x89f09c ; <+40> at os_bsd_aarch64.cpp
libjvm.dylib[0x89f0a0] <+44>:  ldrsw  x11, [x9, x8, lsl #2]
libjvm.dylib[0x89f0a4] <+48>:  add    x10, x10, x11
libjvm.dylib[0x89f0a8] <+52>:  br     x10
libjvm.dylib[0x89f0ac] <+56>:  nop    
libjvm.dylib[0x89f0b0] <+60>:  mov    w0, #0x1 ; =1 
libjvm.dylib[0x89f0b4] <+64>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x89f0b8] <+68>:  ret    
libjvm.dylib[0x89f0bc] <+72>:  isb    
libjvm.dylib[0x89f0c0] <+76>:  mov    w0, #0x1 ; =1 
libjvm.dylib[0x89f0c4] <+80>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x89f0c8] <+84>:  ret    
libjvm.dylib[0x89f0cc] <+88>:  yield  
libjvm.dylib[0x89f0d0] <+92>:  mov    w0, #0x1 ; =1 
libjvm.dylib[0x89f0d4] <+96>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x89f0d8] <+100>: ret    
libjvm.dylib[0x89f0dc] <+104>: sb     
libjvm.dylib[0x89f0e0] <+108>: mov    w0, #0x1 ; =1 
libjvm.dylib[0x89f0e4] <+112>: ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x89f0e8] <+116>: ret    
libjvm.dylib[0x89f0ec] <+120>: adrp   x0, 1063
libjvm.dylib[0x89f0f0] <+124>: add    x0, x0, #0xe2a ; "src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp"
libjvm.dylib[0x89f0f4] <+128>: mov    w1, #0x227 ; =551 
libjvm.dylib[0x89f0f8] <+132>: bl     0x311f84       ; report_should_not_reach_here at debug.cpp:247


So I think switch is fairly well compiled. On first glance, it generates more code by duplicating the epilog for every case, but I think that is a bit cleaner than trying to do branch-overs. It generates marginally better code if you place `case` in enum order, and do `should_not_reach` here branch only for debug builds:


#ifdef ASSERT
    default:
      ShouldNotReachHere();
#endif

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219649388

From aph at openjdk.org  Mon Jul 21 16:13:32 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 16:13:32 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <7AIC7kPYWB133weIDM4wtwDat4H4dfuNqH_alS5wkh4=.f9aa934d-689c-4991-86af-7d61fc4d12d3@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>
 <7AIC7kPYWB133weIDM4wtwDat4H4dfuNqH_alS5wkh4=.f9aa934d-689c-4991-86af-7d61fc4d12d3@github.com>
Message-ID: <-IINGwsF992Al0naVREDpvE6nE6FamJ1EOIoIB3aEK0=.65daa4d8-af68-4376-a210-5826879d24ed@github.com>

On Mon, 21 Jul 2025 12:55:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Do you not think we should implement the Arm-recommended solution in https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm?
> 
> When we get armv8.7 hardware, I'd like to try their solution. 

OK, that makes sense.

>`ISB`-based solution is looked tuned for Graviton 2/3/4. I see it is implemented to support delays requested in ns. Do we request ns delays in Hotspot?

I don't think that matters. We should experiment whan we have hardware to find a sensible default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3097382695

From aph at openjdk.org  Mon Jul 21 16:20:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 16:20:30 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
Message-ID: <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>

On Mon, 21 Jul 2025 16:11:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The switch-based version is committed: https://github.com/openjdk/jdk/pull/26387/commits/e984fdeb10cc91a04860cbdbe45aacb05c4ffd3e
>
> OK, so this inline assembly was to optimize `SpinPause`, since it sits in hot loop. Have you looked at disassembly for `SpinPause` before/after? On my M1, I see this:
> 
> 
> % lldb -o "disassemble -n SpinPause" -o quit -- build/macosx-aarch64-server-release/images/jdk/lib/server/libjvm.dylib
> 
> # Before
> libjvm.dylib`::SpinPause():
> libjvm.dylib[0x89f0d4] <+0>:  stp    x29, x30, [sp, #-0x10]!
> libjvm.dylib[0x89f0d8] <+4>:  mov    x29, sp
> libjvm.dylib[0x89f0dc] <+8>:  adrp   x8, 1409
> libjvm.dylib[0x89f0e0] <+12>: add    x8, x8, #0x80 ; VM_Version::_spin_wait
> libjvm.dylib[0x89f0e4] <+16>: ldrsw  x8, [x8]
> libjvm.dylib[0x89f0e8] <+20>: lsl    x8, x8, #3
> libjvm.dylib[0x89f0ec] <+24>: adr    x9, 0x89f100 ; <+44> at os_bsd_aarch64.cpp:545:5
> libjvm.dylib[0x89f0f0] <+28>: add    x9, x9, x8
> libjvm.dylib[0x89f0f4] <+32>: br     x9
> libjvm.dylib[0x89f0f8] <+36>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
> libjvm.dylib[0x89f0fc] <+40>: nop    
> libjvm.dylib[0x89f100] <+44>: nop    
> libjvm.dylib[0x89f104] <+48>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
> libjvm.dylib[0x89f108] <+52>: isb    
> libjvm.dylib[0x89f10c] <+56>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
> libjvm.dylib[0x89f110] <+60>: yield  
> libjvm.dylib[0x89f114] <+64>: mov    w0, #0x1 ; =1 
> libjvm.dylib[0x89f118] <+68>: ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x89f11c] <+72>: ret  
> 
> # After
> libjvm.dylib`::SpinPause():
> libjvm.dylib[0x89f074] <+0>:   stp    x29, x30, [sp, #-0x10]!
> libjvm.dylib[0x89f078] <+4>:   mov    x29, sp
> libjvm.dylib[0x89f07c] <+8>:   adrp   x8, 1409
> libjvm.dylib[0x89f080] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
> libjvm.dylib[0x89f084] <+16>:  ldr    w8, [x8]
> libjvm.dylib[0x89f088] <+20>:  add    w8, w8, #0x1
> libjvm.dylib[0x89f08c] <+24>:  cmp    w8, #0x4
> libjvm.dylib[0x89f090] <+28>:  b.hi   0x89f0ec       ; <+120> at os_bsd_aarch64.cpp:551:7
> libjvm.dylib[0x89f094] <+32>:  adrp   x9, 0
> libjvm.dylib[0x89f098] <+36>:  add    x9, x9, #0xfc ; ___lldb_unnamed_symbol66913
> libjvm.dylib[0x89f09c] <+40>:  adr    x10, 0x89f09c ; <+40> at os_bsd_aarch64.cpp
> libjvm.dylib[0x89f0a0] <+44>:  ldrsw  x11, [x9, x8, lsl #2]
> libjvm.dylib[0x89f0a4] <+48>:  add    x10, x10, x11
> libjvm.dylib[0x89f0a8] <+52>:  br     x10
> libjvm.dylib[0x89f0ac] <+56>:  nop    
> libjvm.dylib[0x89f0b0] <+60>:  mov    w0, #0x1 ; =1 
> libjvm.dylib[0x89f0b4] <+64>:  ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x89f0b8] <+68>:  ret    
> libjvm.dylib[0x89f0bc] <+72>:  isb    
> libjvm.dylib[0x89f0...

Exactly. When writing inline asm, it doesn't much help to try to out-guess the compiler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219660187

From aph at openjdk.org  Mon Jul 21 16:20:31 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 16:20:31 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
Message-ID: <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>

On Mon, 21 Jul 2025 16:16:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> OK, so this inline assembly was to optimize `SpinPause`, since it sits in hot loop. Have you looked at disassembly for `SpinPause` before/after? On my M1, I see this:
>> 
>> 
>> % lldb -o "disassemble -n SpinPause" -o quit -- build/macosx-aarch64-server-release/images/jdk/lib/server/libjvm.dylib
>> 
>> # Before
>> libjvm.dylib`::SpinPause():
>> libjvm.dylib[0x89f0d4] <+0>:  stp    x29, x30, [sp, #-0x10]!
>> libjvm.dylib[0x89f0d8] <+4>:  mov    x29, sp
>> libjvm.dylib[0x89f0dc] <+8>:  adrp   x8, 1409
>> libjvm.dylib[0x89f0e0] <+12>: add    x8, x8, #0x80 ; VM_Version::_spin_wait
>> libjvm.dylib[0x89f0e4] <+16>: ldrsw  x8, [x8]
>> libjvm.dylib[0x89f0e8] <+20>: lsl    x8, x8, #3
>> libjvm.dylib[0x89f0ec] <+24>: adr    x9, 0x89f100 ; <+44> at os_bsd_aarch64.cpp:545:5
>> libjvm.dylib[0x89f0f0] <+28>: add    x9, x9, x8
>> libjvm.dylib[0x89f0f4] <+32>: br     x9
>> libjvm.dylib[0x89f0f8] <+36>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
>> libjvm.dylib[0x89f0fc] <+40>: nop    
>> libjvm.dylib[0x89f100] <+44>: nop    
>> libjvm.dylib[0x89f104] <+48>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
>> libjvm.dylib[0x89f108] <+52>: isb    
>> libjvm.dylib[0x89f10c] <+56>: b      0x89f114       ; <+64> at os_bsd_aarch64.cpp:561:5
>> libjvm.dylib[0x89f110] <+60>: yield  
>> libjvm.dylib[0x89f114] <+64>: mov    w0, #0x1 ; =1 
>> libjvm.dylib[0x89f118] <+68>: ldp    x29, x30, [sp], #0x10
>> libjvm.dylib[0x89f11c] <+72>: ret  
>> 
>> # After
>> libjvm.dylib`::SpinPause():
>> libjvm.dylib[0x89f074] <+0>:   stp    x29, x30, [sp, #-0x10]!
>> libjvm.dylib[0x89f078] <+4>:   mov    x29, sp
>> libjvm.dylib[0x89f07c] <+8>:   adrp   x8, 1409
>> libjvm.dylib[0x89f080] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
>> libjvm.dylib[0x89f084] <+16>:  ldr    w8, [x8]
>> libjvm.dylib[0x89f088] <+20>:  add    w8, w8, #0x1
>> libjvm.dylib[0x89f08c] <+24>:  cmp    w8, #0x4
>> libjvm.dylib[0x89f090] <+28>:  b.hi   0x89f0ec       ; <+120> at os_bsd_aarch64.cpp:551:7
>> libjvm.dylib[0x89f094] <+32>:  adrp   x9, 0
>> libjvm.dylib[0x89f098] <+36>:  add    x9, x9, #0xfc ; ___lldb_unnamed_symbol66913
>> libjvm.dylib[0x89f09c] <+40>:  adr    x10, 0x89f09c ; <+40> at os_bsd_aarch64.cpp
>> libjvm.dylib[0x89f0a0] <+44>:  ldrsw  x11, [x9, x8, lsl #2]
>> libjvm.dylib[0x89f0a4] <+48>:  add    x10, x10, x11
>> libjvm.dylib[0x89f0a8] <+52>:  br     x10
>> libjvm.dylib[0x89f0ac] <+56>:  nop    
>> libjvm.dylib[0x89f0b0] <+60>:  mov    w0, #0x1 ; =1 
>> libjvm.dylib[0x89f0b4] <+64>:  ldp    x29, x30, [sp], #0x10
>> lib...
>
> Exactly. When writing inline asm, it doesn't much help to try to out-guess the compiler.

> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655)
> 
> Frederick (@fbredber) wanted to avoid branches: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740)

You're getting branches, one way or the other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219661891

From shade at openjdk.org  Mon Jul 21 16:29:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 16:29:24 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v2]
In-Reply-To: <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
Message-ID: <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>

On Mon, 21 Jul 2025 16:17:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Exactly. When writing inline asm, it doesn't much help to try to out-guess the compiler.
>
>> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655)
>> 
>> Frederick (@fbredber) wanted to avoid branches: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740)
> 
> You're getting branches, one way or the other.

I actually like the compiler version, especially if we lay out enums in some sane order. In current inline assembly, adding a new case makes some branches _longer_; probably irrelevant on this small scale, but still. With compiler-compiled switch, we effectively get new additions like `SB` for "free", as every other label stays in place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2219677824

From sparasa at openjdk.org  Mon Jul 21 17:25:26 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 21 Jul 2025 17:25:26 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
 <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
 <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>
Message-ID: <NI-ip8yMMmDw_U9Y0ClJpfsJLETxpMIg9Z3VBBq2pZU=.390c8688-89d4-4360-95c1-d1e13bdad24a@github.com>

On Mon, 21 Jul 2025 15:44:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?
>> 
>> Thanks,
>> Vamsi
>
> Hi @vamsi-parasa , I think it's ok not to expose pop_ppx / push_ppx as separate interfaces, and let processor forward the values b/w push and matching pop if balancing constraints are satisfied.
> 
> <img width="1055" height="151" alt="image" src="https://github.com/user-attachments/assets/6923ca1b-11eb-4fae-8d51-14f1bfe27cea" />

Hi Jatin (@jatin-bhateja), the reason to make the push_ppx/pop_ppx usage explicit is because an unbalanced push_ppx operation has a performance penalty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2219810277

From sparasa at openjdk.org  Mon Jul 21 17:34:37 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 21 Jul 2025 17:34:37 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <NI-ip8yMMmDw_U9Y0ClJpfsJLETxpMIg9Z3VBBq2pZU=.390c8688-89d4-4360-95c1-d1e13bdad24a@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
 <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
 <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>
 <NI-ip8yMMmDw_U9Y0ClJpfsJLETxpMIg9Z3VBBq2pZU=.390c8688-89d4-4360-95c1-d1e13bdad24a@github.com>
Message-ID: <dkTgh9qrC3FUq5qAeJr1vey5bgGVFaNxOs8kxixHRfA=.45273a12-cc98-45f1-9a9d-146d545efb1c@github.com>

On Mon, 21 Jul 2025 17:23:15 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> Hi @vamsi-parasa , I think it's ok not to expose pop_ppx / push_ppx as separate interfaces, and let processor forward the values b/w push and matching pop if balancing constraints are satisfied.
>> 
>> <img width="1055" height="151" alt="image" src="https://github.com/user-attachments/assets/6923ca1b-11eb-4fae-8d51-14f1bfe27cea" />
>
> Hi Jatin (@jatin-bhateja), the reason to make the push_ppx/pop_ppx usage explicit is because an unbalanced push_ppx operation has a performance penalty.

> Please create a new RFE for its tracking.

Hi Jatin(@jatin-bhateja) , please see the JBS issue (https://bugs.openjdk.org/browse/JDK-8362903) for push2/pop2 enabling in future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2219828160

From amenkov at openjdk.org  Mon Jul 21 18:44:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 21 Jul 2025 18:44:28 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread
In-Reply-To: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
Message-ID: <F-aP-P_ezXDgryWhofqnhEE8XEgDbWfL6cDvZLFmufY=.6cf55a40-8677-4b1c-a1df-fde87cc6103c@github.com>

On Mon, 14 Jul 2025 05:34:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
> 
> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
> 
> Testing:
> - tiers 1-4
> 
> Thanks

src/hotspot/share/runtime/threadSMR.hpp line 78:

> 76: // longer protected by a ThreadsListHandle.
> 77: //
> 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread

This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread).
JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2219977613

From eastigeevich at openjdk.org  Mon Jul 21 20:31:27 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 20:31:27 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Put cases in enum order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26387/files
  - new: https://git.openjdk.org/jdk/pull/26387/files/e984fdeb..57d30a35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26387&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26387&range=01-02

  Stats: 13 lines in 1 file changed: 6 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26387/head:pull/26387

PR: https://git.openjdk.org/jdk/pull/26387

From liach at openjdk.org  Mon Jul 21 21:10:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 21:10:34 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
Message-ID: <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>

On Mon, 21 Jul 2025 07:16:30 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.

I have looked into that; there is some difficulty, in particular, there are a lot of special handling for LMF classes, such as setting the protection domain, which distinguishes them from the LF/String concat classes. Since this is not as pure a migration, I am planning to do as a separate task; most likely, the string concat classes would be taken as the general hidden class template (which works for hidden classes like pattern matching, not sure about MethodHandleProxies, which also have publicly accessible instances like LMF)

> There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.

Now we are using the term AOT not only to describe code compilation (like JIT), but for general preprocessing, like jlink. So the term AOT is suitable.

> As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.

Also considered for a future patch. This relates to your safeguard proposal; we might add the safeguard implementation together with the warning annotation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3098961108

From jiangli at openjdk.org  Mon Jul 21 21:18:27 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 21 Jul 2025 21:18:27 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
 <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>
Message-ID: <Im22N9iqozmTaU1ERvuZO4FxsQIFr7YtCXdqpoVYSbI=.84bdcde8-11fc-4098-889e-71b6a926dc60@github.com>

On Mon, 21 Jul 2025 21:08:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> > heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.
> 
> I have looked into that; there is some difficulty, in particular, there are a lot of special handling for LMF classes, such as setting the protection domain, which distinguishes them from the LF/String concat classes. Since this is not as pure a migration, I am planning to do as a separate task; most likely, the string concat classes would be taken as the general hidden class template (which works for hidden classes like pattern matching, not sure about MethodHandleProxies, which also have publicly accessible instances like LMF)

SG.

> 
> > There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.
> 
> Now we are using the term AOT not only to describe code compilation (like JIT), but for general preprocessing, like jlink. So the term AOT is suitable.

Ok, that seems reasonable then.

> 
> > As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.
> 
> Also considered for a future patch. This relates to your safeguard proposal; we might add the safeguard implementation together with the warning annotation.

SG.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3099037148

From dholmes at openjdk.org  Mon Jul 21 21:45:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Jul 2025 21:45:25 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread
In-Reply-To: <F-aP-P_ezXDgryWhofqnhEE8XEgDbWfL6cDvZLFmufY=.6cf55a40-8677-4b1c-a1df-fde87cc6103c@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <F-aP-P_ezXDgryWhofqnhEE8XEgDbWfL6cDvZLFmufY=.6cf55a40-8677-4b1c-a1df-fde87cc6103c@github.com>
Message-ID: <ZlXTZAOtQBfTcZdy7bzfpMVFdjJeGLgq3oj61gcTgf8=.ceeeaef2-769f-4eaf-9aaa-05e967391bb3@github.com>

On Mon, 21 Jul 2025 18:42:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> src/hotspot/share/runtime/threadSMR.hpp line 78:
> 
>> 76: // longer protected by a ThreadsListHandle.
>> 77: //
>> 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread
> 
> This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread).
> JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread

This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2220422664

From eastigeevich at openjdk.org  Mon Jul 21 21:55:26 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 21 Jul 2025 21:55:26 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
Message-ID: <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>

On Mon, 21 Jul 2025 16:25:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I agree with you. I proposed to use the switch when JDK-8321371 was being reviewed: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865147655)
>>> 
>>> Frederick (@fbredber) wanted to avoid branches: [#16994 (comment)](https://github.com/openjdk/jdk/pull/16994#issuecomment-1865955740)
>> 
>> You're getting branches, one way or the other.
>
> I actually like the compiler version, especially if we lay out enums in some sane order. In current inline assembly, adding a new case makes some branches _longer_; probably irrelevant on this small scale, but still. With compiler-compiled switch, we effectively get new additions like `SB` for "free", as every other label stays in place.

I put cases in enum order. On my M3 Pro I get:

libjvm.dylib[0x8a75e8] <+0>:   stp    x29, x30, [sp, #-0x10]!
libjvm.dylib[0x8a75ec] <+4>:   mov    x29, sp
libjvm.dylib[0x8a75f0] <+8>:   adrp   x8, 1417
libjvm.dylib[0x8a75f4] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
libjvm.dylib[0x8a75f8] <+16>:  ldr    w8, [x8]
libjvm.dylib[0x8a75fc] <+20>:  cmp    w8, #0x1
libjvm.dylib[0x8a7600] <+24>:  b.gt   0x8a7620       ; <+56> at os_bsd_aarch64.cpp:534:5
libjvm.dylib[0x8a7604] <+28>:  cbz    w8, 0x8a7640 ; <+88> at os_bsd_aarch64.cpp:538:7
libjvm.dylib[0x8a7608] <+32>:  cmp    w8, #0x1
libjvm.dylib[0x8a760c] <+36>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
libjvm.dylib[0x8a7610] <+40>:  isb
libjvm.dylib[0x8a7614] <+44>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7618] <+48>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a761c] <+52>:  ret
libjvm.dylib[0x8a7620] <+56>:  cmp    w8, #0x2
libjvm.dylib[0x8a7624] <+60>:  b.eq   0x8a7650       ; <+104> at os_bsd_aarch64.cpp:544:7
libjvm.dylib[0x8a7628] <+64>:  cmp    w8, #0x3
libjvm.dylib[0x8a762c] <+68>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
libjvm.dylib[0x8a7630] <+72>:  sb
libjvm.dylib[0x8a7634] <+76>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7638] <+80>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a763c] <+84>:  ret
libjvm.dylib[0x8a7640] <+88>:  nop
libjvm.dylib[0x8a7644] <+92>:  mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7648] <+96>:  ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a764c] <+100>: ret
libjvm.dylib[0x8a7650] <+104>: yield
libjvm.dylib[0x8a7654] <+108>: mov    w0, #0x1 ; =1
libjvm.dylib[0x8a7658] <+112>: ldp    x29, x30, [sp], #0x10
libjvm.dylib[0x8a765c] <+116>: ret


It's interesting. My code is binary search tree version.
It does not depend on the order of the cases. 
I could not get jump table version you've got.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2220438239

From amenkov at openjdk.org  Mon Jul 21 22:10:24 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 21 Jul 2025 22:10:24 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread
In-Reply-To: <ZlXTZAOtQBfTcZdy7bzfpMVFdjJeGLgq3oj61gcTgf8=.ceeeaef2-769f-4eaf-9aaa-05e967391bb3@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <F-aP-P_ezXDgryWhofqnhEE8XEgDbWfL6cDvZLFmufY=.6cf55a40-8677-4b1c-a1df-fde87cc6103c@github.com>
 <ZlXTZAOtQBfTcZdy7bzfpMVFdjJeGLgq3oj61gcTgf8=.ceeeaef2-769f-4eaf-9aaa-05e967391bb3@github.com>
Message-ID: <M8wYIgZk2R4m6ppzE9LYVXU4JnQ2Ht4_nX35xF-8utQ=.d188e37e-b5b1-4903-b778-8c5c33836be1@github.com>

On Mon, 21 Jul 2025 21:43:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.hpp line 78:
>> 
>>> 76: // longer protected by a ThreadsListHandle.
>>> 77: //
>>> 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread
>> 
>> This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread).
>> JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread
>
> This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`.

This is common comment which describes 2 ways to get protected JavaThread, so to me it looks like it describes both (the rest of the comment is applicable to JvmtiExport::cv_external_thread_to_JavaThread).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2220457004

From duke at openjdk.org  Tue Jul 22 00:18:42 2025
From: duke at openjdk.org (Jesse Glick)
Date: Tue, 22 Jul 2025 00:18:42 GMT
Subject: RFR: 8349988: Change cgroup version detection logic to not depend
 on /proc/cgroups [v5]
In-Reply-To: <GoQHhsL19lDlLq4FRGgkY_y7sI17PSkhfVQoq_VRT6Y=.d1da88cb-6bde-4c17-9472-4e6b7133e652@github.com>
References: <BBLqBQtdYk7p51YvIOxll3Z4wLBFNENdMBpjzNB7w_c=.f853b012-994e-4292-b59d-0ea1b04ff7b6@github.com>
 <GoQHhsL19lDlLq4FRGgkY_y7sI17PSkhfVQoq_VRT6Y=.d1da88cb-6bde-4c17-9472-4e6b7133e652@github.com>
Message-ID: <_DHxyZ4JBM2_A83SwQsnflB_DvZxq5D17JeadT5UKEM=.89d102a8-f7b2-4f98-b9d2-1790ad8e7de6@github.com>

On Tue, 1 Apr 2025 21:33:30 GMT, Thomas Fitzsimmons <duke at openjdk.org> wrote:

>> This pull request fixes https://bugs.openjdk.org/browse/JDK-8349988 and https://bugs.openjdk.org/browse/JDK-8347811.
>> 
>> I tested it with:
>> 
>> 
>> java -Xlog:os+container=trace -version
>> 
>> on:
>> 
>> `Red Hat Enterprise Linux 8 (cgroups v1 only)`:
>> _No change in behaviour_
>> 
>> `Fedora 41 (cgroups v2)`:
>> _More verbose output due to `/sys/fs/cgroup/cgroup.controllers` parsing:_
>> 
>> --- tt-old-f41.txt	2025-02-26 15:37:56.310738515 -0500
>> +++ tt-new-f41.txt	2025-02-26 15:37:56.601739407 -0500
>> @@ -1,7 +1,12 @@
>>  [trace][os,container] OSContainer::init: Initializing Container Support
>> -[debug][os,container] Detected optional pids controller entry in /proc/cgroups
>> -[debug][os,container] controller cpuset is not enabled
>> -                    ] 
>> +[debug][os,container] v2 controller cpuset is enabled and relevant
>> +[debug][os,container] v2 controller cpu is enabled and required
>> +[debug][os,container] v2 controller io is enabled but not relevant
>> +[debug][os,container] v2 controller memory is enabled and required
>> +[debug][os,container] v2 controller hugetlb is enabled but not relevant
>> +[debug][os,container] v2 controller pids is enabled and relevant
>> +[debug][os,container] v2 controller rdma is enabled but not relevant
>> +[debug][os,container] v2 controller misc is enabled but not relevant
>>  [debug][os,container] Detected cgroups v2 unified hierarchy
>>  [trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/user.slice/user-4215196.slice/user at 4215196.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-135086d6-2de4-4f2e-ad94-899b5eecaf83.scope
>>  [trace][os,container] Path to /memory.max is /sys/fs/cgroup/user.slice/user-4215196.slice/user at 4215196.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-135086d6-2de4-4f2e-ad94-899b5eecaf83.scope/memory.max
>> 
>> 
>> `Fedora 41 (custom kernel with cgroups v1 disabled)`:
>> _Fixes `cgroups v2` detection:_
>> 
>> --- tt-old-f41-custom-kernel.txt	2025-02-26 15:37:58.197744304 -0500
>> +++ tt-new-f41-custom-kernel.txt	2025-02-26 15:37:59.380747933 -0500
>> @@ -1,7 +1,63 @@
>>  [trace][os,container] OSContainer::init: Initializing Container Support
>> -[debug][os,container] Detected optional pids controller entry in /proc/cgroups
>> -[debug][os,container] controller cpuset is not enabled
>> -                    ] 
>> -[debug][os,container] controller memory is not enabled
>> -                    ] 
>> -[debug][os,container] One or more required controllers disabled at kernel level.
>> +[...
>
> Thomas Fitzsimmons 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 cgroups-v2-version-check-and-controllers-parsing-1
>  - testCgroupv1SystemdOnly, testCgroupv1NoMounts: Use cgroupv1 fields
>  - Merge branch 'master' into cgroups-v2-version-check-and-controllers-parsing-1
>  - Replace literal tabs in procCgroupsCgroupsV1CpusetDisabledContent
>  - Detect cpuset-disabled condition during cgroups v1 /proc/cgroups parsing
>    
>    Remove from cgroups v1 branch incorrect log messages about cpuset
>    controller being optional.  Add test case for cgroups v1, cpuset
>    disabled.
>  - Improve !cgroups_v2_enabled branch comment
>  - Debug-log optional and disabled cgroups v2 controllers
>    
>    Do not log enabled controllers that are not relevant to the JDK.
>  - Move index declaration to scope in which it is used
>  - Remove empty string check during cgroup.controllers parsing
>  - Define ISSPACE_CHARS macro, use it in strsep call
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8c14eafa...b29d8694

In case anyone comes across this, I filed it as https://bugs.launchpad.net/ubuntu/+source/linux-meta-hwe-6.14/+bug/2117446

Effectiveness of patch confirmed on Ubuntu 24.04.2 HWE using Docker CE 28.3.2 by


git checkout 9c5ed23eac7470f56d498e9c4d3c51c2f80fd571^
bash configure --with-boot-jdk=$HOME/.sdkman/candidates/java/24-tem
make images
docker run -m 1GB --rm -v $(pwd)/build/linux-x86_64-server-release/images/jdk:/jdk ubuntu /jdk/bin/java '-Xlog:os*=trace' -XshowSettings:vm -XX:MaxRAMPercentage=50 -version
git checkout 9c5ed23eac7470f56d498e9c4d3c51c2f80fd571
make images
docker run -m 1GB --rm -v $(pwd)/build/linux-x86_64-server-release/images/jdk:/jdk ubuntu /jdk/bin/java '-Xlog:os*=trace' -XshowSettings:vm -XX:MaxRAMPercentage=50 -version


Before: shows


One or more required controllers disabled at kernel level.


and max heap size is ? of physical RAM. After,


Memory Limit is: 1073741824


and max heap size is 512Mb as expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23811#issuecomment-3100042998

From dholmes at openjdk.org  Tue Jul 22 05:39:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 05:39:38 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread
In-Reply-To: <M8wYIgZk2R4m6ppzE9LYVXU4JnQ2Ht4_nX35xF-8utQ=.d188e37e-b5b1-4903-b778-8c5c33836be1@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <F-aP-P_ezXDgryWhofqnhEE8XEgDbWfL6cDvZLFmufY=.6cf55a40-8677-4b1c-a1df-fde87cc6103c@github.com>
 <ZlXTZAOtQBfTcZdy7bzfpMVFdjJeGLgq3oj61gcTgf8=.ceeeaef2-769f-4eaf-9aaa-05e967391bb3@github.com>
 <M8wYIgZk2R4m6ppzE9LYVXU4JnQ2Ht4_nX35xF-8utQ=.d188e37e-b5b1-4903-b778-8c5c33836be1@github.com>
Message-ID: <qB9MaA6hC1F7mqiCkMeF9FQ93nBMr8U-Fy7001_kcqY=.e1e7276a-5de5-4b9f-97ad-2cd95a0a57f7@github.com>

On Mon, 21 Jul 2025 22:07:38 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`.
>
> This is common comment which describes 2 ways to get protected JavaThread, so to me it looks like it describes both (the rest of the comment is applicable to JvmtiExport::cv_external_thread_to_JavaThread).

Sorry confused myself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2221247224

From dholmes at openjdk.org  Tue Jul 22 05:47:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 05:47:37 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
Message-ID: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>

> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
> 
> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
> 
> Testing:
> - tiers 1-4
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Move comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26287/files
  - new: https://git.openjdk.org/jdk/pull/26287/files/a195fe22..820f26e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=00-01

  Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287

PR: https://git.openjdk.org/jdk/pull/26287

From lmesnik at openjdk.org  Tue Jul 22 06:49:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 22 Jul 2025 06:49:25 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
Message-ID: <n6NsHr_auSArwQHTnQO4ELgX-_h5SiKz9xdNRpAdjCw=.97c6652d-87e6-409c-b5b6-8568d4a497c9@github.com>

On Wed, 2 Jul 2025 15:56:28 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 incrementally with two additional commits since the last revision:
> 
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables

Thanks for fixing tests, please full review from compiler team.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25954#pullrequestreview-3041388771

From stuefe at openjdk.org  Tue Jul 22 07:40:25 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 22 Jul 2025 07:40:25 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space
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: <bEaXnnouXb3aQDSe_HPj9sM82MrGLlP6ru7OII7kqZ4=.34138e8d-fb54-48ef-9fc8-c14e4f7a2702@github.com>

On Thu, 19 Jun 2025 06:41:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 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 (the latter still ongoing). Test were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing 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.

Ping @shipilev

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3101455120

From aph at openjdk.org  Tue Jul 22 08:09:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Jul 2025 08:09:30 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
Message-ID: <QGvC3cF8haP7mNr0rbjJ-GFC1stL0ENK8-KaCvaduYA=.ee361214-8874-4141-a879-8eb315d3a2f5@github.com>

On Wed, 2 Jul 2025 15:56:28 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 incrementally with two additional commits since the last revision:
> 
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables

src/hotspot/share/asm/codeBuffer.hpp line 547:

> 545: 
> 546:  private:
> 547:   enum class TrampolineCallKind { Runtime, Static };

Perhaps better to use `relocInfo::relocType` instead of `TrampolineCallKind`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2221604364

From aph at openjdk.org  Tue Jul 22 08:36:33 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Jul 2025 08:36:33 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
Message-ID: <ojIHFy2eXYE3K6jSCoLIsWU4hahg6LqMxN-giJa9X9s=.8f304f99-1a94-4831-8f29-eb9c4ecccc0d@github.com>

On Wed, 2 Jul 2025 15:56:28 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 incrementally with two additional commits since the last revision:
> 
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables

src/hotspot/share/utilities/globalDefinitions.hpp line 1337:

> 1335:   return ht ^ (hv << 1 | (hv >> (sizeof(unsigned) * BitsPerByte - 1)));
> 1336: }
> 1337: 

Suggestion:

template<typename K, ENABLE_IF(is_pair<K>::value)> unsigned primitive_hash(const K& k) {
  return primitive_hash(k.first) * 31 + primitive_hash(k.second);
}


Reason: use a nonlinear combiner, the same as many other places in the VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2221711577

From duke at openjdk.org  Tue Jul 22 14:50:35 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 22 Jul 2025 14:50:35 GMT
Subject: RFR: 8363584: Sort share/utilities includes
Message-ID: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>

This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.

Passes tier1 tests.

-------------

Commit messages:
 - revert
 - sort utilities

Changes: https://git.openjdk.org/jdk/pull/26428/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363584
  Stats: 71 lines in 23 files changed: 37 ins; 33 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From shade at openjdk.org  Tue Jul 22 15:00:25 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 15:00:25 GMT
Subject: RFR: 8363584: Sort share/utilities includes
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <u8PAIVyjTszZfrNlVBd-uPeJs1-IHTjQ_dcyw-2ziTs=.60332280-7de2-4490-8d2b-a691ed980277@github.com>

On Tue, 22 Jul 2025 14:45:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests.

Looks reasonable to me. Need to wait for builds to complete, 24 hours cooldown, and have another Reviewer.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26428#pullrequestreview-3043423674

From shade at openjdk.org  Tue Jul 22 16:00:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 16:00:02 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
Message-ID: <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>

On Mon, 21 Jul 2025 21:53:08 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I actually like the compiler version, especially if we lay out enums in some sane order. In current inline assembly, adding a new case makes some branches _longer_; probably irrelevant on this small scale, but still. With compiler-compiled switch, we effectively get new additions like `SB` for "free", as every other label stays in place.
>
> I put cases in enum order. On my M3 Pro I get:
> 
> libjvm.dylib[0x8a75e8] <+0>:   stp    x29, x30, [sp, #-0x10]!
> libjvm.dylib[0x8a75ec] <+4>:   mov    x29, sp
> libjvm.dylib[0x8a75f0] <+8>:   adrp   x8, 1417
> libjvm.dylib[0x8a75f4] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
> libjvm.dylib[0x8a75f8] <+16>:  ldr    w8, [x8]
> libjvm.dylib[0x8a75fc] <+20>:  cmp    w8, #0x1
> libjvm.dylib[0x8a7600] <+24>:  b.gt   0x8a7620       ; <+56> at os_bsd_aarch64.cpp:534:5
> libjvm.dylib[0x8a7604] <+28>:  cbz    w8, 0x8a7640 ; <+88> at os_bsd_aarch64.cpp:538:7
> libjvm.dylib[0x8a7608] <+32>:  cmp    w8, #0x1
> libjvm.dylib[0x8a760c] <+36>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
> libjvm.dylib[0x8a7610] <+40>:  isb
> libjvm.dylib[0x8a7614] <+44>:  mov    w0, #0x1 ; =1
> libjvm.dylib[0x8a7618] <+48>:  ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x8a761c] <+52>:  ret
> libjvm.dylib[0x8a7620] <+56>:  cmp    w8, #0x2
> libjvm.dylib[0x8a7624] <+60>:  b.eq   0x8a7650       ; <+104> at os_bsd_aarch64.cpp:544:7
> libjvm.dylib[0x8a7628] <+64>:  cmp    w8, #0x3
> libjvm.dylib[0x8a762c] <+68>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
> libjvm.dylib[0x8a7630] <+72>:  sb
> libjvm.dylib[0x8a7634] <+76>:  mov    w0, #0x1 ; =1
> libjvm.dylib[0x8a7638] <+80>:  ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x8a763c] <+84>:  ret
> libjvm.dylib[0x8a7640] <+88>:  nop
> libjvm.dylib[0x8a7644] <+92>:  mov    w0, #0x1 ; =1
> libjvm.dylib[0x8a7648] <+96>:  ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x8a764c] <+100>: ret
> libjvm.dylib[0x8a7650] <+104>: yield
> libjvm.dylib[0x8a7654] <+108>: mov    w0, #0x1 ; =1
> libjvm.dylib[0x8a7658] <+112>: ldp    x29, x30, [sp], #0x10
> libjvm.dylib[0x8a765c] <+116>: ret
> 
> 
> It's interesting. My code is binary search tree version.
> It does not depend on the order of the cases. 
> I could not get jump table version you've got.

Still getting a jump table with your current version. Maybe this comes down to the compiler toolchain. Dang, maybe this is one reason to go for hand-written assembly: make it stable across toolchains.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223042090

From shade at openjdk.org  Tue Jul 22 16:09:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 16:09:55 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
Message-ID: <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>

On Tue, 22 Jul 2025 15:57:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I put cases in enum order. On my M3 Pro I get:
>> 
>> libjvm.dylib[0x8a75e8] <+0>:   stp    x29, x30, [sp, #-0x10]!
>> libjvm.dylib[0x8a75ec] <+4>:   mov    x29, sp
>> libjvm.dylib[0x8a75f0] <+8>:   adrp   x8, 1417
>> libjvm.dylib[0x8a75f4] <+12>:  add    x8, x8, #0x80 ; VM_Version::_spin_wait
>> libjvm.dylib[0x8a75f8] <+16>:  ldr    w8, [x8]
>> libjvm.dylib[0x8a75fc] <+20>:  cmp    w8, #0x1
>> libjvm.dylib[0x8a7600] <+24>:  b.gt   0x8a7620       ; <+56> at os_bsd_aarch64.cpp:534:5
>> libjvm.dylib[0x8a7604] <+28>:  cbz    w8, 0x8a7640 ; <+88> at os_bsd_aarch64.cpp:538:7
>> libjvm.dylib[0x8a7608] <+32>:  cmp    w8, #0x1
>> libjvm.dylib[0x8a760c] <+36>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
>> libjvm.dylib[0x8a7610] <+40>:  isb
>> libjvm.dylib[0x8a7614] <+44>:  mov    w0, #0x1 ; =1
>> libjvm.dylib[0x8a7618] <+48>:  ldp    x29, x30, [sp], #0x10
>> libjvm.dylib[0x8a761c] <+52>:  ret
>> libjvm.dylib[0x8a7620] <+56>:  cmp    w8, #0x2
>> libjvm.dylib[0x8a7624] <+60>:  b.eq   0x8a7650       ; <+104> at os_bsd_aarch64.cpp:544:7
>> libjvm.dylib[0x8a7628] <+64>:  cmp    w8, #0x3
>> libjvm.dylib[0x8a762c] <+68>:  b.ne   0x8a7614       ; <+44> at os_bsd_aarch64.cpp:555:5
>> libjvm.dylib[0x8a7630] <+72>:  sb
>> libjvm.dylib[0x8a7634] <+76>:  mov    w0, #0x1 ; =1
>> libjvm.dylib[0x8a7638] <+80>:  ldp    x29, x30, [sp], #0x10
>> libjvm.dylib[0x8a763c] <+84>:  ret
>> libjvm.dylib[0x8a7640] <+88>:  nop
>> libjvm.dylib[0x8a7644] <+92>:  mov    w0, #0x1 ; =1
>> libjvm.dylib[0x8a7648] <+96>:  ldp    x29, x30, [sp], #0x10
>> libjvm.dylib[0x8a764c] <+100>: ret
>> libjvm.dylib[0x8a7650] <+104>: yield
>> libjvm.dylib[0x8a7654] <+108>: mov    w0, #0x1 ; =1
>> libjvm.dylib[0x8a7658] <+112>: ldp    x29, x30, [sp], #0x10
>> libjvm.dylib[0x8a765c] <+116>: ret
>> 
>> 
>> It's interesting. My code is binary search tree version.
>> It does not depend on the order of the cases. 
>> I could not get jump table version you've got.
>
> Still getting a jump table with your current version. Maybe this comes down to the compiler toolchain. Dang, maybe this is one reason to go for hand-written assembly: make it stable across toolchains.

@fbredber @theRealAph, thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223062256

From aph at openjdk.org  Tue Jul 22 16:42:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Jul 2025 16:42:57 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
Message-ID: <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>

On Tue, 22 Jul 2025 16:07:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @fbredber @theRealAph, thoughts?

That's fine. It's supposed to be a delay, and an indirect jump won't hurt. It's a lot less disruptive than an ISB in many cases, and as far as I can tell ISB is the best we've got today.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223172651

From shade at openjdk.org  Tue Jul 22 17:14:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 17:14:58 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
Message-ID: <g33Vy_9lfEopYWI8CzZEPnkHSwBMiIShhUhzxTChWHY=.942c233c-1dd6-4670-90c8-97777370666d@github.com>

On Mon, 21 Jul 2025 20:31:27 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> ### Background
>> 
>> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
>> 
>> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
>> 
>> ### Summary of changes
>> 
>> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
>> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
>> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
>> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
>> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
>> * Added a gtest to verify the functionality of `SpinPause`.
>> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
>> 
>> ### Testing results: fastdebug, release
>> 
>> - Linux, Graviton 2
>>    - tier1: Passed
>>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
>> - MacOS, M3 Pro
> ...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put cases in enum order

All right then, looks good to me.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26387#pullrequestreview-3044035998

From eastigeevich at openjdk.org  Tue Jul 22 17:14:59 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 22 Jul 2025 17:14:59 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
Message-ID: <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>

On Tue, 22 Jul 2025 16:40:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @fbredber @theRealAph, thoughts?
>
>> @fbredber @theRealAph, thoughts?
> 
> That's fine. It's supposed to be a delay, and an indirect jump won't hurt. It's a lot less disruptive than an ISB in many cases, and as far as I can tell ISB is the best we've got today.

For the default `yield`, we have the following execution paths:
1. My hand written assembly: `tbz; yield; b`
2. Compiler jump table: `cmp; b.hi; adrp; add; adr; ldrsw; add; br; yield`
3. Compiler binary search tree: `cmp; b.gt; cmp; b.eq; yield`. `cmp+b` can usually be fused. So this might be like `b.c; b.c; yield`. 

IMO, `2.` should be the slowest. `3.` should be close to `1.`.  

@theRealAph, what's your opinion?

@fbredber, how  did you measure performance for https://github.com/openjdk/jdk/pull/16994 ? Will the compiler produced code meet performance requirements?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223273644

From fbredberg at openjdk.org  Tue Jul 22 17:21:07 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 22 Jul 2025 17:21:07 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
Message-ID: <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>

On Tue, 22 Jul 2025 17:11:58 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>>> @fbredber @theRealAph, thoughts?
>> 
>> That's fine. It's supposed to be a delay, and an indirect jump won't hurt. It's a lot less disruptive than an ISB in many cases, and as far as I can tell ISB is the best we've got today.
>
> For the default `yield`, we have the following execution paths:
> 1. My hand written assembly: `tbz; yield; b`
> 2. Compiler jump table: `cmp; b.hi; adrp; add; adr; ldrsw; add; br; yield`
> 3. Compiler binary search tree: `cmp; b.gt; cmp; b.eq; yield`. `cmp+b` can usually be fused. So this might be like `b.c; b.c; yield`. 
> 
> IMO, `2.` should be the slowest. `3.` should be close to `1.`.  
> 
> @theRealAph, what's your opinion?
> 
> @fbredber, how  did you measure performance for https://github.com/openjdk/jdk/pull/16994 ? Will the compiler produced code meet performance requirements?

Here are my thoughts.

You wrote that I wanted to avoid branches, which is not entirely true. I wrote:

_"I just like to keep away from conditional branches in code that is supposed to be in tight loops."_

And by that I meant that I don't want to end up with multiple `cmp` and `b.eq` (i.e. a binary search tree) that we see in the code @eastig generated above. Even if the switch code looks as good and neat as the one first generated by @shipilev, it might be a search tree after a compiler update. Hence I wrote it in assembler. When I developed it (on linux-aarch64) it didn't have the forward branches, those where all `ret`-instructions. This works fine if the function doesn't create any stack frame (which it doesn't on either linux-aarch64 or linux-aarch64-debug). Unfortunately macosx-aarch64 always seems to create a stack frame, so all the early return instructions (`ret`) had to be changed into forward branches. I know that you shouldn't try to outsmart the compiler, but I still think that the "one pc-relative branch plus one forward branch" is better than the binary search tree. If we can guarantee that the generated code will always be as tight as the one first generated by Shipilev
 , then we're at least in the same ball park as the hand crafted assembler. But how do we guarantee that?

Also, I did quite a lot of performance measurements before I settled on the assembler solution. Have you made any comparison before and after changing from the assembler code to the new c++ code? If so what tests did you run? Since the code is called in tight locking loops, this code really matters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223286197

From coleenp at openjdk.org  Tue Jul 22 17:38:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 17:38:22 GMT
Subject: RFR: 8363816: Refactor array name creation
Message-ID: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>

This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
Tested with tier1 sanity.

-------------

Commit messages:
 - 8363816: Refactor array name creation

Changes: https://git.openjdk.org/jdk/pull/26430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363816
  Stats: 45 lines in 3 files changed: 25 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26430/head:pull/26430

PR: https://git.openjdk.org/jdk/pull/26430

From shade at openjdk.org  Tue Jul 22 17:49:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 17:49:54 GMT
Subject: RFR: 8363816: Refactor array name creation
In-Reply-To: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
Message-ID: <n-1dK5R1Fg0wuR3GaTf6cr1atI6DOYw9askeZfX1eDg=.616a38a0-68a5-48db-99d0-66b41e9a9bef@github.com>

On Tue, 22 Jul 2025 17:31:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
> Tested with tier1 sanity.

This looks like a mechanical move with passing `Thread*` where needed. Is it? Looks fine if so.

src/hotspot/share/oops/arrayKlass.cpp line 111:

> 109: }
> 110: 
> 111: 

Seems irrelevant to this PR.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26430#pullrequestreview-3044170200
PR Review Comment: https://git.openjdk.org/jdk/pull/26430#discussion_r2223359787

From coleenp at openjdk.org  Tue Jul 22 19:04:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 19:04:39 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
Message-ID: <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>

> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
> Tested with tier1 sanity.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix errant line deletion.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26430/files
  - new: https://git.openjdk.org/jdk/pull/26430/files/c3815d3c..dfbb2155

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26430&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26430/head:pull/26430

PR: https://git.openjdk.org/jdk/pull/26430

From coleenp at openjdk.org  Tue Jul 22 19:04:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 19:04:39 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
Message-ID: <KgeUNsHfEy3_0EHSWsF1DOkVklJo-5P0x7LEpmyfIOQ=.2e5572c9-201d-4677-9969-221dcc75a953@github.com>

On Tue, 22 Jul 2025 19:00:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errant line deletion.

Yes, it's a mechanical move, and passes JavaThread.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26430#pullrequestreview-3044463219

From coleenp at openjdk.org  Tue Jul 22 19:04:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 19:04:39 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <n-1dK5R1Fg0wuR3GaTf6cr1atI6DOYw9askeZfX1eDg=.616a38a0-68a5-48db-99d0-66b41e9a9bef@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <n-1dK5R1Fg0wuR3GaTf6cr1atI6DOYw9askeZfX1eDg=.616a38a0-68a5-48db-99d0-66b41e9a9bef@github.com>
Message-ID: <haEXsxDaboPQYV23B7MZA3tvzcduNpEg77XUnSicHAQ=.5898ae28-dbd3-449c-8f4b-0263e520f942@github.com>

On Tue, 22 Jul 2025 17:46:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix errant line deletion.
>
> src/hotspot/share/oops/arrayKlass.cpp line 111:
> 
>> 109: }
>> 110: 
>> 111: 
> 
> Seems irrelevant to this PR.

Yes, this was unintended.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26430#discussion_r2223566645

From kbarrett at openjdk.org  Tue Jul 22 19:42:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Jul 2025 19:42:56 GMT
Subject: RFR: 8363584: Sort share/utilities includes
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>

On Tue, 22 Jul 2025 14:45:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 43:

> 41: # include <io.h>    // for stream.cpp
> 42: # include <float.h> // for _isnan
> 43: # include <stdio.h> // for va_list

These aren't being flagged as out of order by the checker, because of the trailing comments.
And the comment for `<stdio.h>` is odd, since that's already being brought in by `<stdarg.h>`.

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 47:

> 45: # include <inttypes.h>
> 46: # include <limits.h>
> 47: # include <time.h>

And these were blocked from reordering across the "no reorder" commented includes.

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 50:

> 48: // Need this on windows to get the math constants (e.g., M_PI).
> 49: #define _USE_MATH_DEFINES
> 50: # include <math.h>

There's a separate problem, unrelated to include order cleanup, that `_USE_MATH_DEFINES` is being
defined here, as that's too late if `<math.h>` happened to be included already. I'll file a bug to address that.
(Apparently not causing problems currently, but include reorderings could trigger problems.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/26428#pullrequestreview-3044533592
PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2223618579
PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2223640908
PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2223651965

From amenkov at openjdk.org  Tue Jul 22 21:58:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 22 Jul 2025 21:58:57 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

I still think that it would be safer to explicitly specify that caller knows that jthread can be virtual thread (and maybe add assert when a caller works only with platform threads, but passed jthread is virtual), but ok, it's up to you.
Currently all callers except `ThreadSnapshotFactory::get_thread_snapshot` use `cv_internal_thread_to_JavaThread` for platform threads only. Do you want to update `ThreadSnapshotFactory::get_thread_snapshot` to utilize new functionality or prefer to do it by separate CR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3104940720

From kvn at openjdk.org  Tue Jul 22 22:03:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Jul 2025 22:03:10 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
Message-ID: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>

`StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.

We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.

I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.

During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.

I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 

I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.

Tested: tier1-4,tier10-rt,xcomp,stress

-------------

Commit messages:
 - 8363837: Move StubRoutines::_crc_table_adr initialization to preuniverse stubs

Changes: https://git.openjdk.org/jdk/pull/26434/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363837
  Stats: 63 lines in 13 files changed: 37 ins; 13 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26434/head:pull/26434

PR: https://git.openjdk.org/jdk/pull/26434

From kvn at openjdk.org  Tue Jul 22 22:03:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Jul 2025 22:03:10 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <KJLFQ4XwaiUiQ-Jf5EPmTdrg0RXJVEA7KXd3k6LhxNc=.6b31240b-a8c2-4c61-901d-c8d012b8341a@github.com>

On Tue, 22 Jul 2025 21:56:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

@adinn  please look

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3104946401

From eastigeevich at openjdk.org  Tue Jul 22 22:16:58 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 22 Jul 2025 22:16:58 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
Message-ID: <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>

On Tue, 22 Jul 2025 17:18:09 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> For the default `yield`, we have the following execution paths:
>> 1. My hand written assembly: `tbz; yield; b`
>> 2. Compiler jump table: `cmp; b.hi; adrp; add; adr; ldrsw; add; br; yield`
>> 3. Compiler binary search tree: `cmp; b.gt; cmp; b.eq; yield`. `cmp+b` can usually be fused. So this might be like `b.c; b.c; yield`. 
>> 
>> IMO, `2.` should be the slowest. `3.` should be close to `1.`.  
>> 
>> @theRealAph, what's your opinion?
>> 
>> @fbredber, how  did you measure performance for https://github.com/openjdk/jdk/pull/16994 ? Will the compiler produced code meet performance requirements?
>
> Here are my thoughts.
> 
> You wrote that I wanted to avoid branches, which is not entirely true. I wrote:
> 
> _"I just like to keep away from conditional branches in code that is supposed to be in tight loops."_
> 
> And by that I meant that I don't want to end up with multiple `cmp` and `b.eq` (i.e. a binary search tree) that we see in the code @eastig generated above. Even if the switch code looks as good and neat as the one first generated by @shipilev, it might be a search tree after a compiler update. Hence I wrote it in assembler. When I developed it (on linux-aarch64) it didn't have the forward branches, those where all `ret`-instructions. This works fine if the function doesn't create any stack frame (which it doesn't on either linux-aarch64 or linux-aarch64-debug). Unfortunately macosx-aarch64 always seems to create a stack frame, so all the early return instructions (`ret`) had to be changed into forward branches. I know that you shouldn't try to outsmart the compiler, but I still think that the "one pc-relative branch plus one forward branch" is better than the binary search tree. If we can guarantee that the generated code will always be as tight as the one first generated by Shipil
 ev, then we're at least in the same ball park as the hand crafted assembler. But how do we guarantee that?
> 
> Also, I did quite a lot of performance measurements before I settled on the assembler solution. Have you made any comparison before and after changing from the assembler code to the new c++ code? If so what tests did you run? Since the code is called in tight locking loops, this code really matters.

I have not run benchmarks. Do we have any of them in OpenJDK?

For the current default YIELD, compiled switch: https://godbolt.org/z/fo71nfPb6

SpinPause(SpinWait::Inst):
        cmp     w0, #3
        b.eq    .LBB0_3
        cmp     w0, #2
        b.ne    .LBB0_4
        yield
        ret
.LBB0_3:
        nop
.LBB0_4:
        ret



Iterations:        100
Instructions:      800
Total Cycles:      203

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223924434

From eastigeevich at openjdk.org  Tue Jul 22 22:16:58 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 22 Jul 2025 22:16:58 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
Message-ID: <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>

On Tue, 22 Jul 2025 22:12:04 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Here are my thoughts.
>> 
>> You wrote that I wanted to avoid branches, which is not entirely true. I wrote:
>> 
>> _"I just like to keep away from conditional branches in code that is supposed to be in tight loops."_
>> 
>> And by that I meant that I don't want to end up with multiple `cmp` and `b.eq` (i.e. a binary search tree) that we see in the code @eastig generated above. Even if the switch code looks as good and neat as the one first generated by @shipilev, it might be a search tree after a compiler update. Hence I wrote it in assembler. When I developed it (on linux-aarch64) it didn't have the forward branches, those where all `ret`-instructions. This works fine if the function doesn't create any stack frame (which it doesn't on either linux-aarch64 or linux-aarch64-debug). Unfortunately macosx-aarch64 always seems to create a stack frame, so all the early return instructions (`ret`) had to be changed into forward branches. I know that you shouldn't try to outsmart the compiler, but I still think that the "one pc-relative branch plus one forward branch" is better than the binary search tree. If we can guarantee that the generated code will always be as tight as the one first generated by Shipi
 lev, then we're at least in the same ball park as the hand crafted assembler. But how do we guarantee that?
>> 
>> Also, I did quite a lot of performance measurements before I settled on the assembler solution. Have you made any comparison before and after changing from the assembler code to the new c++ code? If so what tests did you run? Since the code is called in tight locking loops, this code really matters.
>
> I have not run benchmarks. Do we have any of them in OpenJDK?
> 
> For the current default YIELD, compiled switch: https://godbolt.org/z/fo71nfPb6
> 
> SpinPause(SpinWait::Inst):
>         cmp     w0, #3
>         b.eq    .LBB0_3
>         cmp     w0, #2
>         b.ne    .LBB0_4
>         yield
>         ret
> .LBB0_3:
>         nop
> .LBB0_4:
>         ret
> 
> 
> 
> Iterations:        100
> Instructions:      800
> Total Cycles:      203

For my hand written assembly with the current default YIELD: https://godbolt.org/z/3YjxzW4sW

SpinPause(SpinWait::Inst):
        mov     w8, w0
        tbz     w8, #0, .Ltmp0
        yield
        b       .Ltmp1
.Ltmp0:
.Ltmp1:

        ret



Iterations:        100
Instructions:      500
Total Cycles:      152

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223928498

From duke at openjdk.org  Tue Jul 22 22:20:56 2025
From: duke at openjdk.org (duke)
Date: Tue, 22 Jul 2025 22:20:56 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v5]
In-Reply-To: <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <lrxowDZY5H9EUO8mR5EBMnCKNF_I-TMwPF6keWj1tc4=.1d648407-6983-4cc7-bf19-0cb7bc961b39@github.com>
Message-ID: <ld-2QhVd69mFhpiL3anGhPH9cPgzlBH8weemGevX87s=.42644f3a-24b3-4c6e-9ce7-c1caa5a1a35b@github.com>

On Thu, 17 Jul 2025 17:17:07 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR adds support for the Push-Pop Acceleration (PPX) hint to legacy PUSH and POP instructions, enabling the PUSHP and POPP forms. The PPX hint improves performance by accelerating register value forwarding between matching push/pop pairs.
>> 
>> **Purpose:** PPX is a performance hint that allows the processor to bypass memory and the training loop of Fast Store Forwarding Predictor (FSFP) by directly forwarding data between paired PUSHP and POPP instructions.
>> 
>> **Requirements:** Both the PUSH and its matching POP must be marked with PPX. A "matching" pair accesses the same stack address (e.g., typical function prolog/epilog). Standalone PUSH instructions (e.g. for argument passing) must not be marked.
>> 
>> **Encoding:** PUSHP/POPP is a replacement for legacy PUSH/POP (0x50+rd / 0x58+rd) and uses REX2.W = 1 (implies 64-bit operand size). PPX cannot be encoded with 16-bit operand size as REX2.W overrides the 0x66 prefix.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to push_ppx/pop_ppx

@vamsi-parasa 
Your change (at version 78cbf2430d2a8179d97201f799026747a38367a4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25889#issuecomment-3104989703

From ccheung at openjdk.org  Tue Jul 22 22:26:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 22 Jul 2025 22:26:55 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
Message-ID: <sE56gMrdnjzyFgtE2VXFMmnrhACoODLZ0YWFA9sWTtg=.e8b51eb5-6826-4074-9fca-84b9ed1a5e05@github.com>

On Tue, 22 Jul 2025 19:04:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errant line deletion.

Looks good. Thanks.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26430#pullrequestreview-3045039778

From eastigeevich at openjdk.org  Tue Jul 22 22:32:55 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 22 Jul 2025 22:32:55 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
Message-ID: <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>

On Tue, 22 Jul 2025 22:14:23 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I have not run benchmarks. Do we have any of them in OpenJDK?
>> 
>> For the current default YIELD, compiled switch: https://godbolt.org/z/fo71nfPb6
>> 
>> SpinPause(SpinWait::Inst):
>>         cmp     w0, #3
>>         b.eq    .LBB0_3
>>         cmp     w0, #2
>>         b.ne    .LBB0_4
>>         yield
>>         ret
>> .LBB0_3:
>>         nop
>> .LBB0_4:
>>         ret
>> 
>> 
>> 
>> Iterations:        100
>> Instructions:      800
>> Total Cycles:      203
>
> For my hand written assembly with the current default YIELD: https://godbolt.org/z/3YjxzW4sW
> 
> SpinPause(SpinWait::Inst):
>         mov     w8, w0
>         tbz     w8, #0, .Ltmp0
>         yield
>         b       .Ltmp1
> .Ltmp0:
> .Ltmp1:
> 
>         ret
> 
> 
> 
> Iterations:        100
> Instructions:      500
> Total Cycles:      152

The original assembly with the current default YIELD: https://godbolt.org/z/McWGM4f44

SpinPause(SpinWait::Inst):
        lsl     w8, w0, #3
        sxtw    x8, w8
        adr     x9, #20
        add     x9, x9, x8
        br      x9
        b       .Ltmp1
        nop
        nop
        b       .Ltmp1
        nop
        b       .Ltmp1
        yield
.Ltmp1:

        ret



Iterations:        100
Instructions:      1300
Total Cycles:      254

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223946443

From kvn at openjdk.org  Tue Jul 22 22:34:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Jul 2025 22:34:58 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <uP6Nc8Vf5nEQjvumKSfCwP31hPwyviHGw5MUaIOwoK0=.68685775-330c-401a-bb72-3c453b076e90@github.com>

On Tue, 22 Jul 2025 21:56:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> and I can move updateBytesCRC32 stub declaration.

and I can **NOT** move updateBytesCRC32 stub declaration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3105014228

From xpeng at openjdk.org  Tue Jul 22 22:37:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 22 Jul 2025 22:37:37 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v9]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <fcGZ6B4joQElEweYiCycmzHaUeroWe6HyYqwvlSZR90=.43221900-b8ef-44b8-8550-e20b021aa80e@github.com>

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> For the test, I have manually tested different GCs with Flight Recording enabled and verified the events:
> G1:
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0108 ms
>   gcId = 0
>   gcWorkerId = 8
>   name = "Termination"
>   eventThread = "GC Thread#4" (osThreadId = 20483)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0467 ms
>   gcId = 0
>   gcWorkerId = 2
>   name = "Termination"
>   eventThread = "GC Thread#2" (osThreadId = 21251)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0474 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination"
>   eventThread = "GC Thread#8" (osThreadId = 36359)
> }
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000834 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000166 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> 
> Shenandoah: 
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0202 ms
>   gcId = 0
>   gcWorkerId = 0
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0205 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0127 ms
>   gcId = 0
>   gcWorkerId = 5
>   name = "Termination: Final Mark"
>   eventThread = "Shenandoah G...

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Merge branch 'openjdk:master' into JDK-8354555
 - Fix jft test failure
 - Merge branch 'master' into JDK-8354555
 - Patch to fix the PR concerns
 - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
 - Add include "workerThread.hpp"
 - ... and 23 more: https://git.openjdk.org/jdk/compare/016694bf...4d60e2e6

-------------

Changes: https://git.openjdk.org/jdk/pull/24676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=08
  Stats: 90 lines in 10 files changed: 68 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

PR: https://git.openjdk.org/jdk/pull/24676

From sparasa at openjdk.org  Tue Jul 22 22:41:00 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 22 Jul 2025 22:41:00 GMT
Subject: Integrated: 8359965: Enable paired pushp and popp instruction usage
 for APX enabled CPUs
In-Reply-To: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
Message-ID: <DFIK1LXQBGX4bgHzTstnSNGlQCA87NrWGlR3YvieRsg=.419d1430-70f1-4151-bf34-898f88f22031@github.com>

On Thu, 19 Jun 2025 05:15:40 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> This PR adds support for the Push-Pop Acceleration (PPX) hint to legacy PUSH and POP instructions, enabling the PUSHP and POPP forms. The PPX hint improves performance by accelerating register value forwarding between matching push/pop pairs.
> 
> **Purpose:** PPX is a performance hint that allows the processor to bypass memory and the training loop of Fast Store Forwarding Predictor (FSFP) by directly forwarding data between paired PUSHP and POPP instructions.
> 
> **Requirements:** Both the PUSH and its matching POP must be marked with PPX. A "matching" pair accesses the same stack address (e.g., typical function prolog/epilog). Standalone PUSH instructions (e.g. for argument passing) must not be marked.
> 
> **Encoding:** PUSHP/POPP is a replacement for legacy PUSH/POP (0x50+rd / 0x58+rd) and uses REX2.W = 1 (implies 64-bit operand size). PPX cannot be encoded with 16-bit operand size as REX2.W overrides the 0x66 prefix.

This pull request has now been integrated.

Changeset: 4994bd59
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4994bd594299e91e804438692e068b1c5dd5cc02
Stats:     341 lines in 22 files changed: 19 ins; 0 del; 322 mod

8359965: Enable paired pushp and popp instruction usage for APX enabled CPUs

Reviewed-by: sviswanathan, vpaprotski

-------------

PR: https://git.openjdk.org/jdk/pull/25889

From eastigeevich at openjdk.org  Tue Jul 22 22:43:55 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 22 Jul 2025 22:43:55 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
 <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>
 <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
Message-ID: <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>

On Tue, 22 Jul 2025 22:35:12 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> The original assembly with the current default YIELD: https://godbolt.org/z/McWGM4f44
>> 
>> SpinPause(SpinWait::Inst):
>>         lsl     w8, w0, #3
>>         sxtw    x8, w8
>>         adr     x9, #20
>>         add     x9, x9, x8
>>         br      x9
>>         b       .Ltmp1
>>         nop
>>         nop
>>         b       .Ltmp1
>>         nop
>>         b       .Ltmp1
>>         yield
>> .Ltmp1:
>> 
>>         ret
>> 
>> 
>> 
>> Iterations:        100
>> Instructions:      1300
>> Total Cycles:      254
>
> For the default YIELD we have:
> - Original: ~250 clocks
> - Compiler binary search tree: ~200 clocks (-20%)
> - Optimized with `TBZ`: ~150 clocks (-40%)

I think the differences might be smaller on the real hardware. Maybe everything will be around 200 clocks.
If we need code easy to maintain then this is `switch`. If we need performance then this is `tbz`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2223958425

From dholmes at openjdk.org  Wed Jul 23 00:03:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 00:03:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com>
Message-ID: <Ah8iU9yHn2MH8ObKXhEamPJUj_urUmhQLBdPYUyHzyE=.4960f960-a34b-4724-af74-1b3f75378c42@github.com>

On Tue, 22 Jul 2025 21:55:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I still think that it would be safer to explicitly specify that caller knows that jthread can be virtual thread 

I think that retains the risk of the caller not knowing they need to ensure they protect the carrier thread.

> Do you want to update ThreadSnapshotFactory::get_thread_snapshot to utilize new functionality

No, we had some internal discussions and that code is incorrectly using the JVMTI transition disabler, so it needs a complete overhaul. That will be handled separately.

Thanks again for looking at this in depth Alex.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3105187899

From amenkov at openjdk.org  Wed Jul 23 00:31:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 23 Jul 2025 00:31:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <ysS4V2vmgmjI9XliZaSSqUiwOHGqgf5lokSgOabeLB0=.bb230237-2643-4a63-865b-cf4880a70162@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3045222350

From kvn at openjdk.org  Wed Jul 23 01:10:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 01:10:55 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>

On Tue, 22 Jul 2025 21:56:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

@TheRealMDoerr @offamitkumar @RealFYang please test these changes on your platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3105290106

From kvn at openjdk.org  Wed Jul 23 02:00:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 02:00:43 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fixed Zero VM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26434/files
  - new: https://git.openjdk.org/jdk/pull/26434/files/08f27284..6459712d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26434/head:pull/26434

PR: https://git.openjdk.org/jdk/pull/26434

From dholmes at openjdk.org  Wed Jul 23 04:45:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 04:45:04 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
Message-ID: <RX51fVpa8NhWbcl3kSWBcPIrpt5_APUvAprCDE7S4dg=.e33b3e23-5dd3-48b5-a21c-19c7227cef99@github.com>

On Tue, 22 Jul 2025 19:04:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errant line deletion.

A couple of pre-existing style nits, but as you are here ...

LGTM.

Thanks

src/hotspot/share/oops/objArrayKlass.cpp line 58:

> 56: Symbol* ObjArrayKlass::create_element_klass_array_name(JavaThread* current, Klass* element_klass) {
> 57:   ResourceMark rm(current);
> 58:   char *name_str = element_klass->name()->as_C_string();

Suggestion:

  char* name_str = element_klass->name()->as_C_string();

src/hotspot/share/oops/objArrayKlass.cpp line 60:

> 58:   char *name_str = element_klass->name()->as_C_string();
> 59:   int len = element_klass->name()->utf8_length();
> 60:   char *new_str = NEW_RESOURCE_ARRAY_IN_THREAD(current, char, len + 4);

Suggestion:

  char* new_str = NEW_RESOURCE_ARRAY_IN_THREAD(current, char, len + 4);

src/hotspot/share/oops/objArrayKlass.cpp line 71:

> 69:     new_str[idx++] = JVM_SIGNATURE_ENDCLASS;
> 70:   }
> 71:   new_str[idx++] = '\0';

Suggestion:

  new_str[idx] = '\0';

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26430#pullrequestreview-3045572262
PR Review Comment: https://git.openjdk.org/jdk/pull/26430#discussion_r2224327081
PR Review Comment: https://git.openjdk.org/jdk/pull/26430#discussion_r2224327393
PR Review Comment: https://git.openjdk.org/jdk/pull/26430#discussion_r2224329199

From rkennke at openjdk.org  Wed Jul 23 06:34:56 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 23 Jul 2025 06:34:56 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
Message-ID: <P2zaVUYeZWGib_soDaKOcnkRiSo1IFrk81me8ACPTR0=.edd8f0a1-ad53-4fc7-8978-f693a181146b@github.com>

On Wed, 16 Jul 2025 14:01:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulnes:
>> 
>> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
>> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if its 0, we'd assert, if garbage, the resulting Klass* would be garbage.
>> - In print_failure, we now check pointers for readability before handing them to print_obj
>> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
>> - In print_obj, we print a small hex dump of the header (32bytes). With little cost we get a glance at the raw header and the first members.
>> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
>> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
>> 
>> Tests: I manually tested the patch with a number of manually broken oops of various flavours. 
>> 
>> Example output, invalid forwardee:
>> 
>> 
>> Referenced from:
>>   no interior location recorded (probably a plain heap scan, or detached oop)
>> 
>> Object:
>>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
>> 
>>         allocated after mark start
>>         after update watermark
>>         marked strong
>>         marked weak
>>     not in collection set
>>     mark:  marked(0xdeaddeaddeaddeaf)
>>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
>> 
>>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
>> 
>> Forwardee:
>>   0xdeaddeaddeaddeac - safe print, no details
>
> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>  - small revert
>  - cosmetics
>  - wip
>  - wip
>  - wip
>  - wip
>  - assert_correct

Marked as reviewed by rkennke (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26237#pullrequestreview-3045862118

From stuefe at openjdk.org  Wed Jul 23 06:34:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 23 Jul 2025 06:34:56 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <AUuYFmIZ4RoHOcvPSJQGs-IOQLf-DFsIqwOsREY2xQg=.5a241abd-93ef-439d-862f-ab29f8734a03@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <AUuYFmIZ4RoHOcvPSJQGs-IOQLf-DFsIqwOsREY2xQg=.5a241abd-93ef-439d-862f-ab29f8734a03@github.com>
Message-ID: <iedrB3R2kGsCbvP2Zs2LutVfJdvgLncMFVVEwJAFPyI=.d42294d2-4305-4d25-8265-5590959416b6@github.com>

On Thu, 17 Jul 2025 16:46:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>>  - small revert
>>  - cosmetics
>>  - wip
>>  - wip
>>  - wip
>>  - wip
>>  - assert_correct
>
> This looks really useful! I have only two comments/questions.

@rkennke Did I address all your concerns? Anyone else willing to look at this, @earthling-amzn maybe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26237#issuecomment-3105656726

From rkennke at openjdk.org  Wed Jul 23 06:34:57 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 23 Jul 2025 06:34:57 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <P2zaVUYeZWGib_soDaKOcnkRiSo1IFrk81me8ACPTR0=.edd8f0a1-ad53-4fc7-8978-f693a181146b@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <P2zaVUYeZWGib_soDaKOcnkRiSo1IFrk81me8ACPTR0=.edd8f0a1-ad53-4fc7-8978-f693a181146b@github.com>
Message-ID: <ilOIXDw72FDYB8i79GOhTYC7a8ZOcT7hEhTyUNxgO4I=.c02514ba-6323-4c88-b29e-23f67845af7f@github.com>

On Wed, 23 Jul 2025 06:31:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>>  - small revert
>>  - cosmetics
>>  - wip
>>  - wip
>>  - wip
>>  - wip
>>  - assert_correct
>
> Marked as reviewed by rkennke (Reviewer).

> @rkennke Did I address all your concerns? Anyone else willing to look at this, @earthling-amzn maybe?

Yes, looks all good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26237#issuecomment-3106003932

From aph at openjdk.org  Wed Jul 23 08:13:10 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 23 Jul 2025 08:13:10 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
Message-ID: <n2WkgAfBQKlZ0mizlj1VtYFcojCVkECkIda-tCV2csc=.3d8b442e-d68b-4fe0-884f-d865b2e7479d@github.com>

On Mon, 21 Jul 2025 20:31:27 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> ### Background
>> 
>> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
>> 
>> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
>> 
>> ### Summary of changes
>> 
>> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
>> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
>> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
>> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
>> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
>> * Added a gtest to verify the functionality of `SpinPause`.
>> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
>> 
>> ### Testing results: fastdebug, release
>> 
>> - Linux, Graviton 2
>>    - tier1: Passed
>>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
>> - MacOS, M3 Pro
> ...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put cases in enum order

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26387#pullrequestreview-3046198008

From duke at openjdk.org  Wed Jul 23 08:27:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 23 Jul 2025 08:27:54 GMT
Subject: RFR: 8363584: Sort share/utilities includes
In-Reply-To: <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
Message-ID: <CObC9qvXuWkJfMchxEXC4woEfxSNSEox2jZKL4p4FQw=.1b77c0bf-14b7-419d-9a51-b97aaf910e89@github.com>

On Tue, 22 Jul 2025 19:16:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 43:
> 
>> 41: # include <io.h>    // for stream.cpp
>> 42: # include <float.h> // for _isnan
>> 43: # include <stdio.h> // for va_list
> 
> These aren't being flagged as out of order by the checker, because of the trailing comments.
> And the comment for `<stdio.h>` is odd, since that's already being brought in by `<stdarg.h>`.

@kimbarrett How should we tackle this problem? I tried the following:

 # include <stdlib.h>
 # include <string.h>
-# include <stddef.h>// for offsetof
+// for offsetof
+# include <stddef.h>
 # include <sys/stat.h>
-# include <io.h>    // for stream.cpp
-# include <float.h> // for _isnan
-# include <stdio.h> // for va_list
+// for stream.cpp
+# include <io.h>
+// for _isnan
+# include <float.h>
+// for va_list
+# include <stdio.h>
 # include <fcntl.h>
 # include <inttypes.h>
 # include <limits.h>


Then running `SortInclude` gives the following result:

 # include <float.h>
 // for va_list
-# include <stdio.h>
 # include <fcntl.h>
 # include <inttypes.h>
 # include <limits.h>
+# include <stdio.h>
 # include <time.h>


from which I infer that `SortInclude` disregards comments above the `include` statement, which of course is not what we want. 

Either we remove the comments, or `SortIncludes.java` should be improved somehow. For example, I see the following comment in `TestIncludesAreSorted`:

Note that non-space characters after the closing " or > of an include statement
can be used to prevent re-ordering of the include.

Would it be acceptable to change this behavior to prevent only lines containing a particular combination from being reordered? (e.g. `// do not reorder`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2224795365

From aph at openjdk.org  Wed Jul 23 08:45:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 23 Jul 2025 08:45:57 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
 <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>
 <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
 <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
Message-ID: <LdkvCLN4qPDTZjmhgE2wlq0UIAMFm-hipNlfftNNvOE=.7ba684e9-75b7-4510-8c52-09a6371d6a48@github.com>

On Tue, 22 Jul 2025 22:41:32 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> For the default YIELD we have:
>> - Original: ~250 clocks
>> - Compiler binary search tree: ~200 clocks (-20%)
>> - Optimized with `TBZ`: ~150 clocks (-40%)
>
> I think the differences might be smaller on the real hardware. Maybe everything will be around 200 clocks.
> If we need code easy to maintain then this is `switch`. If we need performance then this is `tbz`.

> Also, I did quite a lot of performance measurements before I settled on the assembler solution. Have you made any comparison before and after changing from the assembler code to the new c++ code? If so what tests did you run? Since the code is called in tight locking loops, this code really matters.

Given that this routine is a backoff delay, it's not clear that speeding it up helps.

However, if we really wanted to speed this up we'd use an indirect branch to one of four code blocks: `isb; ret` would be one of them. But I don't think we do want to speed it up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2224842183

From fbredberg at openjdk.org  Wed Jul 23 10:10:55 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 23 Jul 2025 10:10:55 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
 <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>
 <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
 <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
Message-ID: <3XSJWk8McJoHpxWTp6rMVhSBsqKhsjjaIkbbmTWvJb0=.619d0bfc-ee7f-437f-b7f5-cdd07b8ff9ee@github.com>

On Tue, 22 Jul 2025 22:41:32 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> For the default YIELD we have:
>> - Original: ~250 clocks
>> - Compiler binary search tree: ~200 clocks (-20%)
>> - Optimized with `TBZ`: ~150 clocks (-40%)
>
> I think the differences might be smaller on the real hardware. Maybe everything will be around 200 clocks.
> If we need code easy to maintain then this is `switch`. If we need performance then this is `tbz`.

@eastig 
When I tested [JDK-8320317](https://bugs.openjdk.org/browse/JDK-8320317) the DaCapo-h2-large test showed very stable values when run multiple times. The performance went up on Linux x86 and Windows x86 by approximately 12%, but went down with roughly the same amount on macOS AArch64. That performance decreased could however be avoided by implement `SpinPause()` on macOS. So I fixed that in [JDK-8321371](https://bugs.openjdk.org/browse/JDK-8321371).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2225054012

From coleenp at openjdk.org  Wed Jul 23 11:41:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 11:41:13 GMT
Subject: RFR: 8363816: Refactor array name creation [v3]
In-Reply-To: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
Message-ID: <munDmBGKKkGAIrNnqdxmWfkM9TSX8X-r36TSc7J1mx8=.ce175caf-b277-4144-a8a6-ac7e5d6d4eeb@github.com>

> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
> Tested with tier1 sanity.

Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/hotspot/share/oops/objArrayKlass.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/oops/objArrayKlass.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/oops/objArrayKlass.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26430/files
  - new: https://git.openjdk.org/jdk/pull/26430/files/dfbb2155..bf267900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26430&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26430/head:pull/26430

PR: https://git.openjdk.org/jdk/pull/26430

From coleenp at openjdk.org  Wed Jul 23 11:41:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 11:41:14 GMT
Subject: RFR: 8363816: Refactor array name creation [v2]
In-Reply-To: <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <YpbwssUeDBxxOnRt40pZvv3JFoVe_2h4B0YnK7lg5hU=.f07f65f8-d604-44f2-a13e-570d1b4c99ab@github.com>
Message-ID: <Np-C5Z1BTdCm4TCdRdVpXKf7On_dwqXzKmA2pwbiTHQ=.2afb8505-639d-496d-af42-42c859d4d11b@github.com>

On Tue, 22 Jul 2025 19:04:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix errant line deletion.

All fixed, thanks for the suggestions that I can click.  Can you re-review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26430#issuecomment-3107362783

From fbredberg at openjdk.org  Wed Jul 23 11:52:55 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 23 Jul 2025 11:52:55 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
 <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>
 <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
 <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
Message-ID: <nPNfgvYdvC03AkO2SuhKcNQLniRDnOIiJqaUzpj_MdU=.7eefda32-4e12-45ae-a030-4bd8be6517de@github.com>

On Tue, 22 Jul 2025 22:41:32 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> For the default YIELD we have:
>> - Original: ~250 clocks
>> - Compiler binary search tree: ~200 clocks (-20%)
>> - Optimized with `TBZ`: ~150 clocks (-40%)
>
> I think the differences might be smaller on the real hardware. Maybe everything will be around 200 clocks.
> If we need code easy to maintain then this is `switch`. If we need performance then this is `tbz`.

@eastig
I would prefer your `tbz` version for reasons stated earlier, but most notably to make it stable across toolchains.
But maybe it's best to just integrate it as is since there are other problems ([JDK-8361032](https://bugs.openjdk.org/browse/JDK-8361032) and [JDK-8360936](https://bugs.openjdk.org/browse/JDK-8360936)) that are waiting for this to be fixed.

Time will tell if this implementation will make performance better or worse. The debate of how to best implement `SpinPause()` will surely not end today. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2225312820

From vyazici at openjdk.org  Wed Jul 23 12:54:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Jul 2025 12:54:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with four additional commits since the last revision:

 - Add `@bug` tags
 - Improve wording of `@param len`
 - Make source array bound checks lenient too
 - Cap destination array bounds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/025c7ef7..1d02189f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=10-11

  Stats: 29 lines in 6 files changed: 8 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From vyazici at openjdk.org  Wed Jul 23 12:54:01 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Jul 2025 12:54:01 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
 <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>
Message-ID: <PMiTq_RP0cSqHvcbd6j5qJwS7kbH-PTrRqkTzTjvX2U=.ab0fb2c4-66e8-41f3-a4e9-5ac7e799926c@github.com>

On Mon, 21 Jul 2025 15:39:34 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Minor: could you please add a bug id to the `@bug` annotations in tests?

@myankelev, thanks for the heads up. Implemented in 1d02189fba1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3107998200

From adinn at openjdk.org  Wed Jul 23 13:21:54 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 23 Jul 2025 13:21:54 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
Message-ID: <CjPN4gg5SFqXvEQjRU7n31mQ6npVGA8VTz__2y5ecF4=.12d36bbd-26dd-4f55-9de9-a8995715a5cd@github.com>

On Wed, 23 Jul 2025 01:07:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> @TheRealMDoerr @offamitkumar @RealFYang please test these changes on your platforms.

@vnkozlov I'll note straight off that the situation here is complicated by the fact that `crc_table_adr` and `crc32c_table_addr` are pseudo-'entries'. They do not actually hold (code or data) addresses in generated code. What they really identify is an arch-specific address for foreign (C++) data that is assigned as a side-effect of performing generation for other entries. the only reason for marking them as entries is so we get a generated field and associated getter in class `StubRoutines`.

I'm not sure we need to care too much about their pseudo-entry status. More importantly, I dislike your solution of moving the initialization into `generate_preuniverse_stubs()`. This moves that initialization step away from the generator code that uses the resulting value, making it harder to see how the intrinsic works. It also has the unfortunate side effect of forcing us to create a preuinverse blob for every arch even if when we don't really need one.

You are right that we cannot add these addresses to the external addresses list under `AOTCodeCache::init2()` (via the call to `table->init_extrs()`) because the assignment of the pseudo-entry has not yet happened. However, we have two alternatives.

1) We can simply pretend that they are real entries add them to the stub addresses list under `AOTCodeCache::init_early_stubs_table()` (via the call to `table->init_early_stubs()`). That will successfully advertise them  after they have been created as addresses that need relocation at AOT Cache load. However, it will also misclassify them as addresses in generated code when they are actually foreign addresses. Do we care about that misclassification (do we use a different reloc for stubs addresses vs external addresses?)

2) We can leave the external addresses table open at the end of the call to table->init_extrs()`. When we enter table->init_early_stubs() we can add these two extra 'pseudo-stub' addresses to the external addresses list and close it before registering the early stubs addresses.

Both of these seem to me to be simpler and cleaner ways to deal with the address publication problem. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3108328211

From adinn at openjdk.org  Wed Jul 23 13:38:57 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 23 Jul 2025 13:38:57 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <nPNfgvYdvC03AkO2SuhKcNQLniRDnOIiJqaUzpj_MdU=.7eefda32-4e12-45ae-a030-4bd8be6517de@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <uKVvAJvagOVP-w6KkJDzld0h_RhqJ-HIvH5_Fw7pVAw=.3cbab103-e321-42e9-902b-64bf07e1b3d3@github.com>
 <isSF8GS6bL8Ycb5yq_B6JpsZZqeEuAKWGmHEn7QHDcc=.bd770c33-fd1d-4738-8363-5f83cfca1bb6@github.com>
 <VVWJFSCK4JIYmlKfs_h_Kh40SG6AjhHlL3GJSovqGjQ=.bdd74447-6679-47c7-90c5-3fb4e30f5767@github.com>
 <-mV1L4ORJqLeTpsCXzPAHaGhUeZSE8kVRR0AzTg8i3g=.40d67121-21a9-4d1b-83ad-b2e941bc7fbb@github.com>
 <2PhAMrGu0NPMoNlugVPgOv8EWUpqcTkgznLEUGouvNo=.ad40b574-8757-4e9b-8953-e50c99fffa0b@github.com>
 <uyXcC96oeMDv-gKhdCT8R_Utcxa1iavpb5fl7ASk6iE=.733093da-1568-46b6-9386-e75ca0b26df9@github.com>
 <hkcADhD0V7oop0N-VfCLggUQGBzEDZs1WvbtS51j6vQ=.41132ba5-3cae-438c-92bb-6e6fc8abbe4a@github.com>
 <0OQ7H6oQ4xqU__xMgC7V6J_y0KyrZmakdm4ZlgjzSd8=.e0193f22-8709-445b-aa3c-a80aa3790d5a@github.com>
 <o-KDX8ojBAC74ZnZf37lsu36kFEmYGcWciq8cuH-SyQ=.fb8e52f9-7e6b-40a2-8c28-708644d7fdc8@github.com>
 <59n-_YwUOUFnb3WToo140MrZ4I1CrOAgbm_
 FLqyQDyw=.abeb5971-a6b1-4101-a661-f6f9841d6b7b@github.com>
 <1UNc1e01QKOcE0e_zeDQ5iY1Vn1pZYJbmjOAp8EVeNs=.98587548-da86-4afd-a3f3-66c1e5fc1a46@github.com>
 <B4Qf8IJgylz3p7xUrXCS5CHbn3PDTDWqG8sA3h5Cqzw=.514a2fcd-c809-4ffb-9a47-1934944eb5f5@github.com>
 <8EJEzIyO7VAy61yeBsPQhtxTXh8S_FmKsqytomnaYFk=.df1bb725-d6f8-4ad6-b189-ea245059b2f1@github.com>
 <w3slBf3RURJ3w6urJ-34OTWCnWlYXYzmrY3ceIaAXvw=.1e7a5fbc-f2f1-44ad-8036-2d03d7595498@github.com>
 <mLwOaOdemVBJqQ-mLjO8pPp7x_HvQt_k0FVftc4A3kg=.63e4d431-765b-4dd6-8e9a-b3e08cf9f62e@github.com>
 <h5qe2PzNUp9MremyUZOwffSc970ByITLFQNEcIKGpyk=.93f3b477-f4da-47e1-a114-638eae8d49b1@github.com>
 <T2MF4TzsdTfgk_k_KCoV42tcKA9XXkC41EhXpN-zuq8=.e6afd373-0c8f-40f7-93b4-28bb5b044be2@github.com>
 <ykVVT1UJrW9ZIiI_h4g7Yluexpz1hBAVAaNHWj6Tptc=.ea588595-2d9b-4c21-8e53-af1e782b30cb@github.com>
 <nPNfgvYdvC03AkO2SuhKcNQLniRDnOIiJqaUzpj_MdU=.7eefda32-4e12-45ae-a030-4bd8be6517de@github.com>
Message-ID: <yNXqc5I5Pe8H7DI2l_ZSgAmwhuFMTT1enIJMY-i2R2Y=.063a4770-29aa-458b-82b4-a833cffe5b35@github.com>

On Wed, 23 Jul 2025 11:49:53 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> I think the differences might be smaller on the real hardware. Maybe everything will be around 200 clocks.
>> If we need code easy to maintain then this is `switch`. If we need performance then this is `tbz`.
>
> @eastig
> I would prefer your `tbz` version for reasons stated earlier, but most notably to make it stable across toolchains.
> But maybe it's best to just integrate it as is since there are other problems ([JDK-8361032](https://bugs.openjdk.org/browse/JDK-8361032) and [JDK-8360936](https://bugs.openjdk.org/browse/JDK-8360936)) that are waiting for this to be fixed.
> 
> Time will tell if this implementation will make performance better or worse. The debate of how to best implement `SpinPause()` will surely not end today. :)

Andrew Haley is right. This is a backoff routine. Making it back off that little bit faster or slower is a pointless micro-optimization.

Of course, making the implementation a lot slower could well upset the dynamics of the backoff but that's a different order of magnitude to what is at stake in the various hand-written or generated assembly routines being discussed here. A key thing to note in that regard is that any branching that happens is going to always be followed the same way and hence will be very accurately predicted.

And in other news . . . Rome is burning . . .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26387#discussion_r2225642394

From shade at openjdk.org  Wed Jul 23 13:54:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Jul 2025 13:54:57 GMT
Subject: RFR: 8363816: Refactor array name creation [v3]
In-Reply-To: <munDmBGKKkGAIrNnqdxmWfkM9TSX8X-r36TSc7J1mx8=.ce175caf-b277-4144-a8a6-ac7e5d6d4eeb@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <munDmBGKKkGAIrNnqdxmWfkM9TSX8X-r36TSc7J1mx8=.ce175caf-b277-4144-a8a6-ac7e5d6d4eeb@github.com>
Message-ID: <OTLqjD1OFaUmgGRmyg1KHX--pf6q2nPJV7jtJb3MXH4=.be8808a2-fda7-4b0c-bb80-605e46cc834a@github.com>

On Wed, 23 Jul 2025 11:41:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Something weird is going on with GHA tests, but I believe those are environmental. This is good to go in.

Speaking of GHA, if you update your https://github.com/coleenp/jdk (it is currently 4400+ commits behind), you'll get some of the nice caching stuff that would likely help these intermittent troubles: https://mail.openjdk.org/pipermail/jdk-dev/2025-July/010211.html

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26430#pullrequestreview-3047563061
PR Comment: https://git.openjdk.org/jdk/pull/26430#issuecomment-3108717692

From eastigeevich at openjdk.org  Wed Jul 23 13:55:04 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 23 Jul 2025 13:55:04 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
Message-ID: <KF-Lzq9bwZAy3mtZpg0qoq9DIz4zhvcWAtlYOVmZBEA=.614b4937-b0bd-43e1-9524-4c1c054aeabf@github.com>

On Mon, 21 Jul 2025 20:31:27 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> ### Background
>> 
>> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
>> 
>> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
>> 
>> ### Summary of changes
>> 
>> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
>> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
>> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
>> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
>> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
>> * Added a gtest to verify the functionality of `SpinPause`.
>> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
>> 
>> ### Testing results: fastdebug, release
>> 
>> - Linux, Graviton 2
>>    - tier1: Passed
>>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
>> - MacOS, M3 Pro
> ...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put cases in enum order

Thank you everyone for review and comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3108684362

From eastigeevich at openjdk.org  Wed Jul 23 13:55:05 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 23 Jul 2025 13:55:05 GMT
Subject: Integrated: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
Message-ID: <hzCKB2KTZYExG2DS5rDgRkLcTzxZTfmGDIW6MeFF_VU=.d7adf49f-cbd5-4d6a-bd65-b625ea60ef3e@github.com>

On Fri, 18 Jul 2025 13:11:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> ### Background
> 
> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
> 
> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
> 
> ### Summary of changes
> 
> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
> * Added a gtest to verify the functionality of `SpinPause`.
> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
> 
> ### Testing results: fastdebug, release
> 
> - Linux, Graviton 2
>    - tier1: Passed
>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
> - MacOS, M3 Pro
>    - tier1, OnSpinWaitInst=default: Passed
>    ...

This pull request has now been integrated.

Changeset: 743c8212
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/743c821289a6562972364b5dcce8dd29a786264a
Stats:     215 lines in 10 files changed: 163 ins; 23 del; 29 mod

8362193: Re-work MacOS/AArch64 SpinPause to handle SB

Reviewed-by: shade, aph

-------------

PR: https://git.openjdk.org/jdk/pull/26387

From tschatzl at openjdk.org  Wed Jul 23 14:34:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 14:34:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v44]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <0KXHzGhrVDYfe_gWdT7DFsZYNyKDDVv9Os8K91HLfUQ=.b120a07e-95d0-4140-be81-a95e1b02f5d5@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - ... and 51 more: https://git.openjdk.org/jdk/compare/743c8212...dd836387

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=43
  Stats: 7122 lines in 112 files changed: 2588 ins; 3592 del; 942 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From coleenp at openjdk.org  Wed Jul 23 14:52:05 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 14:52:05 GMT
Subject: RFR: 8363816: Refactor array name creation [v3]
In-Reply-To: <munDmBGKKkGAIrNnqdxmWfkM9TSX8X-r36TSc7J1mx8=.ce175caf-b277-4144-a8a6-ac7e5d6d4eeb@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
 <munDmBGKKkGAIrNnqdxmWfkM9TSX8X-r36TSc7J1mx8=.ce175caf-b277-4144-a8a6-ac7e5d6d4eeb@github.com>
Message-ID: <gWP1U7CrPKOohb7z70va5NBC90xfCRNUHXV-uZL5zmw=.c6abecde-971f-462f-aadb-79691c445f1b@github.com>

On Wed, 23 Jul 2025 11:41:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
>> Tested with tier1 sanity.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/oops/objArrayKlass.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thanks for approving Aleksey.  I updated my fork just now.  Will that help GHA?  The problems looked environmental to me but it would be nice to have all passing even for a small change like this.

Thanks for reviewing, Aleksey, David and Calvin.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26430#issuecomment-3108972966

From coleenp at openjdk.org  Wed Jul 23 14:52:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 14:52:07 GMT
Subject: Integrated: 8363816: Refactor array name creation
In-Reply-To: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
References: <KX03JC5rBUomrQE4qmzoN5RCcHo4tEX2QTqGx5kfPV4=.e6a0d5ba-6ce5-4928-9e4b-f741d3755172@github.com>
Message-ID: <ghGBvhBOhLK8CTjygP5mRjqFrFOEXEoO0ny1pKiIAXk=.9b2c0db8-89a1-4c36-8e36-89ce4ba262d5@github.com>

On Tue, 22 Jul 2025 17:31:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a simple change that refactors the array name creation (using the element class as part of the name), so that it can be called by other classes in valhalla.
> Tested with tier1 sanity.

This pull request has now been integrated.

Changeset: 38cd860d
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38cd860daa9504bbe5add8c2d045d78c75fb7e38
Stats:     44 lines in 2 files changed: 25 ins; 18 del; 1 mod

8363816: Refactor array name creation

Reviewed-by: shade, ccheung, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26430

From kvn at openjdk.org  Wed Jul 23 15:06:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 15:06:54 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <CjPN4gg5SFqXvEQjRU7n31mQ6npVGA8VTz__2y5ecF4=.12d36bbd-26dd-4f55-9de9-a8995715a5cd@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
 <CjPN4gg5SFqXvEQjRU7n31mQ6npVGA8VTz__2y5ecF4=.12d36bbd-26dd-4f55-9de9-a8995715a5cd@github.com>
Message-ID: <VN-PJMIdzRq9d7KAnTO3BpEw42xLKfdd8EA23qa8K6M=.c693d010-1bcb-4a53-be05-bda990dd4732@github.com>

On Wed, 23 Jul 2025 13:19:35 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> @TheRealMDoerr @offamitkumar @RealFYang please test these changes on your platforms.
>
> @vnkozlov I'll note straight off that the situation here is complicated by the fact that `crc_table_adr` and `crc32c_table_addr` are pseudo-'entries'. They do not actually hold (code or data) addresses in generated code. What they really identify is an arch-specific address for foreign (C++) data that is assigned as a side-effect of performing generation for other entries. the only reason for marking them as entries is so we get a generated field and associated getter in class `StubRoutines`.
> 
> I'm not sure we need to care too much about their pseudo-entry status. More importantly, I dislike your solution of moving the initialization into `generate_preuniverse_stubs()`. This moves that initialization step away from the generator code that uses the resulting value, making it harder to see how the intrinsic works. It also has the unfortunate side effect of forcing us to create a preuinverse blob for every arch even if when we don't really need one.
> 
> You are right that we cannot add these addresses to the external addresses list under `AOTCodeCache::init2()` (via the call to `table->init_extrs()`) because the assignment of the pseudo-entry has not yet happened. However, we have two alternatives.
> 
> 1) We can simply pretend that they are real entries add them to the stub addresses list under `AOTCodeCache::init_early_stubs_table()` (via the call to `table->init_early_stubs()`). That will successfully advertise them  after they have been created as addresses that need relocation at AOT Cache load. However, it will also misclassify them as addresses in generated code when they are actually foreign addresses. Do we care about that misclassification (do we use a different reloc for stubs addresses vs external addresses?)
> 
> 2) We can leave the external addresses table open at the end of the call to table->init_extrs()`. When we enter table->init_early_stubs() we can add these two extra 'pseudo-stub' addresses to the external addresses list and close it before registering the early stubs addresses.
> 
> Both of these seem to me to be simpler and cleaner ways to deal with the address publication problem. What do you think?

Thank you, @adinn  for you suggestions.

> do we use a different reloc for stubs addresses vs external addresses?

1. will not work. They could be different. Stubs use `runtime_call` relic and `crc` uses `external_word`.

I considered 2. when I worked on this but there is assumption that we have all external addresses recorded when we look for matching address in `AOTCodeAddressTable::id_for_address()`. There is specific assert there. And we have relocation in all stubs and adapters.  I am concern about some concurrency issues if we don't satisfy the assumption.

An other solution would be to have separate `StubRoutines::get_crc_table_addr()` which can be use early by AOT code and later by `generate_initial_stubs()`. It will check local value (StubRoutines::x86::_crc32c_table on x86, for example) and calculate it if needed. 

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3109030825

From duke at openjdk.org  Wed Jul 23 15:34:02 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Jul 2025 15:34:02 GMT
Subject: Withdrawn: 8324720: Instruction selection does not respect
 -XX:-UseBMI2Instructions flag
In-Reply-To: <nbtY8tl8vaX4QJUNnOtGrz8NT3USaJok_wj0O4lu38U=.655afad9-7ff1-4e98-84d9-b62517d034af@github.com>
References: <nbtY8tl8vaX4QJUNnOtGrz8NT3USaJok_wj0O4lu38U=.655afad9-7ff1-4e98-84d9-b62517d034af@github.com>
Message-ID: <ISTAB0Qz77cREEhby51zBXDpILzAErKk8934ekrQ1zs=.9a1bd07f-7810-4d09-8ebc-49709dfc38e1@github.com>

On Fri, 23 May 2025 13:50:09 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

> While executing a function  performing `a >> b` operation with `?XX:-UseBMI2Instructions` flag, the generated code contains BMI2 instruction `sarx eax,esi,edx`. The expected output should not contain any BMI2 instruction.  
>  
> ### Analysis and solution 
>  
> As suggested by @merykitty in [JDK-8324720](https://bugs.openjdk.org/browse/JDK-8324720) , the initial idea was to make `VM_Version::supports_bmi2()` respect` UseBMI2Instructions `flag by disabling BMI2 feature when `UseBMI2Instructions` runtime flag is explicitly set to false. This fix is similar to how other runtime flags such as, `UseAPX` and `UseAVX`, enable or disable specific code and register set. However, some test failures were encountered while running tests on this fix. 
> 
> The first set of failures were caused by assertion check on `VM_Version::supports_bmi2()` statement while generating some BMI2 specific instructions. This was caused by the stub generator generating AVX-512 specific code that uses these BMI2 instructions. It should be noted that the `UseAVX` flag is set by default to the highest supported version available in x86 machine. This in turn allows AVX-512 specific code generation whenever possible. In order to not comprise the performance benefits of using AVX-512,  the proposed fix only disables BMI2 feature if AVX-512 features are also disabled  (or not available in the machine) along with the UseBMI2Instructions flag.  
>  
> The second failure occured in `compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnSupportedCPU.java` where a warning "_Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU_." was returned on a AMD64 machine that had support for SHA512. Looking into `compiler/testlibrary/sha/predicate/IntrinsicPredicates.java` it was found that the predicate for AMD64 was not in line with the changes introduced by [JDK-8341052](https://bugs.openjdk.org/browse/JDK-8341052) in commit [85c1aea](https://github.com/openjdk/jdk/pull/20633/commits/85c1aea90b10014aa34dfc902dff2bfd31bd70c0) .

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25415

From adinn at openjdk.org  Wed Jul 23 15:45:57 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 23 Jul 2025 15:45:57 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <VN-PJMIdzRq9d7KAnTO3BpEw42xLKfdd8EA23qa8K6M=.c693d010-1bcb-4a53-be05-bda990dd4732@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
 <CjPN4gg5SFqXvEQjRU7n31mQ6npVGA8VTz__2y5ecF4=.12d36bbd-26dd-4f55-9de9-a8995715a5cd@github.com>
 <VN-PJMIdzRq9d7KAnTO3BpEw42xLKfdd8EA23qa8K6M=.c693d010-1bcb-4a53-be05-bda990dd4732@github.com>
Message-ID: <Ks2OWO9686TM_s0uniOz9zFV0Q-6hYYJJScao9gXOWI=.1d57aba4-4c8e-4dbb-b0ce-1693f75d657c@github.com>

On Wed, 23 Jul 2025 15:04:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Another solution would be to have separate StubRoutines::get_crc_table_addr() which can be use early by AOT code and later by generate_initial_stubs(). It will check local value (StubRoutines::x86::_crc32c_table on x86, for example) and calculate it if needed.

Yes, I think it would be much better if we removed the entry declarations for `crc_table_adr` and `crc32c_table_addr` from stubDeclarations.hpp and instead always looked up the address using a getter method declared in the shared header and implemented in each arch.

We don't need a generated field in class StubRoutines nor any way to track the value as we do for real generated addresses. So, using the declaration mechanism was the wrong way to do this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3109177274

From zgu at openjdk.org  Wed Jul 23 16:25:03 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 23 Jul 2025 16:25:03 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <XoO60brvJtGWR8xGF7VYbC1qDWqOe_c2qnzTucAH-94=.b2926784-4790-417b-bde0-32a5c2aea1a7@github.com>

On Fri, 18 Jul 2025 13:13:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

Looks good!

-------------

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-3048185454

From shade at openjdk.org  Wed Jul 23 19:22:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Jul 2025 19:22:31 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
Message-ID: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>

See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.

Additional testing:
 - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
 - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
 - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
 - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

-------------

Commit messages:
 - Better comment
 - Actually the most paranoid variant is not trusting AOT cache status
 - More paranoid fix for JDK 25
 - Fix

Changes: https://git.openjdk.org/jdk/pull/26449/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360679
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26449.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26449/head:pull/26449

PR: https://git.openjdk.org/jdk/pull/26449

From kvn at openjdk.org  Wed Jul 23 19:37:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 19:37:54 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <ljV7Ah1Ws2ncbGkhsLWSLp-tqIemzBPmqwFTd04RgeA=.cefb547a-554c-445b-94d0-4f0df2f5a028@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

Good catch.

I assume on x86 it is fine.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26449#pullrequestreview-3048739878

From kvn at openjdk.org  Wed Jul 23 19:40:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 19:40:53 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <0xZs7NlMJd_XUfYe6r97lZk59vQr_xSoCD6nIMAPqh0=.a309a520-9fc5-4aa5-a199-affa03638403@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

I am fine with back porting this into JDK 25. Please, file request according to https://openjdk.org/jeps/3#Fix-Request-Process

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26449#issuecomment-3109900378

From shade at openjdk.org  Wed Jul 23 19:49:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Jul 2025 19:49:04 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <ljV7Ah1Ws2ncbGkhsLWSLp-tqIemzBPmqwFTd04RgeA=.cefb547a-554c-445b-94d0-4f0df2f5a028@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
 <ljV7Ah1Ws2ncbGkhsLWSLp-tqIemzBPmqwFTd04RgeA=.cefb547a-554c-445b-94d0-4f0df2f5a028@github.com>
Message-ID: <DTza3mkuBkBuDhij2hVoUT4-okXnht2EI87LVHFkIHc=.246c6832-3864-45fc-9fc4-8acf7a71e076@github.com>

On Wed, 23 Jul 2025 19:34:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I assume on x86 it is fine.

Yes, because on x86 we do the proper VM call. I filed [JDK-8360679](https://bugs.openjdk.org/browse/JDK-8360679) to clean that up. After that is done, we will bring the follow-up fix to 25u. Meanwhile, we want to unbreak JDK 25 GA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26449#issuecomment-3109919349

From dlong at openjdk.org  Wed Jul 23 19:55:34 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 23 Jul 2025 19:55:34 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only
 MacOSX aarch64
Message-ID: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>

This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() do a direct byte store, leaving 24 bits for the guard value.

-------------

Commit messages:
 - trailing white space
 - fix s390 copy-paste
 - use fast path for safepoints
 - ppc align check
 - ppc align
 - simplify x86
 - In CAS loop, update old_value from result of CAS
 - fix ppc build
 - fix zero build
 - ppc typos
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cf75f1f9...ecc6e68e

Changes: https://git.openjdk.org/jdk/pull/26399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361376
  Stats: 214 lines in 13 files changed: 118 ins; 58 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/26399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399

PR: https://git.openjdk.org/jdk/pull/26399

From ayang at openjdk.org  Wed Jul 23 20:13:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 20:13:13 GMT
Subject: Integrated: 8338977: Parallel: Improve heap resizing heuristics
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <VU9Tm1PI8Yz_DKDB9AtUQ2x2Y8DdEa4GwIi0GNPYH5o=.d7783ebb-8868-494c-a949-6bd827e316bc@github.com>

On Fri, 2 May 2025 10:23:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

This pull request has now been integrated.

Changeset: ad510fb2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad510fb25e47098d136515c355164e5177c5b419
Stats:     4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod

8338977: Parallel: Improve heap resizing heuristics

Reviewed-by: zgu, gli, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Wed Jul 23 20:13:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 23 Jul 2025 20:13:12 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]
In-Reply-To: <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <rAPcRMkxD0uoJTzadbMR7eui7ixfiVHCKy8JCvS5TPc=.6307f4fd-e333-41c8-97f2-81971974eb93@github.com>
Message-ID: <_Yg88tIFDmL4WUGVb--Xy-hih_0NrVkmqWU5FfFha4Y=.9e385636-1779-4189-855b-a123cd2b0cd7@github.com>

On Fri, 18 Jul 2025 13:13:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-3109989114

From kvn at openjdk.org  Wed Jul 23 21:26:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 21:26:11 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

   Rework the fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26434/files
  - new: https://git.openjdk.org/jdk/pull/26434/files/6459712d..f0378d20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=01-02

  Stats: 105 lines in 25 files changed: 50 ins; 41 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26434/head:pull/26434

PR: https://git.openjdk.org/jdk/pull/26434

From kvn at openjdk.org  Wed Jul 23 21:29:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Jul 2025 21:29:00 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
Message-ID: <qlcoa6tqaPWj3xOxjF8LSZnJ-ORWdFR1qmZzR8YhjrI=.bde59d8a-e6f3-44b3-8cba-b31cd254b034@github.com>

On Wed, 23 Jul 2025 02:00:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Zero VM

Here is new version of fix as we discussed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3110218210

From dlong at openjdk.org  Wed Jul 23 21:42:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 23 Jul 2025 21:42:54 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
Message-ID: <0hUerokqC_F8hnTVSlcSO7eRDfuq_JhFOMZJGtnVJLg=.85ed9e6e-9fec-4855-a4e0-53748a7b42fa@github.com>

On Fri, 4 Jul 2025 02:33:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix optimized build

@eme64 and @mhaessig, this is somewhat a followup to 8336906, so you may be the best candidates to volunteer to look at this :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3110272992

From jbhateja at openjdk.org  Thu Jul 24 00:41:02 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Jul 2025 00:41:02 GMT
Subject: RFR: 8359965: Enable paired pushp and popp instruction usage for
 APX enabled CPUs [v2]
In-Reply-To: <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>
References: <DkbdpSH83x7bk_k4lPxtwFGb9zTfej-GGKDtctaV0Ug=.175cbeac-ef6d-436e-bc26-0318811278a5@github.com>
 <_G3VGE-OBobi6zHUwA3452t_6Z5O_ojTPI_t8Fdm__M=.097051f1-0478-447d-a46b-b6e6d6cd25e1@github.com>
 <cKNosjZAgL5gVEBIRsyK7k5u5S9INSsoOhRtGLh5RjI=.245036b4-705d-4260-9e02-b54546289ff0@github.com>
 <lsfztlQ2WPq_s2cM8l7K8u7v23M9FLNziW_cZXMKVKs=.4c83100f-37e7-4591-b694-84b05b408e8a@github.com>
 <xpW7ESbV6tppd2r4AIcrLz7sDpoNrM58Ijv7F00sywg=.cc78b545-8870-43ae-87e0-a3fa38b8d44c@github.com>
Message-ID: <1lFbFokLiW3pWxrvq8WtLoiXj-TkYFq2xk-cBtgHvhI=.ab2f363a-60a9-4d9b-aca4-82c770eb1cb2@github.com>

On Mon, 21 Jul 2025 15:44:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi Jatin (@jatin-bhateja), for the first iteration, would it be ok to get the push_paired/pop_paired changes integrated and then make the push2p/pop2p related optimizations in a separate PR?
>> 
>> Thanks,
>> Vamsi
>
> Hi @vamsi-parasa , I think it's ok not to expose pop_ppx / push_ppx as separate interfaces, and let processor forward the values b/w push and matching pop if balancing constraints are satisfied.
> 
> <img width="1055" height="151" alt="image" src="https://github.com/user-attachments/assets/6923ca1b-11eb-4fae-8d51-14f1bfe27cea" />

> Hi Jatin (@jatin-bhateja), the reason to make the push_ppx/pop_ppx usage explicit is because an unbalanced push_ppx operation has a performance penalty.

Thanks @vamsi-parasa , as per APX specification PPX is an optimization hint and should only improve performance if balancing contraintins are met. so I don't think it will have any performance penalty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2227032048

From jrose at openjdk.org  Thu Jul 24 06:10:01 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Jul 2025 06:10:01 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
Message-ID: <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@github.com>

On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - Some more from reviews
>  - Reviewed the diff on github
>  - Stage
>  - Missed comment updates
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b

Good fix.  I added some minor comments.  No logic changes requested!

I'm a little surprised to see the second annotation has survived; I'd prefer to see it totally nuked.  But I am not asking you to remove it; there is an argument that it is helpful.  I requested better documdentation and checking that the two annotations are properly interdependent.  The "runtime setup" annotation should not be allowed except in classes marked as AOT safe.

In a few places you removed an unrelated "non-public" comment.  That is not a good cleanup to incorporate in passing, since the comment is actually functional.

If somebody is arguing that such comments are somehow detrimental, let them make a separate argument and a separate PR to purge them.

src/hotspot/share/classfile/classFileParser.cpp line 5179:

> 5177:       log_info(aot, init)("Found @AOTSafeClassInitializer class %s", ik->external_name());
> 5178:     }
> 5179:   }

This would be a good place to validate that the runtime-setup annotation is only placed on `@AOTSCI` classes.

src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 47:

> 45:  * All bound arguments are encapsulated in dedicated species.
> 46:  */
> 47: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 67:

> 65:  * @param <S> species data type.
> 66:  */
> 67: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 39:

> 37:  * @author jrose
> 38:  */
> 39: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 75:

> 73:  * @author jrose
> 74:  */
> 75: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/jdk/internal/vm/annotation/AOTRuntimeSetup.java line 39:

> 37: ///
> 38: /// `classFileParser.cpp` performs checks on the annotated method - if the
> 39: /// annotated method's signature differs from that described above, a

add:

 /// `classFileParser.cpp` performs checks on the annotated method - if the
 /// annotated method's signature differs from that described above,
+/// or if the enclosing class is not annotated `@AOTSafeClassInitializer`,
 /// a [ClassFormatError] will be thrown.


Otherwise, there are just some late-firing asserts that catch the error.
But the dependency of one annotation on the other should be documented up front.

-------------

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3050063235
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227419561
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227480716
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227481353
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227482049
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227484671
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227401171

From fyang at openjdk.org  Thu Jul 24 07:18:54 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 24 Jul 2025 07:18:54 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
Message-ID: <NASa8-pJ5Pifxndg4H5qi3ic16xPJMkKR7sPQiJ_CrM=.4e6c2c38-c3cc-4aae-b164-e2af5d27793b@github.com>

On Wed, 23 Jul 2025 01:07:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @TheRealMDoerr @offamitkumar @RealFYang please test these changes on your platforms.

Thanks for the ping. I performed tier1 test and I see the result is clean with the latest version on linux-riscv64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3112326408

From adinn at openjdk.org  Thu Jul 24 07:27:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 24 Jul 2025 07:27:53 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <iYxUQOcGg-PCVBiMTkvjfMCiVwhbtHdlmp4ux6G-Tnc=.49122148-c4d6-4520-9a17-d83a1a37aa2e@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

Nice catch!

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26449#pullrequestreview-3050427010

From adinn at openjdk.org  Thu Jul 24 07:44:55 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 24 Jul 2025 07:44:55 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
Message-ID: <VB-OvdXTwnjn5U5uyzTGecPdP9yJkXobO9o6cZPUaaA=.15c05099-1ee9-4f2c-9df8-aaf99521a16f@github.com>

On Wed, 23 Jul 2025 21:26:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Rework the fix

src/hotspot/cpu/zero/stubDeclarations_zero.hpp line 40:

> 38:                                       do_arch_entry,                    \
> 39:                                       do_arch_entry_init)               \
> 40:   do_arch_blob(initial, 32)                                             \

Do we need this any more?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2227698445

From adinn at openjdk.org  Thu Jul 24 07:51:01 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 24 Jul 2025 07:51:01 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
Message-ID: <LFxQFrUPXEjtdpPexHTavudA9lyjmwMDZXBJ2AuaH50=.c8286fcd-1cbc-4361-a266-dc45cedcf4f6@github.com>

On Wed, 23 Jul 2025 21:26:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Rework the fix

src/hotspot/share/runtime/stubRoutines.hpp line 306:

> 304:     return dest_uninitialized ? _arrayof_oop_disjoint_arraycopy_uninit : _arrayof_oop_disjoint_arraycopy;
> 305:   }
> 306: 

Could we have a comment here to note that 1) this method is implemented in architecture-specific code 2) any table that is returned must be allocated once-only in foreign memory rather generated in the code cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2227726242

From shade at openjdk.org  Thu Jul 24 08:41:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 08:41:55 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <0xZs7NlMJd_XUfYe6r97lZk59vQr_xSoCD6nIMAPqh0=.a309a520-9fc5-4aa5-a199-affa03638403@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
 <0xZs7NlMJd_XUfYe6r97lZk59vQr_xSoCD6nIMAPqh0=.a309a520-9fc5-4aa5-a199-affa03638403@github.com>
Message-ID: <nqkFGOKGkGTD3MLTnl_YA4VKucUah37sqawGoCUqx0E=.19b2a5a2-6c63-4219-ac76-de27758b08d5@github.com>

On Wed, 23 Jul 2025 19:38:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am fine with back porting this into JDK 25. Please, file request according to https://openjdk.org/jeps/3#Fix-Request-Process

Thanks! Request filed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26449#issuecomment-3112576283

From duke at openjdk.org  Thu Jul 24 08:46:06 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 08:46:06 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v2]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <cJTHAWqalKZSxr9BctGVO_IsDV0VIohnjkKjCFpAgm8=.7ad26330-00c5-46a2-a0e2-12dbae67012e@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  move comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/0d1868a3..6c8507a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=00-01

  Stats: 21 lines in 1 file changed: 11 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From aph at openjdk.org  Thu Jul 24 08:46:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 24 Jul 2025 08:46:54 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <AFEw-Ewn7GKmWHqUlJ510Fq8cqb10qfK5JZfG08FSmU=.d7064d52-60ac-4e06-9d29-c6927138e47a@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26449#pullrequestreview-3050694675

From duke at openjdk.org  Thu Jul 24 08:52:38 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 08:52:38 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v3]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <x-TZkhHmvwB3Gm_kK3w-3WZpDxWHxz3SuMJosjAVIBs=.6881818c-9136-4a45-9cf3-6eb5109eddcb@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/6c8507a0..c33773ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From duke at openjdk.org  Thu Jul 24 08:52:38 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 08:52:38 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v3]
In-Reply-To: <CObC9qvXuWkJfMchxEXC4woEfxSNSEox2jZKL4p4FQw=.1b77c0bf-14b7-419d-9a51-b97aaf910e89@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
 <CObC9qvXuWkJfMchxEXC4woEfxSNSEox2jZKL4p4FQw=.1b77c0bf-14b7-419d-9a51-b97aaf910e89@github.com>
Message-ID: <3aff9b7le6FZ7rJ_FtGOnGhB_tyLZpLuhEnYZdKRdFA=.6c3c3404-2d9e-4ffd-b27b-979c5ef74238@github.com>

On Wed, 23 Jul 2025 08:25:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 43:
>> 
>>> 41: # include <io.h>    // for stream.cpp
>>> 42: # include <float.h> // for _isnan
>>> 43: # include <stdio.h> // for va_list
>> 
>> These aren't being flagged as out of order by the checker, because of the trailing comments.
>> And the comment for `<stdio.h>` is odd, since that's already being brought in by `<stdarg.h>`.
>
> @kimbarrett How should we tackle this problem? I tried the following:
> 
>  # include <stdlib.h>
>  # include <string.h>
> -# include <stddef.h>// for offsetof
> +// for offsetof
> +# include <stddef.h>
>  # include <sys/stat.h>
> -# include <io.h>    // for stream.cpp
> -# include <float.h> // for _isnan
> -# include <stdio.h> // for va_list
> +// for stream.cpp
> +# include <io.h>
> +// for _isnan
> +# include <float.h>
> +// for va_list
> +# include <stdio.h>
>  # include <fcntl.h>
>  # include <inttypes.h>
>  # include <limits.h>
> 
> 
> Then running `SortInclude` gives the following result:
> 
>  # include <float.h>
>  // for va_list
> -# include <stdio.h>
>  # include <fcntl.h>
>  # include <inttypes.h>
>  # include <limits.h>
> +# include <stdio.h>
>  # include <time.h>
> 
> 
> from which I infer that `SortInclude` disregards comments above the `include` statement, which of course is not what we want. 
> 
> Either we remove the comments, or `SortIncludes.java` should be improved somehow. For example, I see the following comment in `TestIncludesAreSorted`:
> 
> Note that non-space characters after the closing " or > of an include statement
> can be used to prevent re-ordering of the include.
> 
> Would it be acceptable to change this behavior to prevent only lines containing a particular combination from being reordered? (e.g. `// do not reorder`)

Fixed in 6c8507a09d1f2e9956ce18b14993382622e6741f, I manually removed the comment, ran the tool, and re-applied the comments. Should be good enough, but I wonder if such operation could be done by the tool automagically?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2227877312

From duke at openjdk.org  Thu Jul 24 08:52:38 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 08:52:38 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v3]
In-Reply-To: <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
Message-ID: <XSeD2EwpsQfv3hkfD60fsAeIto5uE9EOtIKApf4dzA4=.23eccc4f-4127-4a69-9376-c9ec3a955667@github.com>

On Tue, 22 Jul 2025 19:28:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 47:
> 
>> 45: # include <inttypes.h>
>> 46: # include <limits.h>
>> 47: # include <time.h>
> 
> And these were blocked from reordering across the "no reorder" commented includes.

Fixed in 6c8507a09d1f2e9956ce18b14993382622e6741f

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2227875050

From duke at openjdk.org  Thu Jul 24 08:56:55 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 08:56:55 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v3]
In-Reply-To: <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
Message-ID: <xDWppvzlOKErnfqir__XGq1aCKbxMCoIyVcSnexcZHA=.97a73985-a78a-4ebd-a778-006319bdbabd@github.com>

On Tue, 22 Jul 2025 19:31:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 50:
> 
>> 48: // Need this on windows to get the math constants (e.g., M_PI).
>> 49: #define _USE_MATH_DEFINES
>> 50: # include <math.h>
> 
> There's a separate problem, unrelated to include order cleanup, that `_USE_MATH_DEFINES` is being
> defined here, as that's too late if `<math.h>` happened to be included already. I'll file a bug to address that.
> (Apparently not causing problems currently, but include reorderings could trigger problems.)

https://bugs.openjdk.org/browse/JDK-8363885

I moved it before all the include statements for now, should be fine until JDK-8363885 is addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2227888502

From mhaessig at openjdk.org  Thu Jul 24 09:16:07 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 24 Jul 2025 09:16:07 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
Message-ID: <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>

On Fri, 4 Jul 2025 02:33:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix optimized build

Thank you for this enhancement, @dean-long! I made a first pass to try and understand the logic, but ended up only commenting on cosmetics. I'll do a second pass next week.

src/hotspot/share/runtime/deoptimization.cpp line 847:

> 845: 
> 846: #ifndef PRODUCT
> 847: #ifdef ASSERT

Why is both `NOT_PRODUCT` and `ASSERT` needed here? So far, I thought that `ASSERT` implies `NOT_PRODUCT`.

src/hotspot/share/runtime/deoptimization.cpp line 939:

> 937:     bool is_top_frame = true;
> 938:     int callee_size_of_parameters = 0;
> 939:     for (int i = 0; i < cur_array->frames(); i++) {

I would suggest renaming `i`to `frame_idx` because there is one usage 50 lines down that would be much more clear with a more verbose name.

src/hotspot/share/runtime/deoptimization.cpp line 947:

> 945: 
> 946:       // Get the oop map for this bci
> 947:       InterpreterOopMap mask;

Perhaps you could move that down to line 977. It would just be one less variable to keep track.

src/hotspot/share/runtime/deoptimization.cpp line 950:

> 948:       int cur_invoke_parameter_size = 0;
> 949:       int top_frame_expression_stack_adjustment = 0;
> 950:       int bci = iframe->interpreter_frame_bci();

`bci` is only used in the `BytecodeStream` constructor below. I would suggest to just call `iframe->interpreter_frame_bci()` in the constructor and forego the variable definition.

src/hotspot/share/runtime/deoptimization.cpp line 999:

> 997:             (iframe_expr_size == mask.expression_stack_size() + callee_size_of_parameters)
> 998:             ))))
> 999:       {

Suggestion:

      int iframe_expr_size = iframe->interpreter_frame_expression_stack_size();
      int expr_stack_size_before = iframe_expr_size + (is_top_frame ? top_frame_expression_stack_adjustment : 0);

      if (!((is_top_frame && exec_mode == Unpack_exception && iframe_expr_size == 0) ||
            (reexecute ?
             (expr_stack_size_before == mask.expression_stack_size() + cur_invoke_parameter_size) :
             (iframe_expr_size == mask.expression_stack_size() + callee_size_of_parameters)
            ))) {

These parentheses can be simplified a bit.

src/hotspot/share/runtime/vframeArray.cpp line 195:

> 193:     Bytecodes::Code code = Bytecodes::code_at(method(), bcp);
> 194:     assert(!Interpreter::bytecode_should_reexecute(code), "should_reexecute mismatch");
> 195:   }

This might be a candidate for `#ifdef ASSERT`?
Suggestion:

#ifdef ASSERT
  if (!reexec) {
    address bcp = method()->bcp_from(bci());
    Bytecodes::Code code = Bytecodes::code_at(method(), bcp);
    assert(!Interpreter::bytecode_should_reexecute(code), "should_reexecute mismatch");
  }
#endif

src/hotspot/share/runtime/vframeArray.cpp line 239:

> 237:       pc = Interpreter::deopt_reexecute_entry(method(), bcp);
> 238:     }
> 239:     assert(reexecute, "must be");

This assert is a bit redundant with the condition on this branch and `reexecute` not being assigned to.
Suggestion:

src/hotspot/share/runtime/vframeArray.hpp line 1:

> 1: /*

Please update the copyright year in this file.

-------------

Changes requested by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26121#pullrequestreview-3050547887
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227775314
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227853547
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227821569
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227832230
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227790942
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227879608
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227895145
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227887220

From mhaessig at openjdk.org  Thu Jul 24 09:16:08 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 24 Jul 2025 09:16:08 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
 <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>
Message-ID: <T_YbhLza_qGLP8jxnZmN8qJVycq6v3ixaEweEHel-_g=.3dda1c37-a694-4e31-aff3-f3c2502b23f5@github.com>

On Thu, 24 Jul 2025 08:13:40 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix optimized build
>
> src/hotspot/share/runtime/deoptimization.cpp line 999:
> 
>> 997:             (iframe_expr_size == mask.expression_stack_size() + callee_size_of_parameters)
>> 998:             ))))
>> 999:       {
> 
> Suggestion:
> 
>       int iframe_expr_size = iframe->interpreter_frame_expression_stack_size();
>       int expr_stack_size_before = iframe_expr_size + (is_top_frame ? top_frame_expression_stack_adjustment : 0);
> 
>       if (!((is_top_frame && exec_mode == Unpack_exception && iframe_expr_size == 0) ||
>             (reexecute ?
>              (expr_stack_size_before == mask.expression_stack_size() + cur_invoke_parameter_size) :
>              (iframe_expr_size == mask.expression_stack_size() + callee_size_of_parameters)
>             ))) {
> 
> These parentheses can be simplified a bit.

Suggestion:

int iframe_expr_ssize = iframe->interpreter_frame_expression_stack_size();
      int map_expr_invoke_ssize = mask.expression_stack_size() + cur_invoke_parameter_size;
      int expr_ssize_before = iframe_expr_ssize + (is_top_frame ? top_frame_expression_stack_adjustment : 0);
      int map_expr_callee_ssize = mask.expression_stack_size() + callee_size_of_parameters;

      if (!((is_top_frame && exec_mode == Unpack_exception && iframe_expr_ssize == 0) ||
            (reexecute ? expr_ssize_before == map_expr_invoke_ssize :
                         iframe_expr_ssize == map_expr_callee_ssize)
           )) {

Personally, I would write something like this, but feel free to disregard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2227794608

From eastigeevich at openjdk.org  Thu Jul 24 09:32:54 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 24 Jul 2025 09:32:54 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions
In-Reply-To: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
Message-ID: <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>

On Fri, 18 Jul 2025 19:33:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
> 
> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.

src/hotspot/share/runtime/stubRoutines.cpp line 170:

> 168:   // When new stubs added we need to make sure there is some space left
> 169:   // to catch situation when we should increase size again.
> 170:   assert(code_size == 0 || buffer.insts_remaining() > 200, "increase %s", assert_msg);

What is the reason to move the assert?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2227982091

From duke at openjdk.org  Thu Jul 24 09:43:50 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 09:43:50 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v4]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <w8OQ8DPWs-hO-hhR01bpMMFFw4yqiR2WKC80v-S9r8E=.03f4bf6c-a578-4ee3-a8bd-53b536f1e73d@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  more sorting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/c33773ec..b01fdab5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=02-03

  Stats: 29 lines in 3 files changed: 14 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From sspitsyn at openjdk.org  Thu Jul 24 09:48:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Jul 2025 09:48:57 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

src/hotspot/share/runtime/threadSMR.cpp line 839:

> 837:        }
> 838:        if (java_thread == nullptr) {
> 839:          // Virtual thread was unmounted, or else carrier has now terminated.

Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing.

I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread
 - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace)
 - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted
 
So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228017957

From duke at openjdk.org  Thu Jul 24 10:08:44 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 10:08:44 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v5]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <hcFPACeNpqMckigBbtbSBfzQBQmeE3lIq5OZJo2I_As=.6670eaba-8762-4fd0-b955-6d0ae3cc2292@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/b01fdab5..41c6df80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From duke at openjdk.org  Thu Jul 24 10:08:44 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 10:08:44 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v5]
In-Reply-To: <u8PAIVyjTszZfrNlVBd-uPeJs1-IHTjQ_dcyw-2ziTs=.60332280-7de2-4490-8d2b-a691ed980277@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <u8PAIVyjTszZfrNlVBd-uPeJs1-IHTjQ_dcyw-2ziTs=.60332280-7de2-4490-8d2b-a691ed980277@github.com>
Message-ID: <du2JDE0Tj4lEqB4Aqaa4ZVHR9uqHkxPb4NXhiIjd-98=.29fb4c64-4289-4c77-95c9-aa3325c7ce9d@github.com>

On Tue, 22 Jul 2025 14:57:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   up
>
> Looks reasonable to me. Need to wait for builds to complete, 24 hours cooldown, and have another Reviewer.

Thanks for the review @shipilev @kimbarrett, I made a few more changes and chased a few more missing reorders. This is ready for a second round of review when you have time. I re-run tier1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26428#issuecomment-3112859133

From duke at openjdk.org  Thu Jul 24 10:57:36 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 10:57:36 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v6]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <4jrmskHlTlvLeMt0Cp3Ap2sZZxcjv3PPi1nzgwEXwyU=.37757695-6bf9-426f-81f7-503ba79b9bf5@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

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/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/41c6df80..8ebbfaf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From duke at openjdk.org  Thu Jul 24 10:57:36 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 10:57:36 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v6]
In-Reply-To: <3aff9b7le6FZ7rJ_FtGOnGhB_tyLZpLuhEnYZdKRdFA=.6c3c3404-2d9e-4ffd-b27b-979c5ef74238@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <0OVOqD0gdU2QutzexV-F52YGO6EbD-B_EcMl8UMTfdk=.99678ddc-499a-4fca-930f-541dc693be4c@github.com>
 <CObC9qvXuWkJfMchxEXC4woEfxSNSEox2jZKL4p4FQw=.1b77c0bf-14b7-419d-9a51-b97aaf910e89@github.com>
 <3aff9b7le6FZ7rJ_FtGOnGhB_tyLZpLuhEnYZdKRdFA=.6c3c3404-2d9e-4ffd-b27b-979c5ef74238@github.com>
Message-ID: <QMgN1m_Ea7xTTbZeyjKp7LdHTMWwlJo1eCxJyJnKDuY=.dd7c936f-895a-4643-be99-76deb3e364fe@github.com>

On Thu, 24 Jul 2025 08:49:41 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> @kimbarrett How should we tackle this problem? I tried the following:
>> 
>>  # include <stdlib.h>
>>  # include <string.h>
>> -# include <stddef.h>// for offsetof
>> +// for offsetof
>> +# include <stddef.h>
>>  # include <sys/stat.h>
>> -# include <io.h>    // for stream.cpp
>> -# include <float.h> // for _isnan
>> -# include <stdio.h> // for va_list
>> +// for stream.cpp
>> +# include <io.h>
>> +// for _isnan
>> +# include <float.h>
>> +// for va_list
>> +# include <stdio.h>
>>  # include <fcntl.h>
>>  # include <inttypes.h>
>>  # include <limits.h>
>> 
>> 
>> Then running `SortInclude` gives the following result:
>> 
>>  # include <float.h>
>>  // for va_list
>> -# include <stdio.h>
>>  # include <fcntl.h>
>>  # include <inttypes.h>
>>  # include <limits.h>
>> +# include <stdio.h>
>>  # include <time.h>
>> 
>> 
>> from which I infer that `SortInclude` disregards comments above the `include` statement, which of course is not what we want. 
>> 
>> Either we remove the comments, or `SortIncludes.java` should be improved somehow. For example, I see the following comment in `TestIncludesAreSorted`:
>> 
>> Note that non-space characters after the closing " or > of an include statement
>> can be used to prevent re-ordering of the include.
>> 
>> Would it be acceptable to change this behavior to prevent only lines containing a particular combination from being reordered? (e.g. `// do not reorder`)
>
> Fixed in 6c8507a09d1f2e9956ce18b14993382622e6741f, I manually removed the comment, ran the tool, and re-applied the comments. Should be good enough, but I wonder if such operation could be done by the tool automagically?

> And the comment for <stdio.h> is odd, since that's already being brought in by <stdarg.h>.

I see @kimbarrett, fixed in 8ebbfaf61823933895ab3757d352eaa90051fde8. I simply removed the comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2228175768

From stuefe at openjdk.org  Thu Jul 24 11:44:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 11:44:11 GMT
Subject: RFR: 8364004: Add an option for delayed crash tests
Message-ID: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>

Pretty simple small addition to make `-XX:ErrorHandlerTest` work with an optional delay. This is a preparatory patch for some future planned refinements/additions to the error handler tests. It makes it possible to let the JVM warm up for a second or three, then to crash, in order to then observe an error log from a warmed-up JVM.

-------------

Commit messages:
 - adapt test
 - start

Changes: https://git.openjdk.org/jdk/pull/26453/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364004
  Stats: 40 lines in 5 files changed: 31 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26453/head:pull/26453

PR: https://git.openjdk.org/jdk/pull/26453

From dholmes at openjdk.org  Thu Jul 24 12:34:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 12:34:05 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
Message-ID: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>

On Thu, 24 Jul 2025 12:29:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.cpp line 839:
>> 
>>> 837:        }
>>> 838:        if (java_thread == nullptr) {
>>> 839:          // Virtual thread was unmounted, or else carrier has now terminated.
>> 
>> Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing.
>> 
>> I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread
>>  - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace)
>>  - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted
>>  
>> So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler.
>
> The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle.
> 
> The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of  vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier.

Note that `java_thread` may already be null so we don't get to execute line 836.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228385947

From dholmes at openjdk.org  Thu Jul 24 12:34:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 12:34:04 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
Message-ID: <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>

On Thu, 24 Jul 2025 09:44:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> src/hotspot/share/runtime/threadSMR.cpp line 839:
> 
>> 837:        }
>> 838:        if (java_thread == nullptr) {
>> 839:          // Virtual thread was unmounted, or else carrier has now terminated.
> 
> Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing.
> 
> I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread
>  - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace)
>  - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted
>  
> So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler.

The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle.

The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of  vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228382680

From mgronlun at openjdk.org  Thu Jul 24 12:56:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 24 Jul 2025 12:56:05 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method
Message-ID: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>

Greetings,

The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".

It involves three components:

1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().

2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.

3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.

There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.

Testing: jdk_jfr, stress testing

Thank you
Markus

-------------

Commit messages:
 - 8356587

Changes: https://git.openjdk.org/jdk/pull/26458/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356587
  Stats: 304 lines in 23 files changed: 123 ins; 106 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/26458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458

PR: https://git.openjdk.org/jdk/pull/26458

From duke at openjdk.org  Thu Jul 24 13:25:24 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 24 Jul 2025 13:25:24 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt, metaprogramming
Message-ID: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>

This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
- hotspot/share/adlc 
- hotspot/share/libadt
- hotspot/share/metaprogramming

I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.

I'm also adding the directory to TestIncludesAreSorted.java.

Passes tier1.

-------------

Commit messages:
 - move comment
 - sort

Changes: https://git.openjdk.org/jdk/pull/26460/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364037
  Stats: 30 lines in 6 files changed: 17 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26460/head:pull/26460

PR: https://git.openjdk.org/jdk/pull/26460

From yzheng at openjdk.org  Thu Jul 24 13:25:57 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 24 Jul 2025 13:25:57 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
Message-ID: <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>

On Wed, 23 Jul 2025 02:00:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Zero VM

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 420:

> 418:   static_field(StubRoutines,                _dilithiumDecomposePoly,                          address)                               \
> 419:   static_field(StubRoutines,                _updateBytesCRC32,                                address)                               \
> 420:   static_field(StubRoutines,                _crc_table_addr,                                  address)                               \

Could you please export via `CompilerToVM::Data`?

diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
index 41531b083fc..71331b578a5 100644
--- a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
@@ -131,6 +131,8 @@ class CompilerToVM {
     static address dlog10;
     static address dpow;
 
+    static address crc_table_addr;
+
     static address symbol_init;
     static address symbol_clinit;
 
diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
index b6d919fdfe9..8a1a02d62b3 100644
--- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
@@ -151,6 +151,8 @@ address CompilerToVM::Data::dlog;
 address CompilerToVM::Data::dlog10;
 address CompilerToVM::Data::dpow;
 
+address CompilerToVM::Data::crc_table_addr;
+
 address CompilerToVM::Data::symbol_init;
 address CompilerToVM::Data::symbol_clinit;
 
@@ -289,6 +291,7 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
 
   SET_TRIGFUNC_OR_NULL(dtanh);
   SET_TRIGFUNC_OR_NULL(dcbrt);
+  SET_TRIGFUNC_OR_NULL(crc_table_addr);
 
 #undef SET_TRIGFUNC_OR_NULL
 
diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 1408cb09b0a..88d098468e9 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -147,6 +147,7 @@
   static_field(CompilerToVM::Data,             dlog,                                   address)                                      \
   static_field(CompilerToVM::Data,             dlog10,                                 address)                                      \
   static_field(CompilerToVM::Data,             dpow,                                   address)                                      \
+  static_field(CompilerToVM::Data,             crc_table_addr,                         address)                                      \
                                                                                                                                      \
   static_field(CompilerToVM::Data,             symbol_init,                            address)                                      \
   static_field(CompilerToVM::Data,             symbol_clinit,                          address)                                      \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228514289

From rriggs at openjdk.org  Thu Jul 24 14:08:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 14:08:57 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>
Message-ID: <KKkCYGaQEVck6JjJqAp3Ndh7hmV80dLdY51_Qhsw49A=.4fbfba9e-d5c3-4197-bba8-01a2695b72fa@github.com>

On Wed, 23 Jul 2025 12:54:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds

Will re-review when the changes settle.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3051829566

From kvn at openjdk.org  Thu Jul 24 15:06:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:06:57 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <VB-OvdXTwnjn5U5uyzTGecPdP9yJkXobO9o6cZPUaaA=.15c05099-1ee9-4f2c-9df8-aaf99521a16f@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
 <VB-OvdXTwnjn5U5uyzTGecPdP9yJkXobO9o6cZPUaaA=.15c05099-1ee9-4f2c-9df8-aaf99521a16f@github.com>
Message-ID: <4ME73Xqjc4FYKFsOxK0n1JViBulhj9-_ukphppVCHyw=.764525b8-c965-4522-a0c5-c70422f060b0@github.com>

On Thu, 24 Jul 2025 07:42:03 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Rework the fix
>
> src/hotspot/cpu/zero/stubDeclarations_zero.hpp line 40:
> 
>> 38:                                       do_arch_entry,                    \
>> 39:                                       do_arch_entry_init)               \
>> 40:   do_arch_blob(initial, 32)                                             \
> 
> Do we need this any more?

Yes, to call `generate_initial_stubs()` where `_call_stub_entry` is set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228794225

From kvn at openjdk.org  Thu Jul 24 15:21:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:21:52 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v4]
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <Ci4xYGTLlQIdhXFoDUSJ9FMu1jxTlqz4ytnVPgGl49g=.72f255c9-c300-4ddc-bf22-e51c9e623ef4@github.com>

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26434/files
  - new: https://git.openjdk.org/jdk/pull/26434/files/f0378d20..71d29f9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26434/head:pull/26434

PR: https://git.openjdk.org/jdk/pull/26434

From kvn at openjdk.org  Thu Jul 24 15:21:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:21:55 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
Message-ID: <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>

On Thu, 24 Jul 2025 13:23:26 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed Zero VM
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 420:
> 
>> 418:   static_field(StubRoutines,                _dilithiumDecomposePoly,                          address)                               \
>> 419:   static_field(StubRoutines,                _updateBytesCRC32,                                address)                               \
>> 420:   static_field(StubRoutines,                _crc_table_addr,                                  address)                               \
> 
> Could you please export via `CompilerToVM::Data`?
> 
> diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
> index 41531b083fc..71331b578a5 100644
> --- a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
> @@ -131,6 +131,8 @@ class CompilerToVM {
>      static address dlog10;
>      static address dpow;
>  
> +    static address crc_table_addr;
> +
>      static address symbol_init;
>      static address symbol_clinit;
>  
> diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> index b6d919fdfe9..8a1a02d62b3 100644
> --- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> @@ -151,6 +151,8 @@ address CompilerToVM::Data::dlog;
>  address CompilerToVM::Data::dlog10;
>  address CompilerToVM::Data::dpow;
>  
> +address CompilerToVM::Data::crc_table_addr;
> +
>  address CompilerToVM::Data::symbol_init;
>  address CompilerToVM::Data::symbol_clinit;
>  
> @@ -289,6 +291,7 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
>  
>    SET_TRIGFUNC_OR_NULL(dtanh);
>    SET_TRIGFUNC_OR_NULL(dcbrt);
> +  SET_TRIGFUNC_OR_NULL(crc_table_addr);
>  
>  #undef SET_TRIGFUNC_OR_NULL
>  
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 1408cb09b0a..88d098468e9 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -147,6 +147,7 @@
>    static_field(CompilerToVM::Data,             dlog,                                   address)                                      \
>    static_field(CompilerToVM::Data,             dlog10,                                 address)                                      \
>    static_field(CompilerToVM::Data,             dpow,                                   address)                                      \
> +  static_field(CompilerToVM::Data,             crc_table_addr,                         address)         ...

@mur47x111 sure.  But do you need also `crc32c_table_addr`?  And I don't see initialization. Can you prepare full patch for JVMCI which I can integrate?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228817259

From kvn at openjdk.org  Thu Jul 24 15:21:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:21:55 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
Message-ID: <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>

On Thu, 24 Jul 2025 15:13:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 420:
>> 
>>> 418:   static_field(StubRoutines,                _dilithiumDecomposePoly,                          address)                               \
>>> 419:   static_field(StubRoutines,                _updateBytesCRC32,                                address)                               \
>>> 420:   static_field(StubRoutines,                _crc_table_addr,                                  address)                               \
>> 
>> Could you please export via `CompilerToVM::Data`?
>> 
>> diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
>> index 41531b083fc..71331b578a5 100644
>> --- a/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
>> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
>> @@ -131,6 +131,8 @@ class CompilerToVM {
>>      static address dlog10;
>>      static address dpow;
>>  
>> +    static address crc_table_addr;
>> +
>>      static address symbol_init;
>>      static address symbol_clinit;
>>  
>> diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
>> index b6d919fdfe9..8a1a02d62b3 100644
>> --- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
>> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
>> @@ -151,6 +151,8 @@ address CompilerToVM::Data::dlog;
>>  address CompilerToVM::Data::dlog10;
>>  address CompilerToVM::Data::dpow;
>>  
>> +address CompilerToVM::Data::crc_table_addr;
>> +
>>  address CompilerToVM::Data::symbol_init;
>>  address CompilerToVM::Data::symbol_clinit;
>>  
>> @@ -289,6 +291,7 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
>>  
>>    SET_TRIGFUNC_OR_NULL(dtanh);
>>    SET_TRIGFUNC_OR_NULL(dcbrt);
>> +  SET_TRIGFUNC_OR_NULL(crc_table_addr);
>>  
>>  #undef SET_TRIGFUNC_OR_NULL
>>  
>> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
>> index 1408cb09b0a..88d098468e9 100644
>> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
>> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
>> @@ -147,6 +147,7 @@
>>    static_field(CompilerToVM::Data,             dlog,                                   address)                                      \
>>    static_field(CompilerToVM::Data,             dlog10,                                 address)                                      \
>>    static_field(CompilerToVM::Data,             dpow,                                   address)                                      \
>> +  sta...
>
> @mur47x111 sure.  But do you need also `crc32c_table_addr`?  And I don't see initialization. Can you prepare full patch for JVMCI which I can integrate?

Initialization is done by `SET_TRIGFUNC_OR_NULL()`. I see.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228825985

From kvn at openjdk.org  Thu Jul 24 15:21:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:21:56 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
 <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
Message-ID: <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>

On Thu, 24 Jul 2025 15:16:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @mur47x111 sure.  But do you need also `crc32c_table_addr`?  And I don't see initialization. Can you prepare full patch for JVMCI which I can integrate?
>
> Initialization is done by `SET_TRIGFUNC_OR_NULL()`. I see.

Okay, I will add crc32c_table_addr myself then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228830008

From kvn at openjdk.org  Thu Jul 24 15:21:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:21:58 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <LFxQFrUPXEjtdpPexHTavudA9lyjmwMDZXBJ2AuaH50=.c8286fcd-1cbc-4361-a266-dc45cedcf4f6@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
 <LFxQFrUPXEjtdpPexHTavudA9lyjmwMDZXBJ2AuaH50=.c8286fcd-1cbc-4361-a266-dc45cedcf4f6@github.com>
Message-ID: <6L0u6QsWNsH9G_vmwaJheoORE5EUcePeeu-BTqHaer0=.b09dfaa1-fe24-4e5f-9cff-a022d0f5f622@github.com>

On Thu, 24 Jul 2025 07:48:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    Rework the fix
>
> src/hotspot/share/runtime/stubRoutines.hpp line 306:
> 
>> 304:     return dest_uninitialized ? _arrayof_oop_disjoint_arraycopy_uninit : _arrayof_oop_disjoint_arraycopy;
>> 305:   }
>> 306: 
> 
> Could we have a comment here to note that 1) this method is implemented in architecture-specific code 2) any table that is returned must be allocated once-only in foreign memory rather generated in the code cache.

Done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228819851

From tschatzl at openjdk.org  Thu Jul 24 15:29:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Jul 2025 15:29:56 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64
In-Reply-To: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
Message-ID: <9OGIoq7EaDQnBhnzMzX3sHGq99xQHthjkG4xbxvSDzc=.9d5ed8b8-62bf-4f4e-b0dc-3cfb3193afca@github.com>

On Sat, 19 Jul 2025 01:39:12 GMT, Dean Long <dlong at openjdk.org> wrote:

> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.

Afaics the `NMethodEntryBarrier_lock` declaration/definition can also be removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3113913189

From kvn at openjdk.org  Thu Jul 24 15:36:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:36:00 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
 <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
 <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>
Message-ID: <E0ouDP0GEqicPIHD_cfCTTc9zno_N6K8mz5PibcuvVM=.46ffbffd-5747-4a2a-a0a0-7e78d7396cb1@github.com>

On Thu, 24 Jul 2025 15:17:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Initialization is done by `SET_TRIGFUNC_OR_NULL()`. I see.
>
> Okay, I will add crc32c_table_addr myself then.

I see that crc32c_table_addr() failed on Aarch64 because we should not call it. 
I will go with your patch @mur47x111 then and let you solve crc32c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228864420

From kvn at openjdk.org  Thu Jul 24 15:45:26 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:45:26 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v5]
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  JVMCI fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26434/files
  - new: https://git.openjdk.org/jdk/pull/26434/files/71d29f9f..eaba165a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26434&range=03-04

  Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26434/head:pull/26434

PR: https://git.openjdk.org/jdk/pull/26434

From adinn at openjdk.org  Thu Jul 24 15:45:26 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 24 Jul 2025 15:45:26 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v5]
In-Reply-To: <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
Message-ID: <kPV_vbFvSnEmHQvgWouAyLwjeSwTDWI5NWYbIX2kA4U=.eaaf05a2-a0e0-4504-b130-0dc196200195@github.com>

On Thu, 24 Jul 2025 15:42:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI fix

Looks ok to me.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26434#pullrequestreview-3052221039

From kvn at openjdk.org  Thu Jul 24 15:45:26 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:45:26 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs
In-Reply-To: <NASa8-pJ5Pifxndg4H5qi3ic16xPJMkKR7sPQiJ_CrM=.4e6c2c38-c3cc-4aae-b164-e2af5d27793b@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
 <NASa8-pJ5Pifxndg4H5qi3ic16xPJMkKR7sPQiJ_CrM=.4e6c2c38-c3cc-4aae-b164-e2af5d27793b@github.com>
Message-ID: <F-_s6ZoPCNlmoFEZf-3XZReQqSLpmxnSetG6yTTFAEM=.132c7b37-eed9-42bc-acce-a59a9e369952@github.com>

On Thu, 24 Jul 2025 07:16:25 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for the ping. I performed tier1 test and I see the result is clean with the latest version on linux-riscv64.

@RealFYang thank you for testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3113964641

From adinn at openjdk.org  Thu Jul 24 15:45:26 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 24 Jul 2025 15:45:26 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v3]
In-Reply-To: <4ME73Xqjc4FYKFsOxK0n1JViBulhj9-_ukphppVCHyw=.764525b8-c965-4522-a0c5-c70422f060b0@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <oKQRuymqbZ7-VOfcA4h9wPAqUQuTr75DypnXA6jW7oo=.69699d6a-6fec-42ae-ac61-51529f3aeb71@github.com>
 <VB-OvdXTwnjn5U5uyzTGecPdP9yJkXobO9o6cZPUaaA=.15c05099-1ee9-4f2c-9df8-aaf99521a16f@github.com>
 <4ME73Xqjc4FYKFsOxK0n1JViBulhj9-_ukphppVCHyw=.764525b8-c965-4522-a0c5-c70422f060b0@github.com>
Message-ID: <5SqARIslbcf1EcbYwT4xJA9pOdLk-mDJ5pB1b-7yDeY=.bc52ba77-0a64-426b-b260-a368ba559c0e@github.com>

On Thu, 24 Jul 2025 15:04:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/zero/stubDeclarations_zero.hpp line 40:
>> 
>>> 38:                                       do_arch_entry,                    \
>>> 39:                                       do_arch_entry_init)               \
>>> 40:   do_arch_blob(initial, 32)                                             \
>> 
>> Do we need this any more?
>
> Yes, to call `generate_initial_stubs()` where `_call_stub_entry` is set.

Ah, yes, how annoying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228882777

From kvn at openjdk.org  Thu Jul 24 15:45:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:45:27 GMT
Subject: RFR: 8363837: Move StubRoutines::_crc_table_adr initialization to
 preuniverse stubs [v2]
In-Reply-To: <E0ouDP0GEqicPIHD_cfCTTc9zno_N6K8mz5PibcuvVM=.46ffbffd-5747-4a2a-a0a0-7e78d7396cb1@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
 <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
 <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>
 <E0ouDP0GEqicPIHD_cfCTTc9zno_N6K8mz5PibcuvVM=.46ffbffd-5747-4a2a-a0a0-7e78d7396cb1@github.com>
Message-ID: <0fCXiQSsivc_DMmlKdYXASHyudDNlBW_Wfko9gRxzwI=.1ca9c4fa-d38d-4e38-a1d9-c5a4610a7df9@github.com>

On Thu, 24 Jul 2025 15:31:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Okay, I will add crc32c_table_addr myself then.
>
> I see that crc32c_table_addr() failed on Aarch64 because we should not call it. 
> I will go with your patch @mur47x111 then and let you solve crc32c.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2228881208

From sspitsyn at openjdk.org  Thu Jul 24 15:47:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Jul 2025 15:47:55 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
Message-ID: <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>

On Thu, 24 Jul 2025 12:31:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle.
>> 
>> The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of  vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier.
>
> Note that `java_thread` may already be null so we don't get to execute line 836.

Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228896900

From kvn at openjdk.org  Thu Jul 24 15:52:03 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:52:03 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method
In-Reply-To: <Ks2OWO9686TM_s0uniOz9zFV0Q-6hYYJJScao9gXOWI=.1d57aba4-4c8e-4dbb-b0ce-1693f75d657c@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <H3dzwlcwo9yUFLAl-Z7KuC0ewSV37OZFpPHso1Ucbeg=.74a4386e-f078-4e81-a521-809751e3b26d@github.com>
 <CjPN4gg5SFqXvEQjRU7n31mQ6npVGA8VTz__2y5ecF4=.12d36bbd-26dd-4f55-9de9-a8995715a5cd@github.com>
 <VN-PJMIdzRq9d7KAnTO3BpEw42xLKfdd8EA23qa8K6M=.c693d010-1bcb-4a53-be05-bda990dd4732@github.com>
 <Ks2OWO9686TM_s0uniOz9zFV0Q-6hYYJJScao9gXOWI=.1d57aba4-4c8e-4dbb-b0ce-1693f75d657c@github.com>
Message-ID: <EdK_V1aiO2lxBGGAvKPRGf-Y4Wy3gve2hECHowyHlE8=.2fcd75e5-5885-44f2-910b-b17f9993b79d@github.com>

On Wed, 23 Jul 2025 15:42:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Thank you, @adinn  for you suggestions.
>> 
>>> do we use a different reloc for stubs addresses vs external addresses?
>> 
>> 1. will not work. They could be different. Stubs use `runtime_call` relic and `crc` uses `external_word`.
>> 
>> I considered 2. when I worked on this but there is assumption that we have all external addresses recorded when we look for matching address in `AOTCodeAddressTable::id_for_address()`. There is specific assert there. And we have relocation in all stubs and adapters.  I am concern about some concurrency issues if we don't satisfy the assumption.
>> 
>> An other solution would be to have separate `StubRoutines::get_crc_table_addr()` which can be use early by AOT code and later by `generate_initial_stubs()`. It will check local value (StubRoutines::x86::_crc32c_table on x86, for example) and calculate it if needed. 
>> 
>> What do you think?
>
>> Another solution would be to have separate StubRoutines::get_crc_table_addr() which can be use early by AOT code and later by generate_initial_stubs(). It will check local value (StubRoutines::x86::_crc32c_table on x86, for example) and calculate it if needed.
> 
> Yes, I think it would be much better if we removed the entry declarations for `crc_table_adr` and `crc32c_table_addr` from stubDeclarations.hpp and instead always looked up the address using a getter method declared in the shared header and implemented in each arch.
> 
> We don't need a generated field in class StubRoutines nor any way to track the value as we do for real generated addresses. So, using the declaration mechanism was the wrong way to do this.

Thank you @adinn

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3113986140

From kvn at openjdk.org  Thu Jul 24 15:52:03 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 15:52:03 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method [v5]
In-Reply-To: <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
Message-ID: <pYzGDWtOByGUJneAi955fhceACtZfui_IHlL9vEwTZw=.a8e8fe2e-e5da-42f7-97b2-7f9530689f11@github.com>

On Thu, 24 Jul 2025 15:45:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI fix

I updated title to reflect current implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3113984526

From shade at openjdk.org  Thu Jul 24 15:56:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 15:56:05 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <WsG_0EqAaV2unkDW6IAzboAqa3QWo9D6BK5ThhVYuao=.140f1282-1cd8-47d8-9698-770be93db74f@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

Thank you all! Here goes the mainline integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26449#issuecomment-3113995634

From shade at openjdk.org  Thu Jul 24 15:56:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 15:56:06 GMT
Subject: Integrated: 8360679: Shenandoah: AOT saved adapter calls into broken
 GC barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <j7JB40RuAazyE0ztfpFE6LTAAJCKmlK6FAyN-pa9LBo=.38f33bca-5c3a-479b-ae15-a90388bf74d7@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

This pull request has now been integrated.

Changeset: 84776309
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8477630970b61e3178abd7ac812ed97e181e2684
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8360679: Shenandoah: AOT saved adapter calls into broken GC barrier stub

Reviewed-by: kvn, adinn, aph

-------------

PR: https://git.openjdk.org/jdk/pull/26449

From shade at openjdk.org  Thu Jul 24 16:02:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 16:02:59 GMT
Subject: RFR: 8360679: Shenandoah: AOT saved adapter calls into broken GC
 barrier stub
In-Reply-To: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
References: <u-ZL4yV0Dis2CuInGaFQMeVJy214clCL6Omb-BPQ1cQ=.f3b99577-c5b8-4e1d-9477-cc50ec65e606@github.com>
Message-ID: <QAiJZoLNxxHWkLQUzCDfwztjWEpJFQscaqO5XMQZoRg=.6d0cff7c-7d68-4c2e-8fab-3eeb8ad4187f@github.com>

On Wed, 23 Jul 2025 18:43:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more analysis. This is AOT-, AArch64-, Shenandoah-specific problem. The fix is simple, the failure is catastrophic, and it is very reproducible. So it makes the issue P2, and would like to get it into JDK 25 under RDP 2 rules.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, mainline, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, mainline, `hotspot_gc_shenandoah` (still passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, JDK 25, `hotspot_gc_shenandoah` (still passes)

JDK 25 backport: https://github.com/openjdk/jdk/pull/26464

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26449#issuecomment-3114016037

From shade at openjdk.org  Thu Jul 24 16:05:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 16:05:44 GMT
Subject: [jdk25] RFR: 8360679: Shenandoah: AOT saved adapter calls into broken
 GC barrier stub
Message-ID: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>

Backports the AOT- Shenandoah- AArch64- specific bugfix for JDK 25 regression. JDK 25 RDP2 approval is pending.

Additional testing:
 - [x] Linux AArch64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
 - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` (still passes)

-------------

Commit messages:
 - Backport 8477630970b61e3178abd7ac812ed97e181e2684

Changes: https://git.openjdk.org/jdk/pull/26464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360679
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26464/head:pull/26464

PR: https://git.openjdk.org/jdk/pull/26464

From kvn at openjdk.org  Thu Jul 24 16:34:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 16:34:54 GMT
Subject: [jdk25] RFR: 8360679: Shenandoah: AOT saved adapter calls into
 broken GC barrier stub
In-Reply-To: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
References: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
Message-ID: <Fu7MwBqtzKFxPdml7ihkL1LwRa6HS_9MVcJH6sqxEz8=.99493309-2fef-4e17-9a7f-692d45645ceb@github.com>

On Thu, 24 Jul 2025 15:59:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backports the AOT- Shenandoah- AArch64- specific bugfix for JDK 25 regression. JDK 25 RDP2 approval is pending.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` (still passes)

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26464#pullrequestreview-3052387558

From sspitsyn at openjdk.org  Thu Jul 24 17:37:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Jul 2025 17:37:53 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
Message-ID: <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>

On Thu, 24 Jul 2025 15:45:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Note that `java_thread` may already be null so we don't get to execute line 836.
>
> Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can also observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`.

> Note that java_thread may already be null so we don't get to execute line 836.

Right. I guess, this answers my comment about the line 839.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2229142376

From liach at openjdk.org  Thu Jul 24 18:44:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 18:44:18 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v12]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <KBhs1l5ktSApeck6WAzETQZXBwKEGOl6OfxOVgmadzg=.32c6bb61-6835-4be5-9360-cb77f75aea6c@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Restore non-public comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Reviews
 - Documentation
 - Don't fail for patching tests
 - Remove design document from code
 - Some more from reviews
 - Reviewed the diff on github
 - ... and 16 more: https://git.openjdk.org/jdk/compare/84776309...7cb07340

-------------

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=11
  Stats: 453 lines in 38 files changed: 286 ins; 150 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

PR: https://git.openjdk.org/jdk/pull/25922

From dlong at openjdk.org  Thu Jul 24 18:51:22 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 18:51:22 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64 [v2]
In-Reply-To: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
Message-ID: <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>

> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  remove NMethodEntryBarrier_lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26399/files
  - new: https://git.openjdk.org/jdk/pull/26399/files/ecc6e68e..e05605eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26399&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26399/head:pull/26399

PR: https://git.openjdk.org/jdk/pull/26399

From ayang at openjdk.org  Thu Jul 24 19:05:29 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 24 Jul 2025 19:05:29 GMT
Subject: RFR: 8364082:
 jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java Eden should be
 placed first in young
Message-ID: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>

Update the test to reflect the new young-gen layout `from/to, eden` after [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).

-------------

Commit messages:
 - pgc-fix-young-order

Changes: https://git.openjdk.org/jdk/pull/26466/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26466&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364082
  Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26466/head:pull/26466

PR: https://git.openjdk.org/jdk/pull/26466

From dlong at openjdk.org  Thu Jul 24 19:05:55 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 19:05:55 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
 <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>
Message-ID: <zhsVj2bFJUQKJE5H8BCEYpAxZFz0zWFAboMFELJmLjM=.2e0d60c7-aa63-4d51-b6a5-7aa9abfc5583@github.com>

On Thu, 24 Jul 2025 08:07:42 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix optimized build
>
> src/hotspot/share/runtime/deoptimization.cpp line 847:
> 
>> 845: 
>> 846: #ifndef PRODUCT
>> 847: #ifdef ASSERT
> 
> Why is both `NOT_PRODUCT` and `ASSERT` needed here? So far, I thought that `ASSERT` implies `NOT_PRODUCT`.

Unfortunately, they are not the same, thanks to "optimized" builds.  We can clean this up if optimizes builds get removed.  See https://bugs.openjdk.org/browse/JDK-8183287.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2229334193

From dlong at openjdk.org  Thu Jul 24 19:14:11 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 19:14:11 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v3]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <zP3aO4h_MDCFRpcrdm2JNr8-w35k0Mh-8zOTvSvxDGw=.43b1d175-a1e0-4d68-88ed-cf324791f40c@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/deoptimization.cpp
  
  Co-authored-by: Manuel H?ssig <manuel at haessig.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/5b7d4bca..6042a475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From dlong at openjdk.org  Thu Jul 24 19:25:42 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 19:25:42 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v4]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <LY6mZq7m7rc3TA6PXrSoOR4-yk-2lDA2ytJVMjKCa4g=.8e1321d8-ad69-4651-b618-f524b6346e1a@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  better name for frame index

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/6042a475..c93ca9e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=02-03

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From dlong at openjdk.org  Thu Jul 24 19:34:15 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 19:34:15 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v5]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <pjrkypJcs8Aw1QMjtUH15KZ0-7NNVlHB2rTXyiVnnxU=.d6d5e3b7-8715-41cc-a69d-2563eb6ebb05@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/runtime/vframeArray.cpp
   
   Co-authored-by: Manuel H?ssig <manuel at haessig.org>
 - Update src/hotspot/share/runtime/vframeArray.cpp
   
   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/c93ca9e1..54919be0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From dlong at openjdk.org  Thu Jul 24 19:38:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 19:38:43 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v6]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <uFPS_NKq0rXlsD0S2RjemiO31kmkeAL6jfx_gQUJiLo=.f8e6f0a6-90a4-4d63-b916-fdb652288c60@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  reviewer suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/54919be0..1e46cce1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=04-05

  Stats: 8 lines in 2 files changed: 3 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From yzheng at openjdk.org  Thu Jul 24 19:39:58 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 24 Jul 2025 19:39:58 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method [v2]
In-Reply-To: <0fCXiQSsivc_DMmlKdYXASHyudDNlBW_Wfko9gRxzwI=.1ca9c4fa-d38d-4e38-a1d9-c5a4610a7df9@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
 <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
 <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>
 <E0ouDP0GEqicPIHD_cfCTTc9zno_N6K8mz5PibcuvVM=.46ffbffd-5747-4a2a-a0a0-7e78d7396cb1@github.com>
 <0fCXiQSsivc_DMmlKdYXASHyudDNlBW_Wfko9gRxzwI=.1ca9c4fa-d38d-4e38-a1d9-c5a4610a7df9@github.com>
Message-ID: <iB56qSmWvetPxh3ZIY97_PXrH08RpSlmPcykKF9IoIg=.ef47279f-0138-47f6-a278-6aae9c36b380@github.com>

On Thu, 24 Jul 2025 15:38:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I see that crc32c_table_addr() failed on Aarch64 because we should not call it. 
>> I will go with your patch @mur47x111 then and let you solve crc32c.
>
> Done

Thanks! I also ran across the `ShouldNotCallThis` on aarch64 and decided to drop that because anyway we don't use `crc32c_table_addr`. I think `crc32c_table_addr` is only used internally in HotSpot but not via intrinsification call. Let's only export `crc_table_addr` for now. I will examine the `crc32c_table_addr` later

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2229418122

From kvn at openjdk.org  Thu Jul 24 19:57:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Jul 2025 19:57:59 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method [v2]
In-Reply-To: <iB56qSmWvetPxh3ZIY97_PXrH08RpSlmPcykKF9IoIg=.ef47279f-0138-47f6-a278-6aae9c36b380@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <YeElo15IM4psoXwzVF9fD3N2XF8DgdDyhrUslqfs6Pw=.f70c8e79-7772-4ef4-9e4b-8baaa9ede45c@github.com>
 <I2CrdCTCnPev1ihUxUDgzg4wiAUZxhRNsDEnIoGZQRg=.5e51720a-1dc9-4e1a-bdb7-1d5662eaa86a@github.com>
 <kdYlEnmzp9ng0dQp2bDTJ2tKnG9fTq4zw24r6hDD6po=.2b120837-4bf8-4b52-adf5-3e3799a9e25a@github.com>
 <13d4kwnP300UqJmQOGcEBZ41O58rfPVvzHao-jMvt78=.1ebb29cf-4bf5-4ac4-aea4-6e35a22bf7b3@github.com>
 <bQ-5BzJ7XbFXpkgWm6VxSeOuzdIB7WO3xMPQ22sNsFs=.e459f324-6497-460c-ae6c-b63aa418ccab@github.com>
 <E0ouDP0GEqicPIHD_cfCTTc9zno_N6K8mz5PibcuvVM=.46ffbffd-5747-4a2a-a0a0-7e78d7396cb1@github.com>
 <0fCXiQSsivc_DMmlKdYXASHyudDNlBW_Wfko9gRxzwI=.1ca9c4fa-d38d-4e38-a1d9-c5a4610a7df9@github.com>
 <iB56qSmWvetPxh3ZIY97_PXrH08RpSlmPcykKF9IoIg=.ef47279f-0138-47f6-a278-6aae9c36b380@github.com>
Message-ID: <DDgvXe1g31TAD2DkJ93Vmxtr1N0oFy67dPLtIYHni1I=.ad0f0ef4-038e-43b8-bbee-365dcf4b371e@github.com>

On Thu, 24 Jul 2025 19:37:12 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Done
>
> Thanks! I also ran across the `ShouldNotCallThis` on aarch64 and decided to drop that because anyway we don't use `crc32c_table_addr`. I think `crc32c_table_addr` is only used internally in HotSpot but not via intrinsification call. Let's only export `crc_table_addr` for now. I will examine the `crc32c_table_addr` later

Thank you, @mur47x111

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26434#discussion_r2229451275

From dlong at openjdk.org  Thu Jul 24 20:03:33 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Jul 2025 20:03:33 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  readability suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/1e46cce1..535fbb05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=05-06

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From asmehra at openjdk.org  Thu Jul 24 20:30:58 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 24 Jul 2025 20:30:58 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
Message-ID: <EttDXvw7DVSYsVYY1md6rx5W-eGJnnJjvrPru8xZWnY=.0fb9d4ff-66ff-4d41-943d-908749395173@github.com>

On Wed, 16 Jul 2025 14:01:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulness:
>> 
>> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
>> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if it's 0, we'd assert, if garbage, the resulting Klass* would be garbage.
>> - In print_failure, we now check pointers for readability before handing them to print_obj
>> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
>> - In print_obj, we print a small hex dump of the header (32bytes). With little cost, we get a glance at the raw header and the first members.
>> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
>> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
>> 
>> Tests: I manually tested the patch with several manually broken oops of various flavours. 
>> 
>> Example output, invalid forwardee:
>> 
>> 
>> Referenced from:
>>   no interior location recorded (probably a plain heap scan, or detached oop)
>> 
>> Object:
>>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
>> 
>>         allocated after mark start
>>         after update watermark
>>         marked strong
>>         marked weak
>>     not in collection set
>>     mark:  marked(0xdeaddeaddeaddeaf)
>>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
>> 
>>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
>> 
>> Forwardee:
>>   0xdeaddeaddeaddeac - safe print, no details
>
> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>  - small revert
>  - cosmetics
>  - wip
>  - wip
>  - wip
>  - wip
>  - assert_correct

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 63:

> 61:   ResourceMark rm;
> 62:   stringStream ss;
> 63:   StreamIndentor si(&ss);

This seems redundant.

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 140:

> 138: 
> 139:   if (!os::is_readable_pointer(obj)) {
> 140:     level = _safe_unknown;

Correct me if I am wrong - shouldn't the caller be responsible for passing correct `level` to `print_failure`? If the caller passes a potentially invalid obj with level = _unsafe_oop then the caller should be updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2229509058
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2229508942

From dholmes at openjdk.org  Thu Jul 24 20:37:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 20:37:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
Message-ID: <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>

On Thu, 24 Jul 2025 17:35:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can also observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`.
>
>> Note that java_thread may already be null so we don't get to execute line 836.
> 
> Right. I guess, this answers my comment about the line 839.

Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2229522833

From eastigeevich at openjdk.org  Thu Jul 24 21:44:54 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 24 Jul 2025 21:44:54 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
Message-ID: <G9x9OSfVm6Scn7iFRilN9EvcZzQ2vobLbgBaJwEM6r0=.2efe2ae1-f7b3-41bf-aad8-7b64cdf7d5ba@github.com>

On Wed, 2 Jul 2025 15:56:28 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 incrementally with two additional commits since the last revision:
> 
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables

src/hotspot/share/asm/codeBuffer.hpp line 550:

> 548:   typedef Pair<TrampolineCallKind, address> SharedTrampolineRequestKey;
> 549:   typedef ResizeableResourceHashtable<SharedTrampolineRequestKey, Offsets, AnyObj::C_HEAP,
> 550:                                       mtCompiler>

You can keep using `address` as a key. I don't think `ciMethod*` can be a runtime call target. If we keep using `address` as a key we don't need to define a hash function. 
A type of a call can be stored as data with offset.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2229643477

From jiangli at openjdk.org  Thu Jul 24 22:31:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Jul 2025 22:31:00 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions
In-Reply-To: <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
Message-ID: <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>

On Thu, 24 Jul 2025 09:30:45 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>> 
>> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.
>
> src/hotspot/share/runtime/stubRoutines.cpp line 170:
> 
>> 168:   // When new stubs added we need to make sure there is some space left
>> 169:   // to catch situation when we should increase size again.
>> 170:   assert(code_size == 0 || buffer.insts_remaining() > 200, "increase %s", assert_msg);
> 
> What is the reason to move the assert?

@eastig Thanks for taking a look!

The log `Info, stubs` output provides useful details. With the assertion failure, it wouldn't show. That's why moving the assert to after the log output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2229710100

From kbarrett at openjdk.org  Thu Jul 24 22:59:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 24 Jul 2025 22:59:12 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v4]
In-Reply-To: <w8OQ8DPWs-hO-hhR01bpMMFFw4yqiR2WKC80v-S9r8E=.03f4bf6c-a578-4ee3-a8bd-53b536f1e73d@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <w8OQ8DPWs-hO-hhR01bpMMFFw4yqiR2WKC80v-S9r8E=.03f4bf6c-a578-4ee3-a8bd-53b536f1e73d@github.com>
Message-ID: <m7QxLXxg9eI2Ib8FPKNgMeAOIuxCS_Hv9u86K2SutqE=.9957cc67-ac61-4342-adc5-4bc05a319019@github.com>

On Thu, 24 Jul 2025 09:43:50 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more sorting

src/hotspot/share/utilities/globalDefinitions.hpp line 29:

> 27: 
> 28: // Get constants like JVM_T_CHAR and JVM_SIGNATURE_INT, before pulling in <jvm.h>.
> 29: #include "classfile_constants.h"

This include may no longer be needed, since `jvm.h` includes `jvm_constants.h`, which
includes `classfile_constants.h`. (As it should. Presumably it didn't used to and there was
an include-order problem as a result.) But that doesn't need to be addressed in this PR.
It can be dealt with in a new followup issue, and just stick to the sorting problems here.
https://bugs.openjdk.org/browse/JDK-8364087

src/hotspot/share/utilities/vmError.cpp line 41:

> 39: #if INCLUDE_JVMCI
> 40: #include "jvmci/jvmci.hpp"
> 41: #endif

These changes shouldn't be made.  Conditional includes go at the end.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2229575525
PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2229739204

From kbarrett at openjdk.org  Thu Jul 24 22:59:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 24 Jul 2025 22:59:10 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v6]
In-Reply-To: <4jrmskHlTlvLeMt0Cp3Ap2sZZxcjv3PPi1nzgwEXwyU=.37757695-6bf9-426f-81f7-503ba79b9bf5@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <4jrmskHlTlvLeMt0Cp3Ap2sZZxcjv3PPi1nzgwEXwyU=.37757695-6bf9-426f-81f7-503ba79b9bf5@github.com>
Message-ID: <2Vkn8zEy4XJkocJ1C9zgwhAxw8697FG_tFOcgthypt0=.7cefe526-4932-4637-a86b-d8753094f632@github.com>

On Thu, 24 Jul 2025 10:57:36 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nn

Changes requested by kbarrett (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26428#pullrequestreview-3053311306

From dholmes at openjdk.org  Thu Jul 24 23:59:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Jul 2025 23:59:54 GMT
Subject: RFR: 8364004: Add an option for delayed crash tests
In-Reply-To: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>
References: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>
Message-ID: <gvbSbdNOAj_xyn7r-1syWdaSvHfD-pd-LixRw1BXGNc=.39a5bfcc-d2e9-4ebb-af4b-a1c6691f49ba@github.com>

On Thu, 24 Jul 2025 08:02:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Pretty simple small addition to make `-XX:ErrorHandlerTest` work with an optional delay. This is a preparatory patch for some future planned refinements/additions to the error handler tests. It makes it possible to let the JVM warm up for a second or three, then to crash, in order to then observe an error log from a warmed-up JVM.

Not sure I see the point of this being in the VM. First you are now going to trigger crashes in the WatcherThread instead of the main thread - not sure if that changes what you want to see. Second seems easier to just have a WhiteBox test that triggers different kinds of crashes after initialization.

If you want to trigger crashes at arbitrary times during initialization then I have no doubt you will find issues with crash reporting and it will be totally timing related and would make the test quite unstable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26453#pullrequestreview-3053672357

From ysuenaga at openjdk.org  Fri Jul 25 00:59:00 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 00:59:00 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
Message-ID: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>

JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.

I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.

So I propose again to emit the events from LeakProfiler when OOM happened.
This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))

Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

-------------

Commit messages:
 - 8364090: Dump JFR recording on CrashOnOutOfMemoryError

Changes: https://git.openjdk.org/jdk/pull/26468/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364090
  Stats: 17 lines in 6 files changed: 2 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From david.holmes at oracle.com  Fri Jul 25 01:54:49 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 25 Jul 2025 11:54:49 +1000
Subject: RFC: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
Message-ID: <281f2b83-30ad-46c2-9a5b-c445d57d3784@oracle.com>

This is a proposal to standardize on the use of os::snprintf and 
os::snprintf_checked across the hotspot code base, and to disallow use 
of the C library variants. (It does not touch use of jio_printf at all.)

From: https://bugs.openjdk.org/browse/JDK-8347707

The platform `snprintf/vsnprintf` returns -1 on error, else if the 
buffer is large enough returns the number of bytes written (excluding 
the null byte), else (buffer is too small) the number of characters 
(excluding the terminating null byte) which would have been written to 
the final string if enough space had been available. Thus, a return 
value of size or more means that the output was truncated.

To provide a consistent approach to error handling and truncation 
management, we provide `os::xxx` wrapper functions as described below 
and forbid the use of the library `::vsnprintf` and `::snprintf`.

The potential errors are, generally speaking, not something we should 
encounter in our own well-written code:

- encoding error: not applicable as we are not using extended character sets
- invalid parameters (null buffers, specifying a limit > size of the 
buffer [Windows], things of this nature)
- mal-formed formatting directives
- overflow error (POSIX) if the required buffer size exceeds INT_MAX (as 
we return `int`).

As these should simply never occur, we handle the checks for -1 at the 
lowest-level (`os::vsnprintf`) with an assertion, and accompanying 
precondition assertions.

The potential clients of this API then fall into a number of camps:

1. Those who have sized their buffer correctly, don't need the return 
value for subsequent use, and for whom truncation (if it were possible) 
would be a programming error.

For these clients we have `void os::snprintf_checked` - which returns 
nothing and asserts on truncation.

2. Those who have sized their buffer correctly, but do need the return 
value for subsequent operations (e.g. chains of `snprintf` where you 
advance the buffer pointer based on previous writes), but again for whom 
truncation should never happen.

For these clients we have `os::snprintf`, but they have to add their own 
assertion for no truncation.

3. Those who present a buffer but know that truncation is a possibility, 
but don't need to do anything about it themselves, and for whom the 
return value is of no use.

These clients also use `os::snprintf_checked`. The truncation assertion 
can be useful for guiding buffer sizing decisions, but in product mode 
truncation is not an error.

4. Those who present a buffer but know that truncation is a possibility, 
and either need to handle it themselves, or else need to use the return 
value in subsequent operations.

These clients are also directed to use `os::snprintf`.

In summary we provide the following API:
- `[[nodiscard]] int os::vsnprintf` is the building block for the other 
methods, it:
   - asserts on precondition failures
   - asserts on error
   - guarantees null-termination in the case of unexpected errors (as 
the standards are still unclear on that point
   - is declared `[[nodiscard[]]` so that callers cannot ignore the 
return value (they can explicitly cast to `void` to indicate they dn't 
need it)
- `void os::snprintf_checked`
   - calls `os::vnsprintf`` so asserts on errors
   - asserts on truncation
- [[nodiscard]] int os::snprintf
   - calls `os::vnsprintf`` so asserts on errors

In terms of the effects on the existing code we:
- Change callers of `::snprintf`/`os::snprintf` that ignore the return 
value and ensure the buffer is large enough to use `os::snprintf_checked`
   - those that allow truncation to happen must use `os::snprintf`.
- Change all callers of `::snprintf`/`os::snprintf` that use the return 
value to use `os::snprintf`, plus any additional assertions needed
- Change the 9 callers of `os::snprintf_checked` that do use the return 
value, to use `os::snprintf` with their own assertions added
- Callers of `os::vnsprintf` are adjusted as needed

There is a draft PR comprising of multiple dependent commits so that you 
can view things in stages. There has been a suggestion to integrate this 
in a staged way under different JBS issues to make reviewing easier. 
There are 46 modified files. The bulk of changes replace calls to 
snprintf/os::snprintf with calls to os::snprintf_checked.

https://github.com/openjdk/jdk/pull/26470

Comments welcomed.

Thanks,
David


From kim.barrett at oracle.com  Fri Jul 25 03:02:37 2025
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 24 Jul 2025 23:02:37 -0400
Subject: RFC: 8347707: Standardise the use of os::snprintf and
 os::snprintf_checked
In-Reply-To: <281f2b83-30ad-46c2-9a5b-c445d57d3784@oracle.com>
References: <281f2b83-30ad-46c2-9a5b-c445d57d3784@oracle.com>
Message-ID: <d3fec6ec-46a9-43d5-a9cd-5d94d2e68a87@oracle.com>

On 7/24/25 9:54 PM, David Holmes wrote:
> This is a proposal to standardize on the use of os::snprintf and os::snprintf_checked across the hotspot code base, and to disallow use of the C library variants. (It does not touch use of jio_printf at all.)
> 
> From: https://bugs.openjdk.org/browse/JDK-8347707
> 
> [...]
> 
> https://github.com/openjdk/jdk/pull/26470
> 
> Comments welcomed.

I approve of this plan.

(This plan is the result of extensive discussions between David and I,
so it would be very surprising to David if I didn't approve.)


From dholmes at openjdk.org  Fri Jul 25 04:29:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 04:29:57 GMT
Subject: RFR: 8364082:
 jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java Eden should be
 placed first in young
In-Reply-To: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
References: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
Message-ID: <bVNxJ6c_9UYti7ByZCoqX87P43EeY-R9Zs9gQjCqmfk=.9bc06862-ed60-4305-8dfd-41f3c3ba6e83@github.com>

On Thu, 24 Jul 2025 18:59:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Update the test to reflect the new young-gen layout `from/to, eden` after [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).

Works for me!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26466#pullrequestreview-3054044874

From stuefe at openjdk.org  Fri Jul 25 05:04:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 05:04:55 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <EttDXvw7DVSYsVYY1md6rx5W-eGJnnJjvrPru8xZWnY=.0fb9d4ff-66ff-4d41-943d-908749395173@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <EttDXvw7DVSYsVYY1md6rx5W-eGJnnJjvrPru8xZWnY=.0fb9d4ff-66ff-4d41-943d-908749395173@github.com>
Message-ID: <6n662nJ03wSS4W7q-qi5L3FkSmlEA1bI07Sx7tW4QPk=.4faae02c-2e36-48fa-84ec-4076cda1cea6@github.com>

On Thu, 24 Jul 2025 20:27:52 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>>  - small revert
>>  - cosmetics
>>  - wip
>>  - wip
>>  - wip
>>  - wip
>>  - assert_correct
>
> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 63:
> 
>> 61:   ResourceMark rm;
>> 62:   stringStream ss;
>> 63:   StreamIndentor si(&ss);
> 
> This seems redundant.

Why?

StreamIndentor indents the future output of the associated stream. We place them wherever we need indentation. We want indentation here - that avoids having to write out manual indentation like the code before did.

> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 140:
> 
>> 138: 
>> 139:   if (!os::is_readable_pointer(obj)) {
>> 140:     level = _safe_unknown;
> 
> Correct me if I am wrong - shouldn't the caller be responsible for passing correct `level` to `print_failure`? If the caller passes a potentially invalid obj with, say level = _safe_oop, then the caller should be updated.

The caller may have erred. Seeing how many callers there are, there are many places that can bitrot. This is just an added safety feature.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2230143357
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2230140139

From dholmes at openjdk.org  Fri Jul 25 05:35:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 05:35:05 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v4]
In-Reply-To: <m7QxLXxg9eI2Ib8FPKNgMeAOIuxCS_Hv9u86K2SutqE=.9957cc67-ac61-4342-adc5-4bc05a319019@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <w8OQ8DPWs-hO-hhR01bpMMFFw4yqiR2WKC80v-S9r8E=.03f4bf6c-a578-4ee3-a8bd-53b536f1e73d@github.com>
 <m7QxLXxg9eI2Ib8FPKNgMeAOIuxCS_Hv9u86K2SutqE=.9957cc67-ac61-4342-adc5-4bc05a319019@github.com>
Message-ID: <1cWba1LYlyl5o5JFisyhbAFHaeop4hrlBG67C3JBGss=.0257e58f-899a-47a3-bd1d-64b97fc8183c@github.com>

On Thu, 24 Jul 2025 21:06:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more sorting
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 29:
> 
>> 27: 
>> 28: // Get constants like JVM_T_CHAR and JVM_SIGNATURE_INT, before pulling in <jvm.h>.
>> 29: #include "classfile_constants.h"
> 
> This include may no longer be needed, since `jvm.h` includes `jvm_constants.h`, which
> includes `classfile_constants.h`. (As it should. Presumably it didn't used to and there was
> an include-order problem as a result.) But that doesn't need to be addressed in this PR.
> It can be dealt with in a new followup issue, and just stick to the sorting problems here.
> https://bugs.openjdk.org/browse/JDK-8364087

I don't know what the comment is referring to as this file doesn't include jvm.h, but it does need the constants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2230186490

From sspitsyn at openjdk.org  Fri Jul 25 06:24:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 25 Jul 2025 06:24:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <dTvBRWZroXI46qPs-kJjEjon4C8EorDBu9ZGdCa8wKw=.a75ba7ae-eb10-4e27-a580-3e469dd1cd29@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

This looks okay to me.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3054238698

From sspitsyn at openjdk.org  Fri Jul 25 06:24:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 25 Jul 2025 06:24:55 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
 <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
Message-ID: <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>

On Thu, 24 Jul 2025 20:35:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Note that java_thread may already be null so we don't get to execute line 836.
>> 
>> Right. I guess, this answers my comment about the line 839.
>
> Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it.

Okay, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2230252813

From dholmes at openjdk.org  Fri Jul 25 06:41:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Jul 2025 06:41:56 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <dTvBRWZroXI46qPs-kJjEjon4C8EorDBu9ZGdCa8wKw=.a75ba7ae-eb10-4e27-a580-3e469dd1cd29@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <dTvBRWZroXI46qPs-kJjEjon4C8EorDBu9ZGdCa8wKw=.a75ba7ae-eb10-4e27-a580-3e469dd1cd29@github.com>
Message-ID: <ynxOq0YuyqkRcS_mEsNngtESiTN6qmF2sPQFDGDTsBM=.8e1980e7-5b65-49d8-b028-22815f384e92@github.com>

On Fri, 25 Jul 2025 06:21:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> This looks okay to me.

Thanks for the review @sspitsyn !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3116587591

From alanb at openjdk.org  Fri Jul 25 07:08:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 07:08:55 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
 <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
 <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>
Message-ID: <lGDHJ2RP6K7L_Gi0w5VbWE4R8dwBeNjBNkBlAGrgaBU=.3ab6b3cb-8a11-4eea-90a4-1d72d487850d@github.com>

On Fri, 25 Jul 2025 06:21:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it.
>
> Okay, thanks.

Once this change is in main line then we can sync'up the loom repo and work on the follow-up changes. The loom repo has changes (that are not in main line) for "suspending" an unmounted thread. For the mounted case then we'll need checks in the handshake to ensure that the expected virtual threads is mounted. We'll need stress tests of course and we can collaborate there in advance of proposing changes for main line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2230330528

From ayang at openjdk.org  Fri Jul 25 07:24:59 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 25 Jul 2025 07:24:59 GMT
Subject: RFR: 8364082:
 jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java Eden should be
 placed first in young
In-Reply-To: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
References: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
Message-ID: <LKjpIwpenrIAQmiCRsUmgr4-aiSQcdUwofxCwxbPeyk=.240d4492-693d-4a7f-88c3-98a9a65b25cc@github.com>

On Thu, 24 Jul 2025 18:59:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Update the test to reflect the new young-gen layout `from/to, eden` after [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).

Thanks for review. Merging now to reduce CI noise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26466#issuecomment-3116708614

From ayang at openjdk.org  Fri Jul 25 07:25:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 25 Jul 2025 07:25:00 GMT
Subject: Integrated: 8364082:
 jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java Eden should be
 placed first in young
In-Reply-To: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
References: <g7vF4Lg7hW5_kuYgBEI3DvBcHrrrXNR9LOqNLjuf-bI=.b5cc1e01-60f4-4bf0-baeb-10211a300bd9@github.com>
Message-ID: <a9NK6ZYG5EbH0dZBhxRSnIrDRFjQDnXUQKaEDc0RPEc=.c4fb9760-fc09-48c7-bd86-e7f7a0e78008@github.com>

On Thu, 24 Jul 2025 18:59:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Update the test to reflect the new young-gen layout `from/to, eden` after [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).

This pull request has now been integrated.

Changeset: 52155dbb
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52155dbbb0107c5077a6be7edfd91d4311411fc3
Stats:     9 lines in 1 file changed: 1 ins; 1 del; 7 mod

8364082: jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java Eden should be placed first in young

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26466

From stuefe at openjdk.org  Fri Jul 25 07:32:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 07:32:00 GMT
Subject: RFR: 8364004: Add an option for delayed crash tests
In-Reply-To: <gvbSbdNOAj_xyn7r-1syWdaSvHfD-pd-LixRw1BXGNc=.39a5bfcc-d2e9-4ebb-af4b-a1c6691f49ba@github.com>
References: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>
 <gvbSbdNOAj_xyn7r-1syWdaSvHfD-pd-LixRw1BXGNc=.39a5bfcc-d2e9-4ebb-af4b-a1c6691f49ba@github.com>
Message-ID: <mx1Qp9Ki0zWf6bBbHGmbPy5xePQkXtxU_0z_eAzRvEQ=.eecccbf0-a07c-4137-8a61-95d08c6edebd@github.com>

On Thu, 24 Jul 2025 23:56:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Pretty simple small addition to make `-XX:ErrorHandlerTest` work with an optional delay. This is a preparatory patch for some future planned refinements/additions to the error handler tests. It makes it possible to let the JVM warm up for a second or three, then to crash, in order to then observe an error log from a warmed-up JVM.
>
> Not sure I see the point of this being in the VM. First you are now going to trigger crashes in the WatcherThread instead of the main thread - not sure if that changes what you want to see. Second seems easier to just have a WhiteBox test that triggers different kinds of crashes after initialization.
> 
> If you want to trigger crashes at arbitrary times during initialization then I have no doubt you will find issues with crash reporting and it will be totally timing related and would make the test quite unstable.

@dholmes-ora You are right. I am closing this one in favor of the approach you suggested in JBS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26453#issuecomment-3116728169

From stuefe at openjdk.org  Fri Jul 25 07:32:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 07:32:00 GMT
Subject: Withdrawn: 8364004: Add an option for delayed crash tests
In-Reply-To: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>
References: <kFSRJ_2j9rOeHOraYTzFLPqJMGPiGeWbNUoRnPDpP-I=.9af24a62-108e-4ebf-ba04-6a8ec626631b@github.com>
Message-ID: <Aqgr2oMgNCgeyKx92UYVCBhFYhBc6c8nmG-N983Bj6s=.c44d3858-c516-44f9-83f4-a1168e4e633e@github.com>

On Thu, 24 Jul 2025 08:02:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Pretty simple small addition to make `-XX:ErrorHandlerTest` work with an optional delay. This is a preparatory patch for some future planned refinements/additions to the error handler tests. It makes it possible to let the JVM warm up for a second or three, then to crash, in order to then observe an error log from a warmed-up JVM.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26453

From vyazici at openjdk.org  Fri Jul 25 07:40:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 25 Jul 2025 07:40:46 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
> 
> Following preliminary work needs to be carried out as well:
> 
> 1. Add a new `VerifyIntrinsicChecks` VM flag
> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
> 
> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
> 
> ## Functional and performance tests
> 
> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
> 
> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
> 
> ## Verification of the VM crash
> 
> I've tested the VM crash scenario as follows:
> 
> 1. Created the following test program:
> 
> public class StrIntri {
>     public static void main(String[] args) {
>         Exception lastException = null;
>         for (int i = 0; i < 1_000_000; i++) {
>             try {
>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>             } catch (Exception exception) {
>                 lastException = exception;
>             }
>         }
>         if (lastException != null) {
>             lastException.printStackTrace();
>         } else {
>             System.out.println("completed");
>         }
>     }
> }
> ...

Volkan Yazici 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 31 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Replace `requireNonNull` with implicit null checks to reduce bytecode size
 - Add `@bug` tags
 - Improve wording of `@param len`
 - Make source array bound checks lenient too
 - Cap destination array bounds
 - Fix bit shifting
 - Remove superseded `@throws` Javadoc
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Make `StringCoding` encoding intrinsics lenient
 - ... and 21 more: https://git.openjdk.org/jdk/compare/9331736c...c322f0e0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/1d02189f..c322f0e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=11-12

  Stats: 11682 lines in 267 files changed: 4951 ins; 5263 del; 1468 mod
  Patch: https://git.openjdk.org/jdk/pull/25998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998

PR: https://git.openjdk.org/jdk/pull/25998

From egahlin at openjdk.org  Fri Jul 25 07:52:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 07:52:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

src/hotspot/share/runtime/java.cpp line 466:

> 464:   }
> 465: 
> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)

You set oom to true here, why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230419356

From ysuenaga at openjdk.org  Fri Jul 25 08:07:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 08:07:57 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
Message-ID: <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>

On Fri, 25 Jul 2025 07:50:32 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> src/hotspot/share/runtime/java.cpp line 466:
> 
>> 464:   }
>> 465: 
>> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)
> 
> You set oom to true here, why?

To keep current behavior.

Before this change, 1st argument of `on_vm_shutdown` is `exception_handler`. You can see it on this change. If `exception_handler` sets to `false`, emergency dump handles it as OOM:


static void post_events(bool exception_handler, Thread* thread) {
  if (exception_handler) {
    EventShutdown e;
    e.set_reason("VM Error");
    e.commit();
  } else {
    // OOM
    LeakProfiler::emit_events(max_jlong, false, false);
  }
  EventDumpReason event;
  event.set_reason(exception_handler ? "Crash" : "Out of Memory");
  event.set_recordingId(-1);
  event.commit();
}


I'm not sure this code would be called when OOM happens, but I think we need to keep this behavior in this change - this change focuses on working emergency dump with `CrashOnOutOfMemoryError`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230449677

From shade at openjdk.org  Fri Jul 25 08:11:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 08:11:59 GMT
Subject: [jdk25] RFR: 8360679: Shenandoah: AOT saved adapter calls into
 broken GC barrier stub
In-Reply-To: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
References: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
Message-ID: <n2fqXRViep6czL9eRdjos1pJVEZEYmQFPWr4pzhsaug=.1b3eb355-cfff-4ae4-9ac9-0381074c7691@github.com>

On Thu, 24 Jul 2025 15:59:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backports the AOT- Shenandoah- AArch64- specific bugfix for JDK 25 regression. JDK 25 RDP2 approval is pending.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` (still passes)

Thank you! Here goes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26464#issuecomment-3116827003

From shade at openjdk.org  Fri Jul 25 08:12:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 08:12:00 GMT
Subject: [jdk25] Integrated: 8360679: Shenandoah: AOT saved adapter calls into
 broken GC barrier stub
In-Reply-To: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
References: <GWTTTQ4xDGWMGOHURq66mDHClL6A1jlK2bk0U_m-7jw=.634f43f8-dbe2-4efb-aef6-6ea6efcdb5e8@github.com>
Message-ID: <sqhUEh0dC-SwJ3YyXDtjE87dZtUkuT1lCcQRNaOEVo8=.a01aec4b-2407-4627-a3a0-84a18ec54f2f@github.com>

On Thu, 24 Jul 2025 15:59:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Backports the AOT- Shenandoah- AArch64- specific bugfix for JDK 25 regression. JDK 25 RDP2 approval is pending.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC` (now passes)
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah` (still passes)

This pull request has now been integrated.

Changeset: 033a121c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/033a121c9691b57ada832072dceb18a7fa2dcfe8
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8360679: Shenandoah: AOT saved adapter calls into broken GC barrier stub

Reviewed-by: kvn
Backport-of: 8477630970b61e3178abd7ac812ed97e181e2684

-------------

PR: https://git.openjdk.org/jdk/pull/26464

From egahlin at openjdk.org  Fri Jul 25 08:24:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 08:24:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
Message-ID: <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>

On Fri, 25 Jul 2025 08:05:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/runtime/java.cpp line 466:
>> 
>>> 464:   }
>>> 465: 
>>> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)
>> 
>> You set oom to true here, why?
>
> To keep current behavior.
> 
> Before this change, 1st argument of `on_vm_shutdown` is `exception_handler`. You can see it on this change. If `exception_handler` sets to `false`, emergency dump handles it as OOM:
> 
> 
> static void post_events(bool exception_handler, Thread* thread) {
>   if (exception_handler) {
>     EventShutdown e;
>     e.set_reason("VM Error");
>     e.commit();
>   } else {
>     // OOM
>     LeakProfiler::emit_events(max_jlong, false, false);
>   }
>   EventDumpReason event;
>   event.set_reason(exception_handler ? "Crash" : "Out of Memory");
>   event.set_recordingId(-1);
>   event.commit();
> }
> 
> 
> I'm not sure this code would be called when OOM happens, but I think we need to keep this behavior in this change - this change focuses on working emergency dump with `CrashOnOutOfMemoryError`.

Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?

I think the OldObjectSample event should only be emitted if an emergency dump occurs, preferably only on oom.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230486262

From duke at openjdk.org  Fri Jul 25 08:49:11 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 25 Jul 2025 08:49:11 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v7]
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - move up
 - revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26428/files
  - new: https://git.openjdk.org/jdk/pull/26428/files/8ebbfaf6..88b4d4c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26428&range=05-06

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26428/head:pull/26428

PR: https://git.openjdk.org/jdk/pull/26428

From duke at openjdk.org  Fri Jul 25 08:49:12 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 25 Jul 2025 08:49:12 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v4]
In-Reply-To: <m7QxLXxg9eI2Ib8FPKNgMeAOIuxCS_Hv9u86K2SutqE=.9957cc67-ac61-4342-adc5-4bc05a319019@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <w8OQ8DPWs-hO-hhR01bpMMFFw4yqiR2WKC80v-S9r8E=.03f4bf6c-a578-4ee3-a8bd-53b536f1e73d@github.com>
 <m7QxLXxg9eI2Ib8FPKNgMeAOIuxCS_Hv9u86K2SutqE=.9957cc67-ac61-4342-adc5-4bc05a319019@github.com>
Message-ID: <s2Vf-P-TDErlccgwY9dGHgukCcHdrzT1oyTlGHinPpc=.7ab46ad5-6c57-47fa-a201-4453fd4b6831@github.com>

On Thu, 24 Jul 2025 22:55:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more sorting
>
> src/hotspot/share/utilities/vmError.cpp line 41:
> 
>> 39: #if INCLUDE_JVMCI
>> 40: #include "jvmci/jvmci.hpp"
>> 41: #endif
> 
> These changes shouldn't be made.  Conditional includes go at the end.

Noted, reverted in a27bef538f1b5cb3465e247798319a2d4a463102

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26428#discussion_r2230537371

From ysuenaga at openjdk.org  Fri Jul 25 09:09:53 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 09:09:53 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
 <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
Message-ID: <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>

On Fri, 25 Jul 2025 08:21:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?

Ok, I will rename to `emit_old_object_samples`.

> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.

Normally, JFR recording should already be stopped at this point because it is stopped by shutdown hook. So I guess this code (`Jfr::on_vm_shutdown` call at here) rarely works. However it might work if shutdown hook would not work for some reasons - OOM for example.

So should we keep this code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230583197

From aph at openjdk.org  Fri Jul 25 09:20:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 25 Jul 2025 09:20:57 GMT
Subject: RFR: 8359114: [s390x] Add z17 detection code [v2]
In-Reply-To: <_fiM-Nhm3q5S2hCxa3quxpodBRmeIsCIBcA7AB4Hmcc=.2005b23d-fc05-4821-90b4-cf22a8d2442e@github.com>
References: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
 <_fiM-Nhm3q5S2hCxa3quxpodBRmeIsCIBcA7AB4Hmcc=.2005b23d-fc05-4821-90b4-cf22a8d2442e@github.com>
Message-ID: <MH8s-AsuBnyN57pZnQ3QXKMt7Yao7ZQbWz2FLve_6MA=.6e07b003-d6a9-4eda-9176-11331d04501b@github.com>

On Wed, 11 Jun 2025 13:09:45 GMT, Manjunath S Matti. <duke at openjdk.org> wrote:

>> Add support to detect the new generation of Z machine (z17).
>
> Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct the comments for the bits covered in DW[2] and DW[3].

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25718#pullrequestreview-3054715840

From duke at openjdk.org  Fri Jul 25 11:36:36 2025
From: duke at openjdk.org (Manjunath S Matti.)
Date: Fri, 25 Jul 2025 11:36:36 GMT
Subject: RFR: 8359114: [s390x] Add z17 detection code [v3]
In-Reply-To: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
References: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
Message-ID: <e4ILBEcSumoQal6998GXp9WYlRk6JJnBuSXbmeFQZAg=.c2c24997-0c14-4eca-b968-d18c7396b54a@github.com>

> Add support to detect the new generation of Z machine (z17).

Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25718/files
  - new: https://git.openjdk.org/jdk/pull/25718/files/95c2fa9e..f62ef2ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25718&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25718&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25718/head:pull/25718

PR: https://git.openjdk.org/jdk/pull/25718

From shade at openjdk.org  Fri Jul 25 13:00:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 13:00:44 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
Message-ID: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>

See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterator, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CDS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.

So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this to happen again.

Additional testing:
 - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
 - [x] Linux x86_64 server fastdebug, `tier1`
 - [ ] Linux x86_64 server fastdebug, `all`

-------------

Commit messages:
 - Comments
 - Mark as inline as well
 - Fix

Changes: https://git.openjdk.org/jdk/pull/26477/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364111
  Stats: 59 lines in 2 files changed: 27 ins; 30 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26477/head:pull/26477

PR: https://git.openjdk.org/jdk/pull/26477

From asmehra at openjdk.org  Fri Jul 25 13:10:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Jul 2025 13:10:56 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
Message-ID: <jwec1U8jWDKuyZN7YvsHv5eUAhACTlPnIS20F7FUg50=.9e65ce1f-afa0-4a78-bca6-4471b6a43acf@github.com>

On Wed, 16 Jul 2025 14:01:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulness:
>> 
>> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
>> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if it's 0, we'd assert, if garbage, the resulting Klass* would be garbage.
>> - In print_failure, we now check pointers for readability before handing them to print_obj
>> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
>> - In print_obj, we print a small hex dump of the header (32bytes). With little cost, we get a glance at the raw header and the first members.
>> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
>> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
>> 
>> Tests: I manually tested the patch with several manually broken oops of various flavours. 
>> 
>> Example output, invalid forwardee:
>> 
>> 
>> Referenced from:
>>   no interior location recorded (probably a plain heap scan, or detached oop)
>> 
>> Object:
>>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
>> 
>>         allocated after mark start
>>         after update watermark
>>         marked strong
>>         marked weak
>>     not in collection set
>>     mark:  marked(0xdeaddeaddeaddeaf)
>>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
>> 
>>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
>> 
>> Forwardee:
>>   0xdeaddeaddeaddeac - safe print, no details
>
> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>  - small revert
>  - cosmetics
>  - wip
>  - wip
>  - wip
>  - wip
>  - assert_correct

lgtm, thanks for addressing the concerns.

-------------

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26237#pullrequestreview-3055343543

From asmehra at openjdk.org  Fri Jul 25 13:10:57 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Jul 2025 13:10:57 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <6n662nJ03wSS4W7q-qi5L3FkSmlEA1bI07Sx7tW4QPk=.4faae02c-2e36-48fa-84ec-4076cda1cea6@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <EttDXvw7DVSYsVYY1md6rx5W-eGJnnJjvrPru8xZWnY=.0fb9d4ff-66ff-4d41-943d-908749395173@github.com>
 <6n662nJ03wSS4W7q-qi5L3FkSmlEA1bI07Sx7tW4QPk=.4faae02c-2e36-48fa-84ec-4076cda1cea6@github.com>
Message-ID: <QToZ6oWKDs2kx-ep0jRuexQBnWwzNoEKntzo2V2nIqw=.13f7ecd6-cc4a-4245-ba03-24d4c354b679@github.com>

On Fri, 25 Jul 2025 05:01:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 63:
>> 
>>> 61:   ResourceMark rm;
>>> 62:   stringStream ss;
>>> 63:   StreamIndentor si(&ss);
>> 
>> This seems redundant.
>
> Why?
> 
> StreamIndentor indents the future output of the associated stream. We place them wherever we need indentation. We want indentation here - that avoids having to write out manual indentation like the code before did.

right, I missed the print statement at line 74.

>> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 140:
>> 
>>> 138: 
>>> 139:   if (!os::is_readable_pointer(obj)) {
>>> 140:     level = _safe_unknown;
>> 
>> Correct me if I am wrong - shouldn't the caller be responsible for passing correct `level` to `print_failure`? If the caller passes a potentially invalid obj with, say level = _safe_oop, then the caller should be updated.
>
> The caller may have erred. Seeing how many callers there are, there are many places that can bitrot. This is just an added safety feature.

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2231040821
PR Review Comment: https://git.openjdk.org/jdk/pull/26237#discussion_r2231041847

From stuefe at openjdk.org  Fri Jul 25 13:37:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 13:37:03 GMT
Subject: RFR: 8361712: Improve ShenandoahAsserts printing [v2]
In-Reply-To: <jwec1U8jWDKuyZN7YvsHv5eUAhACTlPnIS20F7FUg50=.9e65ce1f-afa0-4a78-bca6-4471b6a43acf@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
 <oKOMSiAuQzLGavVWDktgcXhExBrEcWnpc7j93jilYOQ=.68f03255-708d-4b1f-81d3-2403c6a9dfbb@github.com>
 <jwec1U8jWDKuyZN7YvsHv5eUAhACTlPnIS20F7FUg50=.9e65ce1f-afa0-4a78-bca6-4471b6a43acf@github.com>
Message-ID: <Yyw4WgiXCvCYvOc6fBZ0cjOSXmBcnOC_UhzJWUjxmKQ=.c7b3f200-400c-476a-accf-f92d3dc600b9@github.com>

On Fri, 25 Jul 2025 13:07:48 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Thomas Stuefe 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 branch 'openjdk:master' into harden-shenandoah-asserts
>>  - small revert
>>  - cosmetics
>>  - wip
>>  - wip
>>  - wip
>>  - wip
>>  - assert_correct
>
> lgtm, thanks for addressing the concerns.

Thanks @ashu-mehra and @rkennke !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26237#issuecomment-3117842462

From stuefe at openjdk.org  Fri Jul 25 13:37:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 13:37:03 GMT
Subject: Integrated: 8361712: Improve ShenandoahAsserts printing
In-Reply-To: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
References: <jIejBSoGQNs8cyDNuXaPTs8-l3h1G2TAd0H51jwIUMk=.43d22edb-4a3f-4954-a48c-8b00f1f1cf3a@github.com>
Message-ID: <UupqiCNnkITCAGgl9VHu49hb-tZRejgXmwwTLMyGypg=.c40ffb31-90b0-42d5-8a42-f9662761dd81@github.com>

On Thu, 10 Jul 2025 08:02:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small changes to ShenandoahAsserts and friends to improve fault-tolerance and usefulness:
> 
> - In assert_correct, we now check the forwarding pointer first before extracting the narrowKlass from it. The forwarding pointer may be invalid. To do this, the forwarding-pointer-checking-block was moved up to before Klass* checks. We also use SafeFetch-based checks for some added safety.
> - In assert_correct, we test the narrowKlass before decoding it. Otherwise, if it's 0, we'd assert, if garbage, the resulting Klass* would be garbage.
> - In print_failure, we now check pointers for readability before handing them to print_obj
> - In print_obj, we now print the extracted narrowKlass, too (useful on Lilliput with its terse ids)
> - In print_obj, we print a small hex dump of the header (32bytes). With little cost, we get a glance at the raw header and the first members.
> - In print_obj, we print to a single stringStream now and use auto indentation. Avoids having to deal with indentation and newlines manually and having to pay for four stringStreams.
> - In assert_correct, I raised the print level for some of the klass-related assertions to safe_oop since the oop, since the hardened version of print_obj now avoids tripping over invalid Klass*
> 
> Tests: I manually tested the patch with several manually broken oops of various flavours. 
> 
> Example output, invalid forwardee:
> 
> 
> Referenced from:
>   no interior location recorded (probably a plain heap scan, or detached oop)
> 
> Object:
>   0x00000007cd800000 - nk 1798104 klass 0x00000000921b6fd8 [Ljava.lang.Object;
> 
>         allocated after mark start
>         after update watermark
>         marked strong
>         marked weak
>     not in collection set
>     mark:  marked(0xdeaddeaddeaddeaf)
>     region: | 3812|R  |Y|BTE    7cd800000,    7cd920bf8,    7cdc00000|TAMS    7cd800000|UWM    7cd800000|U  1154K|T     0B|G     0B|S  1154K|L     0B|CP   0
> 
>   0x00000007cd800000:   deaddeaddeaddeaf 00000a96001b6fd8 f9b005cff9b0054d f9b006d3f9b00651   .........o......M.......Q.......
>   0x00000007cd800020:   f9b00797f9b00755 f9b00992f9b0087d f9b009a0f9b00999 f9b009a7f9b0098e   U.......}.......................
> 
> Forwardee:
>   0xdeaddeaddeaddeac - safe print, no details

This pull request has now been integrated.

Changeset: 75ff7e15
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75ff7e15fe0d22149e5b8c5ccf3b702d8dc9b3fa
Stats:     164 lines in 9 files changed: 122 ins; 12 del; 30 mod

8361712: Improve ShenandoahAsserts printing

Reviewed-by: rkennke, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/26237

From jbhateja at openjdk.org  Fri Jul 25 13:50:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 13:50:55 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction
Message-ID: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>

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
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2   9756.573          ops/ms

With opt:
Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2  34122.435          ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  33281.868          ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9345.154          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   8283.247          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   8510.695          ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   5626.367          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    960.958          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   4155.801          ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1465.953          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  32748.061          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  33674.408          ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2   9346.148          ops/ms


Please share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - Fixes for failing regressions
 -  Optimizing AVX2 backend and some re-factoring
 - new benchmark
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8303762
 - 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction

Changes: https://git.openjdk.org/jdk/pull/24104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303762
  Stats: 747 lines in 32 files changed: 664 ins; 0 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From jbhateja at openjdk.org  Fri Jul 25 13:50:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 13:50:56 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <rxrqifXZWTu2RgnGV-1QjP1eenihYP5YAMcu48k6NyQ=.22a486b9-a4de-43df-9b01-f6ef81301d64@github.com>

On Tue, 18 Mar 2025 20:51:46 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
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Performance after AVX2 backend modifications


Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2  51644.530          ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  48171.079          ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9662.306          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2  14358.347          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2  14619.920          ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6675.824          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    818.911          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   4778.321          ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1612.264          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  35961.146          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  39072.170          ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2  11209.685          ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3116214722

From egahlin at openjdk.org  Fri Jul 25 13:59:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 13:59:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
 <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
 <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>
Message-ID: <Yv714ShPV1hJQbSRX0HcdTEXNr7lVFntrxWtBLTzAwQ=.073ef128-c46d-43c3-bd85-3e55b97701d1@github.com>

On Fri, 25 Jul 2025 09:07:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?
>> 
>> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.
>
>> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?
> 
> Ok, I will rename to `emit_old_object_samples`.
> 
>> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.
> 
> Normally, JFR recording should already be stopped at this point because it is stopped by shutdown hook. So I guess this code (`Jfr::on_vm_shutdown` call at here) rarely works. However it might work if shutdown hook would not work for some reasons - OOM for example.
> 
> So should we keep this code?

I think you can keep it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2231156266

From mli at openjdk.org  Fri Jul 25 14:06:03 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 25 Jul 2025 14:06:03 GMT
Subject: RFR: 8364120: RISC-V: unify the usage of
 MacroAssembler::instruction_size
Message-ID: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>

Hi,
Can you help to review this simple cleanup?

in MacroAssembler, some magic number 4 is used for MacroAssembler::instruction_size. We should not use magic number if possible.
This pr also replaces all the usage of  `instruction_size` with `MacroAssembler::instruction_size`.

Thanks

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364120
  Stats: 38 lines in 2 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/26481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26481/head:pull/26481

PR: https://git.openjdk.org/jdk/pull/26481

From eastigeevich at openjdk.org  Fri Jul 25 14:43:55 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 25 Jul 2025 14:43:55 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions
In-Reply-To: <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
 <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>
Message-ID: <ybM-bjo9qQnX_DGK_pLMrLILAnssXHRFksdMgQLL8Yg=.f602990a-6d51-4803-bcd9-4f11b8d1f358@github.com>

On Thu, 24 Jul 2025 22:27:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> src/hotspot/share/runtime/stubRoutines.cpp line 170:
>> 
>>> 168:   // When new stubs added we need to make sure there is some space left
>>> 169:   // to catch situation when we should increase size again.
>>> 170:   assert(code_size == 0 || buffer.insts_remaining() > 200, "increase %s", assert_msg);
>> 
>> What is the reason to move the assert?
>
> @eastig Thanks for taking a look!
> 
> The log `Info, stubs` output provides useful details. With the assertion failure, it wouldn't show. That's why moving the assert to after the log output.

If you need information which is printed out in the log, why not to add needed information to the assert? You can copy the format string used for logging. This will make assert's output more informative without a need for enabling logging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2231292404

From coleenp at openjdk.org  Fri Jul 25 14:58:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Jul 2025 14:58:06 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
Message-ID: <ReqXE895w4ZvQDF2PdS89DTl1WhjFGNFaeZUxD0l16E=.5bf33ee4-2d8d-4908-a247-3db3b49398dd@github.com>

On Fri, 25 Jul 2025 12:01:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
> 
> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

This looks like a good cleanup but need someone who knows GC better to also review.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26477#pullrequestreview-3055775411

From stuefe at openjdk.org  Fri Jul 25 15:36:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 15:36:55 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
Message-ID: <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>

On Fri, 25 Jul 2025 12:01:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
> 
> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux x86_64 server fastdebug, `all`

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 69:

> 67:     // Klass is null means this has been a mirror for a primitive type
> 68:     // that we do not need to follow as they are always strong roots.
> 69:     assert(java_lang_Class::is_primitive(obj), "Sanity");

Question, since this assert is new:

When we create a mirror (`java_lang_Class::allocate_mirror`) during normal - non-shared - class loading, is there not a small time window where the mirror exists on the heap, but the Klass is still NULL? Could concurrent heap walkers not observe that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231435613

From stuefe at openjdk.org  Fri Jul 25 15:46:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 15:46:44 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox
Message-ID: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>

Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

-------------

Commit messages:
 - Update whitebox.cpp
 - JDK-8364004-Expose-VMError-controlledCrash-via-Whitebox

Changes: https://git.openjdk.org/jdk/pull/26472/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364004
  Stats: 29 lines in 3 files changed: 24 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26472/head:pull/26472

PR: https://git.openjdk.org/jdk/pull/26472

From duke at openjdk.org  Fri Jul 25 16:10:32 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 25 Jul 2025 16:10:32 GMT
Subject: RFR: 8364115: Sort share/services includes
Message-ID: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>

This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.

Passes tier1.

-------------

Commit messages:
 - sort includes

Changes: https://git.openjdk.org/jdk/pull/26483/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26483&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364115
  Stats: 43 lines in 12 files changed: 22 ins; 19 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26483/head:pull/26483

PR: https://git.openjdk.org/jdk/pull/26483

From yzheng at openjdk.org  Fri Jul 25 16:15:00 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 25 Jul 2025 16:15:00 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method [v5]
In-Reply-To: <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
Message-ID: <MxKjWToGMTs7P6IxUfTicD2QHLJAI0RbWMLSj4Z96Ro=.ad12d07c-56e3-4c50-8350-2e5c5c168421@github.com>

On Thu, 24 Jul 2025 15:45:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI fix

LGTM

-------------

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26434#pullrequestreview-3056079592

From pchilanomate at openjdk.org  Fri Jul 25 16:24:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Jul 2025 16:24:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <ffNR11hbQks0gBjmnl0RBbvnSofqC5746Haj8IUNn90=.cf495e3f-1497-44f0-8923-09150f148f6c@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

LGTM.

src/hotspot/share/runtime/threadSMR.hpp line 48:

> 46: // perform an operation on a target thread.
> 47: //
> 48: // There two ways to refer to java.lang.Thread objects so we have two ways

Nit: are

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3056107193
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231550522

From coleenp at openjdk.org  Fri Jul 25 16:33:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Jul 2025 16:33:56 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
Message-ID: <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>

On Fri, 25 Jul 2025 15:31:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [ ] Linux x86_64 server fastdebug, `all`
>
> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 69:
> 
>> 67:     // Klass is null means this has been a mirror for a primitive type
>> 68:     // that we do not need to follow as they are always strong roots.
>> 69:     assert(java_lang_Class::is_primitive(obj), "Sanity");
> 
> Question, since this assert is new:
> 
> When we create a mirror (`java_lang_Class::allocate_mirror`) during normal - non-shared - class loading, is there not a small time window where the mirror exists on the heap, but the Klass is still NULL? Could concurrent heap walkers not observe that?

Good point.  We create the mirror then initialize the class, so a concurrent GC could see a null Klass pointer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231567610

From kvn at openjdk.org  Fri Jul 25 16:50:03 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Jul 2025 16:50:03 GMT
Subject: RFR: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method [v5]
In-Reply-To: <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
 <JkhG03PpJ-hLQU8nK4oMDweuuXQi8oy3slaTDgkuUUg=.a045d018-16b9-4cff-9027-31643c1ffa79@github.com>
Message-ID: <GI8b4ARp_fgpm5V09CRj0DIlDp_L9hFHptOXG_I9M7E=.3a908cc8-596f-4d7e-9817-e5cbc4c39856@github.com>

On Thu, 24 Jul 2025 15:45:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
>> 
>> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
>> 
>> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
>> 
>> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
>> 
>> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
>> 
>> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
>> 
>> Tested: tier1-4,tier10-rt,xcomp,stress
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI fix

Thank you all for reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26434#issuecomment-3119381710

From kvn at openjdk.org  Fri Jul 25 16:50:04 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Jul 2025 16:50:04 GMT
Subject: Integrated: 8363837: Make StubRoutines::crc_table_adr() into
 platform-specific method
In-Reply-To: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
References: <oHwAipY0YPPH0_MYIPcbXJAAydvz34V_PwfRps27Dsc=.1ac8cec1-0fd8-499d-905d-0a8d81f3c707@github.com>
Message-ID: <OF2HeKpOFjZnd5r9fy8xXTHFdR9j2Db-S6QZQvXarvg=.58fe29a1-c071-45b6-930a-bf813372eb74@github.com>

On Tue, 22 Jul 2025 21:56:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `StubRoutines::_crc_table_adr` and `_crc32c_table_addr` are used by initial stubs. In Leyden these addresses should be recorded in `AOTCodeAddressTable` to be used by AOTed stubs. But recording in `AOTCodeAddressTable` is done in `AOTCodeCache::init2()` which is called before initial stubs are generated and `_crc*_table_addr` are set.
> 
> We need to move `_crc_table_addr` and `_crc32c_table_addr` initialization to `preuniverse` blob to be available in `AOTCodeCache::init2()`.
> 
> I also renamed `_crc_table_adr` to `_crc_table_addr` to match other names.
> 
> During testing I found that `-Xlog:stubs` affects empty blobs generation.  There was typo there: `return nullptr;` was in wrong place.
> 
> I have to specify sizes of `preuniverse` blobs so they are called after I fixed typo.  `32` bytes is cache line size on most CPUs. Note, there will be no assembler code generation for this case: `_crc*_table_addr` are initialized by address of C tables. 
> 
> I did not move `_crc*_table_addr` declaration in `stubDeclarations.hpp` from `init` to `preuniverse` blob. I tried but there is issue: they require to specify stub name and I can move `updateBytesCRC32` stub declaration.  I tries add fake stub but it did not work.  I would prefer if I could use `nullptr` instead of stub in such case. But it will complicate other code. I think it is fine `do_entry()` macro only creates field and accessor function.
> 
> Tested: tier1-4,tier10-rt,xcomp,stress

This pull request has now been integrated.

Changeset: 89fe586e
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89fe586edd5044923a2ce86f8cc5bf16004ac0b5
Stats:     85 lines in 24 files changed: 60 ins; 18 del; 7 mod

8363837: Make StubRoutines::crc_table_adr() into platform-specific method

Reviewed-by: adinn, yzheng

-------------

PR: https://git.openjdk.org/jdk/pull/26434

From mablakatov at openjdk.org  Fri Jul 25 16:56:57 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Fri, 25 Jul 2025 16:56:57 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v2]
In-Reply-To: <G9x9OSfVm6Scn7iFRilN9EvcZzQ2vobLbgBaJwEM6r0=.2efe2ae1-f7b3-41bf-aad8-7b64cdf7d5ba@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <g2M3vXzb2zf3BWuHiW6cm6zgh6BJ5FXDQp9-t_Y_HNo=.a7583ddb-7fb9-43c0-96e9-1361728ed30d@github.com>
 <G9x9OSfVm6Scn7iFRilN9EvcZzQ2vobLbgBaJwEM6r0=.2efe2ae1-f7b3-41bf-aad8-7b64cdf7d5ba@github.com>
Message-ID: <RRC80yZHp3-p8Fyw4YTGp8Xhh1FNL2z-O3SpCahaWYU=.3e472b07-2fb5-4e8d-94bc-0a35bd140cc9@github.com>

On Thu, 24 Jul 2025 21:42:21 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>>  - Combine the two shared trampoline request hash tables
>
> src/hotspot/share/asm/codeBuffer.hpp line 550:
> 
>> 548:   typedef Pair<TrampolineCallKind, address> SharedTrampolineRequestKey;
>> 549:   typedef ResizeableResourceHashtable<SharedTrampolineRequestKey, Offsets, AnyObj::C_HEAP,
>> 550:                                       mtCompiler>
> 
> You can keep using `address` as a key. I don't think `ciMethod*` can be a runtime call target. If we keep using `address` as a key we don't need to define a hash function. 
> A type of a call can be stored as data with offset.

Thank you for a suggestion! I think it works just as fine as the current version does but reduces the footprint of the patch significantly. Hopefully this should make it easier to review the PR. I'll submit an update next week.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2231604632

From shade at openjdk.org  Fri Jul 25 17:04:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 17:04:57 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
 <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
Message-ID: <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>

On Fri, 25 Jul 2025 16:31:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 69:
>> 
>>> 67:     // Klass is null means this has been a mirror for a primitive type
>>> 68:     // that we do not need to follow as they are always strong roots.
>>> 69:     assert(java_lang_Class::is_primitive(obj), "Sanity");
>> 
>> Question, since this assert is new:
>> 
>> When we create a mirror (`java_lang_Class::allocate_mirror`) during normal - non-shared - class loading, is there not a small time window where the mirror exists on the heap, but the Klass is still NULL? Could concurrent heap walkers not observe that?
>
> Good point.  We create the mirror then initialize the class, so a concurrent GC could see a null Klass pointer.

Actually, I now see this assert is tautological: `java_lang_Class::is_primitive` checks that `java_class->metadata_field(_klass_offset) == nullptr`, which is the same as pulling the `Klass*` with `java_lang_Class::as_Klass` and null-checking it, like _we already just did_. So really the assert is redundant and we can purge it.

But this also suggests that whatever interaction with GC exists, it affects current code as well. I think it works with concurrent GCs through a different mechanism: the classes loaded during the GC and their mirrors would be either treated as implicitly live (e.g. via SATB invariants), or need to be specially keep-alived (Shenandoah's IU mode did this, IIRC).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231610330

From shade at openjdk.org  Fri Jul 25 17:04:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 17:04:58 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
 <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
 <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>
Message-ID: <od7_tN-iw2MSbV3PpNrUK3fpazZuLP_-xxL-Z_U9qhg=.c52d19d6-6d3b-450d-89fc-8dfa9da0f8be@github.com>

On Fri, 25 Jul 2025 16:56:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Good point.  We create the mirror then initialize the class, so a concurrent GC could see a null Klass pointer.
>
> Actually, I now see this assert is tautological: `java_lang_Class::is_primitive` checks that `java_class->metadata_field(_klass_offset) == nullptr`, which is the same as pulling the `Klass*` with `java_lang_Class::as_Klass` and null-checking it, like _we already just did_. So really the assert is redundant and we can purge it.
> 
> But this also suggests that whatever interaction with GC exists, it affects current code as well. I think it works with concurrent GCs through a different mechanism: the classes loaded during the GC and their mirrors would be either treated as implicitly live (e.g. via SATB invariants), or need to be specially keep-alived (Shenandoah's IU mode did this, IIRC).

This is what old CMS comment tried to say, I think:


// However, we might get across a klass that just changed during CMS concurrent
// marking if allocation occurred in the old generation.
//
// This is benign here, as we keep alive all CLDs that were loaded during the
// CMS concurrent phase in the class loading, i.e. they will be iterated over
// and kept alive during remark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231620237

From shade at openjdk.org  Fri Jul 25 17:07:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 17:07:54 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <od7_tN-iw2MSbV3PpNrUK3fpazZuLP_-xxL-Z_U9qhg=.c52d19d6-6d3b-450d-89fc-8dfa9da0f8be@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
 <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
 <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>
 <od7_tN-iw2MSbV3PpNrUK3fpazZuLP_-xxL-Z_U9qhg=.c52d19d6-6d3b-450d-89fc-8dfa9da0f8be@github.com>
Message-ID: <7ESr0Fa5H-yDf0lpEXCw_ljWScn5egD1COLOl_2yT3A=.1bc0fcda-1ada-48ce-b485-efa171fe5877@github.com>

On Fri, 25 Jul 2025 17:00:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Actually, I now see this assert is tautological: `java_lang_Class::is_primitive` checks that `java_class->metadata_field(_klass_offset) == nullptr`, which is the same as pulling the `Klass*` with `java_lang_Class::as_Klass` and null-checking it, like _we already just did_. So really the assert is redundant and we can purge it.
>> 
>> But this also suggests that whatever interaction with GC exists, it affects current code as well. I think it works with concurrent GCs through a different mechanism: the classes loaded during the GC and their mirrors would be either treated as implicitly live (e.g. via SATB invariants), or need to be specially keep-alived (Shenandoah's IU mode did this, IIRC).
>
> This is what old CMS comment tried to say, I think:
> 
> 
> // However, we might get across a klass that just changed during CMS concurrent
> // marking if allocation occurred in the old generation.
> //
> // This is benign here, as we keep alive all CLDs that were loaded during the
> // CMS concurrent phase in the class loading, i.e. they will be iterated over
> // and kept alive during remark.

Pretty exhausted at this point, I'll mull over it after the weekend. But so far I think we are fine. Testing returns clean as well. If you can schedule some aggressive testing over the weekend, it would be helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231628450

From shade at openjdk.org  Fri Jul 25 17:10:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 17:10:55 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently
In-Reply-To: <7ESr0Fa5H-yDf0lpEXCw_ljWScn5egD1COLOl_2yT3A=.1bc0fcda-1ada-48ce-b485-efa171fe5877@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
 <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
 <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>
 <od7_tN-iw2MSbV3PpNrUK3fpazZuLP_-xxL-Z_U9qhg=.c52d19d6-6d3b-450d-89fc-8dfa9da0f8be@github.com>
 <7ESr0Fa5H-yDf0lpEXCw_ljWScn5egD1COLOl_2yT3A=.1bc0fcda-1ada-48ce-b485-efa171fe5877@github.com>
Message-ID: <ayKiM0IiwD0anfU-BXp11rJXzghwX0YGLbx0Wvdzlos=.06719ac8-3936-44af-9af0-593bfcbe1b48@github.com>

On Fri, 25 Jul 2025 17:05:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is what old CMS comment tried to say, I think:
>> 
>> 
>> // However, we might get across a klass that just changed during CMS concurrent
>> // marking if allocation occurred in the old generation.
>> //
>> // This is benign here, as we keep alive all CLDs that were loaded during the
>> // CMS concurrent phase in the class loading, i.e. they will be iterated over
>> // and kept alive during remark.
>
> Pretty exhausted at this point, I'll mull over it after the weekend. But so far I think we are fine. Testing returns clean as well. If you can schedule some aggressive testing over the weekend, it would be helpful.

Wait, it's actually the other way around: we can see `nullptr` it our explicit check for a non-primitive class, stall, get to the assert, _then_ discover that mirror is installed, and falsely fail the assert. Assert *needs* to be removed, hold on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2231633100

From shade at openjdk.org  Fri Jul 25 17:27:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Jul 2025 17:27:34 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v2]
In-Reply-To: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
Message-ID: <NtTcf-h4bJw9kGMiVLiwxrmB5r4KeArPuvvz6cNNywc=.80f75e01-ba10-409c-b230-8f11820de8f9@github.com>

> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
> 
> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>  - [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:

  Drop assert, more discussion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26477/files
  - new: https://git.openjdk.org/jdk/pull/26477/files/5e4153ae..bc853287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26477&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26477&range=00-01

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26477/head:pull/26477

PR: https://git.openjdk.org/jdk/pull/26477

From jiangli at openjdk.org  Fri Jul 25 17:42:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 25 Jul 2025 17:42:15 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
Message-ID: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>

> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
> 
> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @eastig review comment:
  - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26395/files
  - new: https://git.openjdk.org/jdk/pull/26395/files/3cfac836..476c56d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26395&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26395&range=00-01

  Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26395/head:pull/26395

PR: https://git.openjdk.org/jdk/pull/26395

From jiangli at openjdk.org  Fri Jul 25 17:42:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 25 Jul 2025 17:42:15 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <ybM-bjo9qQnX_DGK_pLMrLILAnssXHRFksdMgQLL8Yg=.f602990a-6d51-4803-bcd9-4f11b8d1f358@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
 <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>
 <ybM-bjo9qQnX_DGK_pLMrLILAnssXHRFksdMgQLL8Yg=.f602990a-6d51-4803-bcd9-4f11b8d1f358@github.com>
Message-ID: <Ccfcr1u_k0epps8AjsRjW2pgu_Vx5F3Wyhcjcbihht0=.cbd26820-3da2-4231-8ff7-040198d99871@github.com>

On Fri, 25 Jul 2025 14:41:17 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> @eastig Thanks for taking a look!
>> 
>> The log `Info, stubs` output provides useful details. With the assertion failure, it wouldn't show. That's why moving the assert to after the log output.
>
> If you need information which is printed out in the log, why not to add needed information to the assert? You can copy the format string used for logging. This will make assert's output more informative without a need for enabling logging.

Sounds reasonable to me. I updated the PR to move back the assert and added code_size, buffer total size and free to the assert output. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2231688673

From rasbold at openjdk.org  Fri Jul 25 17:58:53 2025
From: rasbold at openjdk.org (Chuck Rasbold)
Date: Fri, 25 Jul 2025 17:58:53 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Ccfcr1u_k0epps8AjsRjW2pgu_Vx5F3Wyhcjcbihht0=.cbd26820-3da2-4231-8ff7-040198d99871@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
 <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>
 <ybM-bjo9qQnX_DGK_pLMrLILAnssXHRFksdMgQLL8Yg=.f602990a-6d51-4803-bcd9-4f11b8d1f358@github.com>
 <Ccfcr1u_k0epps8AjsRjW2pgu_Vx5F3Wyhcjcbihht0=.cbd26820-3da2-4231-8ff7-040198d99871@github.com>
Message-ID: <fUVlWcLle-JnfOtl5E8F-KaR9qKyt15ZNffxoLa9GaQ=.966b6af6-898a-47fe-a5e5-1417ba8154e6@github.com>

On Fri, 25 Jul 2025 17:39:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> If you need information which is printed out in the log, why not to add needed information to the assert? You can copy the format string used for logging. This will make assert's output more informative without a need for enabling logging.
>
> Sounds reasonable to me. I updated the PR to move back the assert and added code_size, buffer total size and free size info to the assert output. Thanks

I actually think the change is better with the assert after the logging, as initially proposed. 

I don't object to the making the assert's output more informative, but can imagine that there may be future improvements to the log message which may then leave the assert with a different message.

The risk of switching the assertion and logging seems minimal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2231716799

From dcubed at openjdk.org  Fri Jul 25 18:08:59 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 25 Jul 2025 18:08:59 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <lGDHJ2RP6K7L_Gi0w5VbWE4R8dwBeNjBNkBlAGrgaBU=.3ab6b3cb-8a11-4eea-90a4-1d72d487850d@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
 <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
 <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>
 <lGDHJ2RP6K7L_Gi0w5VbWE4R8dwBeNjBNkBlAGrgaBU=.3ab6b3cb-8a11-4eea-90a4-1d72d487850d@github.com>
Message-ID: <B5DjmRXjCbHyYUFgOmH2XaJuZuI-PAkM3r2SFnhZxF4=.91594a97-a490-4fed-8693-82b88747df34@github.com>

On Fri, 25 Jul 2025 07:05:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay, thanks.
>
> Once this change is in main line then we can sync'up the loom repo and work on the follow-up changes. The loom repo has changes (that are not in main line) for "suspending" an unmounted thread. For the mounted case then we'll need checks in the handshake to ensure that the expected virtual threads is mounted. We'll need stress tests of course and we can collaborate there in advance of proposing changes for main line.

> Note that java_thread may already be null so we don't get to execute line 836.

I'm having some trouble with this statement. Working backwards from L836, I see
the nullptr check on L826 and the check for non-virtual thread and bail on L827
and L831. However, if we saw nullptr on L826 and we have a virtual thread, then
we can get to L836 even when we started off with a null java_thread.

So I guess I'm not sure what point you're trying to make with the statement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231702449

From dcubed at openjdk.org  Fri Jul 25 18:09:00 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 25 Jul 2025 18:09:00 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <ffNR11hbQks0gBjmnl0RBbvnSofqC5746Haj8IUNn90=.cf495e3f-1497-44f0-8923-09150f148f6c@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <ffNR11hbQks0gBjmnl0RBbvnSofqC5746Haj8IUNn90=.cf495e3f-1497-44f0-8923-09150f148f6c@github.com>
Message-ID: <pm6ILPObDDpD_9yQaR0vSv9ekQ2LphSGv6ZffTJXBA8=.27f6befc-9df9-4608-88b0-aef1947f2cf4@github.com>

On Fri, 25 Jul 2025 16:21:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> src/hotspot/share/runtime/threadSMR.hpp line 48:
> 
>> 46: // perform an operation on a target thread.
>> 47: //
>> 48: // There two ways to refer to java.lang.Thread objects so we have two ways
> 
> Nit: are

Just to be more clear: s/There two ways/There are two ways/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231707768

From dcubed at openjdk.org  Fri Jul 25 18:08:58 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 25 Jul 2025 18:08:58 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
Message-ID: <VCQr8k3Ld2fu0mMB4SvqNaDUhlA4p1Gz8gz18jasicw=.2446f1ad-d426-4b06-93f9-12083e4390dc@github.com>

On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move comment

Thumbs up on the changes. I think I only have a few nits.

src/hotspot/share/prims/jvmtiExport.cpp line 871:

> 869: //
> 870: jvmtiError
> 871: JvmtiExport::cv_oop_to_JavaThread(ThreadsList * t_list, oop thread_oop,

When did `JvmtiExport::cv_oop_to_JavaThread` become unused?

src/hotspot/share/runtime/threadSMR.cpp line 833:

> 831:       return false;
> 832:     } else {
> 833:       // For virtual thread's we need to extract the carrier's JavaThread - if any.

nit typo: s/thread's/threads/

src/hotspot/share/runtime/threadSMR.hpp line 72:

> 70: //   :  // do stuff with 'jt'...
> 71: //
> 72: // A JavaThread* that is included in the ThreadsList that is held by

Why change just this location from `JavaThread *` to `JavaThread*`?
There are other places that you touched that still use `JavaThread *`.

src/hotspot/share/runtime/threadSMR.hpp line 310:

> 308:   inline Iterator end();
> 309: 
> 310:   bool cv_internal_thread_to_JavaThread(jobject jthread, JavaThread** jt_pp, oop* thread_oop_p);

I wish I could remember why in the world I put a space before the `*` when I
did this code so very long ago...

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3056275005
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231715585
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231668135
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231710443
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231713403

From jiangli at openjdk.org  Fri Jul 25 18:54:53 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 25 Jul 2025 18:54:53 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <fUVlWcLle-JnfOtl5E8F-KaR9qKyt15ZNffxoLa9GaQ=.966b6af6-898a-47fe-a5e5-1417ba8154e6@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <U4-RLlv-FUAlGgC-CpcmWChpSlQaU2arqQS7ziRYLM4=.4e3020fb-cf79-4bb9-9753-003d462476f7@github.com>
 <l_itP0084xwhcp_e4D8GXVoL9iI-9SripfBpPxgQyzc=.abd64bbe-be7d-45a4-bee9-053ec60d5682@github.com>
 <ybM-bjo9qQnX_DGK_pLMrLILAnssXHRFksdMgQLL8Yg=.f602990a-6d51-4803-bcd9-4f11b8d1f358@github.com>
 <Ccfcr1u_k0epps8AjsRjW2pgu_Vx5F3Wyhcjcbihht0=.cbd26820-3da2-4231-8ff7-040198d99871@github.com>
 <fUVlWcLle-JnfOtl5E8F-KaR9qKyt15ZNffxoLa9GaQ=.966b6af6-898a-47fe-a5e5-1417ba8154e6@github.com>
Message-ID: <NMjl4_6Pjd8Kthfimrs-uvgUb35jn9Qfbj04EGLTcv0=.a0a97d90-67b9-45b3-9ff9-b267d995d2d7@github.com>

On Fri, 25 Jul 2025 17:56:28 GMT, Chuck Rasbold <rasbold at openjdk.org> wrote:

>> Sounds reasonable to me. I updated the PR to move back the assert and added code_size, buffer total size and free size info to the assert output. Thanks
>
> I actually think the change is better with the assert after the logging, as initially proposed. 
> 
> I don't object to the making the assert's output more informative, but can imagine that there may be future improvements to the log message which may then leave the assert with a different message.
> 
> The risk of switching the assertion and logging seems minimal.

@rasbold Thanks for the thought! Right, there doesn't seem to be much risk with moving the assert to after the logging. With the additional info in the assert output as @eastig suggested, it does provide enough information without needing to enable `-Xlog:stubs`. In the case where we ran into the particular problem in non-local testing environment, the additional size information provided in the assert could save quite some debugging time. So the current change does seem to be a bit more advantageous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26395#discussion_r2231808594

From eastigeevich at openjdk.org  Fri Jul 25 19:46:03 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 25 Jul 2025 19:46:03 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <-IINGwsF992Al0naVREDpvE6nE6FamJ1EOIoIB3aEK0=.65daa4d8-af68-4376-a210-5826879d24ed@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>
 <7AIC7kPYWB133weIDM4wtwDat4H4dfuNqH_alS5wkh4=.f9aa934d-689c-4991-86af-7d61fc4d12d3@github.com>
 <-IINGwsF992Al0naVREDpvE6nE6FamJ1EOIoIB3aEK0=.65daa4d8-af68-4376-a210-5826879d24ed@github.com>
Message-ID: <LIUOM-VNoW8EAXtu9EmF9hXfE7nWuNrN2zHs_2_ti5o=.4976c619-dfbd-40e5-a167-d72f9762b12f@github.com>

On Mon, 21 Jul 2025 16:10:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > Do you not think we should implement the Arm-recommended solution in https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm?
> > 
> > 
> > When we get armv8.7 hardware, I'd like to try their solution.
> 
> OK, that makes sense.

In Apple Silicon CPU Optimization Guide I found M4 supports FEAT_SB (Armv8.5-A), FEAT_ECV (Armv8.6-A) and FEAT_WFxT (Armv8.7-A). I will try to get access to it to test the implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3120128077

From jbhateja at openjdk.org  Fri Jul 25 20:09:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 20:09:40 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>

> 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
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Updating predicate checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/b2e93434..04be59a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From kbarrett at openjdk.org  Fri Jul 25 20:10:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Jul 2025 20:10:56 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v7]
In-Reply-To: <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
Message-ID: <DROlG4-bzbN8xaGZnrkpeiZm_MDdaOL_ik-QldgiJPY=.90b74712-1fa0-4c1d-8ca6-9fb7bfdc17a5@github.com>

On Fri, 25 Jul 2025 08:49:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move up
>  - revert

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26428#pullrequestreview-3056672167

From duke at openjdk.org  Fri Jul 25 22:13:54 2025
From: duke at openjdk.org (duke)
Date: Fri, 25 Jul 2025 22:13:54 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v7]
In-Reply-To: <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
Message-ID: <-2tIXo8q3_SdqNgwnahch50IRa2CQYcB4_cUKtNPqGU=.7cc9cab2-8bda-4f5c-a071-c6129fe1b8ca@github.com>

On Fri, 25 Jul 2025 08:49:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move up
>  - revert

@fandreuz 
Your change (at version 88b4d4c22906c84cf3a259c49c4497116ba38e5e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26428#issuecomment-3120527292

From dlong at openjdk.org  Sat Jul 26 01:40:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Jul 2025 01:40:08 GMT
Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4
 only MacOSX aarch64 [v2]
In-Reply-To: <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>
References: <FYgWIv_iFwkr9an56KHdJqZlyUgtD_4g2f51hvavZWw=.f5c943f7-65e6-4944-afec-0b9c19a7b284@github.com>
 <pGV8Db8JQIT-K6I0GWaRe9n9GsAlHKjwkAfV7kw2Lmo=.df3e4a96-cc73-4a84-98c3-b044cbd2d3a4@github.com>
Message-ID: <FEzUdgFuEI3sZbOTMmri1b0cOfifT38jmdnDgpIWN-U=.ac4caa4c-f352-4b95-9a7e-57f201c1e6ce@github.com>

On Thu, 24 Jul 2025 18:51:22 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove NMethodEntryBarrier_lock

Unfortunately, I am still seeing a small 1% regression in Renaissance-NaiveBayes with ZGC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3120938875

From ysuenaga at openjdk.org  Sat Jul 26 02:16:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 26 Jul 2025 02:16:49 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Rename is_oom to emit_old_object_samples

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/c3198690..ee27149e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=00-01

  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From ysuenaga at openjdk.org  Sat Jul 26 02:16:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 26 Jul 2025 02:16:50 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <YBrgmAkderhdpG0vjwreKvXUcoKjEcOCo4Y_PVEkNkE=.d5956950-71df-4588-b14f-e4d897f29b1b@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

I renamed a parameter `is_oom` to `emit_old_object_samples`.
@egahlin Could you review again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3120997144

From sspitsyn at openjdk.org  Sat Jul 26 08:14:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 26 Jul 2025 08:14:56 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <VCQr8k3Ld2fu0mMB4SvqNaDUhlA4p1Gz8gz18jasicw=.2446f1ad-d426-4b06-93f9-12083e4390dc@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <VCQr8k3Ld2fu0mMB4SvqNaDUhlA4p1Gz8gz18jasicw=.2446f1ad-d426-4b06-93f9-12083e4390dc@github.com>
Message-ID: <2LosO9izz8w79NUa6EoEvSFe3w-umGreQM2whKyK_IY=.c5c7a643-c628-4a5c-919d-00b094f47116@github.com>

On Fri, 25 Jul 2025 17:55:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> src/hotspot/share/prims/jvmtiExport.cpp line 871:
> 
>> 869: //
>> 870: jvmtiError
>> 871: JvmtiExport::cv_oop_to_JavaThread(ThreadsList * t_list, oop thread_oop,
> 
> When did `JvmtiExport::cv_oop_to_JavaThread` become unused?

To support virtual threads the JVMTI is using `JvmtiEnvBase::get_threadOop_and_JavaThread()` which in turn is using the `JvmtiExport::cv_external_thread_to_JavaThread()`. Also, the `JvmtiExport::cv_external_thread_to_JavaThread()` is used directly in some places. When the last usage of `JvmtiExport::cv_oop_to_JavaThread()` become unused I was not sure it is not needed anymore and left it alone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2232788477

From egahlin at openjdk.org  Sat Jul 26 16:56:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 26 Jul 2025 16:56:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
Message-ID: <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>

On Sat, 26 Jul 2025 02:16:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_oom to emit_old_object_samples

src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp line 563:

> 561:     LeakProfiler::emit_events(max_jlong, false, false);
> 562:   } else {
> 563:     EventShutdown e;

Do you know why EventShutDown is not always emitted?

Is it emitted from somewhere else, so we would get two events if we always emitted it here?

I know it was this way before your change, but I?d like to understand why. We want to add another parameter or write a comment to explain the behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2233100695

From stuefe at openjdk.org  Sat Jul 26 18:32:32 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 26 Jul 2025 18:32:32 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit
Message-ID: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>

We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].

A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 

Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - I want to get rid of `-UseCompressedClassPointers` a lot sooner than that.

Therefore, I needed to find a way to support `+UseCompressedClassPointers` on 32-bit. Alternatives would have been:
- remove `-UseCompressedClassPointers` for 64-bit, but leave it in for 32-bit. This would have greatly diminished the benefits though, since we would have to keep a lot of shared coding for the sake of 32-bit.
- Just get rid of `-UseCompressedClassPointers` and leave 32-bit brokenness to the maintainers of 32-bit ports; but that would be throwing 32-bit under the bus knowingly, and I did not want to do that.

-------

This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. Additionally, the code is clearly marked and can be removed cleanly once we completely remove 32-bit support in two or three releases.

How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. Since narrowKlass is 32-bit, that works. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.

We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.

We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design (+COH, aka "Lilliput 1", would be pointless on 32-bit anyway).

However, the devil was in the details: a lot of code relied on the assumption that `+UseCompressedClassPointers` means "we run with a class space". That assumption now is broken, since we run with narrow Klass encoding, but without class space. The code also often assumed that `+UseCompressedClassPointers` == 64-bit, and that is not wrong, too. These things needed fixing. I introduced a new macro "NEEDS_CLASS_SPACE" which is `1` if the platform requires a class space for `+UseCompressedClassPointers`. This is `1` on 64-bit, `0` on 32-bit. I did not just use `#ifdef _LP64` since I wanted to mark these sections in the code clearly. We may need to revisit them at a later time.

CDS: CDS can continue to function as it did before on 32-bit, by being oblivious to the existence of class space and narrow Klass encoding. It simply places the CDS archive anywhere, just as it did before; Klass structures within it will continue to work. However, note that we still won't support Heap archive sections for CDS: even though we now run with `+UseCompressedClassPointers`, the placement of CDS archive and all other Klass-carrying metaspace sections is still random, so we still cannot encode narrow Klass pointers into the objects at dump time.

This is how things are reported in VM.info now - note how both klass range and encoding range cover almost all of the address space, minus small buffer areas at the bottom (below addressable space) and the top (one page):


---------------  P R O C E S S  ---------------

CDS archive(s) mapped at: [0xb6110000-0xb6c00000-0xb6c00000), size 11468800, SharedBaseAddress: 0xb6110000, ArchiveRelocationMode: 1.
UseCompressedClassPointers 1, UseCompactObjectHeaders 0
Narrow klass pointer bits 32, Max shift 0
Narrow klass base: 0x00000000, Narrow klass shift: 0
Encoding Range: [0x00000000 - 0xfffff000), (4294963200 bytes)
Klass Range:    [0x01000000 - 0xfffff000), (4278185984 bytes)
Klass ID Range:  [16777216 - 4294963193) (4278185977)
Protection zone: [0x00000000 - 0x01000000), (16777216 bytes)

-------

Testing:

All of this was developed and tested on arm on a Raspberry. I made sure gtests run cleanly through, I ran a couple of tests from the Metaspace suite, and tested spring petclinic. All of this with C1/C2 and CDS active. Works fine now with `+UseCompressedClassPointers`.

I did not test Zero 32-bit, nor do I intent to. This works well enough on 32-bit now to survive casual use and as many tests as I cared to throw at my poor old Raspberry. This is enough for me. Any further fixes will have to be done by those responsible for maintaining 32-bit ports, and be done in follow-up RFEs.

-------

[1] [hotspot-dev: Deprecate -UseCompressedClassPointers?](https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html)
[2] [Deprecation CSR](https://bugs.openjdk.org/browse/JDK-8350754)
[3] [jdk-dev: The future of 32-bit?](https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009889.html)

-------------

Commit messages:
 - fix gtests on arm32
 - Fix display of encoding range
 - copyrights
 - cosmetics
 - some cleanups in arm cpu coding
 - ARM32 helloworld now works
 - wip
 - oops/compressedKlass
 - oops/ObjLayout
 - Start

Changes: https://git.openjdk.org/jdk/pull/26491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363998
  Stats: 185 lines in 17 files changed: 114 ins; 45 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491

PR: https://git.openjdk.org/jdk/pull/26491

From ysuenaga at openjdk.org  Sun Jul 27 02:10:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 02:10:01 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
 <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>
Message-ID: <5S_xXktLLlxi8Sz3xD39ZjYokKzhN1rZDj36BDN8GdQ=.0d298ab0-4a32-4343-a722-bbb5168e57cc@github.com>

On Sat, 26 Jul 2025 16:54:33 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename is_oom to emit_old_object_samples
>
> src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp line 563:
> 
>> 561:     LeakProfiler::emit_events(max_jlong, false, false);
>> 562:   } else {
>> 563:     EventShutdown e;
> 
> Do you know why EventShutDown is not always emitted?
> 
> Is it emitted from somewhere else, so we would get two events if we always emitted it here?
> 
> I know it was this way before your change, but I?d like to understand why. We may want to add another parameter or write a comment to explain the behavior.

We have two call path to emit `EventShutdown`.

In case of the most of OOM which triggers VM shutdown (e.g. OOM happend on the last non-daemon thread), `Threads::destroy_vm()` should be called, and `Jfr::on_vm_shutdown()` would be called via `before_exit` @ java.cpp .

`Threads::destroy_vm()` @ src/hotspot/share/runtime/threads.cpp

  EventShutdown e;
  if (e.should_commit()) {
    e.set_reason("No remaining non-daemon Java threads");
    e.commit();
  }

  // Hang forever on exit if we are reporting an error.
  if (ShowMessageBoxOnError && VMError::is_error_reported()) {
    os::infinite_sleep();
  }
  os::wait_for_keypress_at_exit();

  // run Java level shutdown hooks
  thread->invoke_shutdown_hooks();

  before_exit(thread);


In case of `exception_handler` - `VMError::report_and_die()` in this case - `EventShutdown` would be emitted at `post_events()`, however `LeakProfiler::emit_events()` would not be called.

I think both `EventShutdown` and LeakProfiler should be emitted when the crash happens due to `-XX:+CrashOnOutOfMemoryError`. So I will add another parameter to enforce to emit `EventShutdown` in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2233594799

From ysuenaga at openjdk.org  Sun Jul 27 10:02:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 10:02:40 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add emit_event_shutdown

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/ee27149e..6cf417d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=01-02

  Stats: 14 lines in 6 files changed: 4 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From ysuenaga at openjdk.org  Sun Jul 27 10:02:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 10:02:40 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
Message-ID: <ZwuazYZEwNkLRvYQZoYWScch6KtpGWMvTIqI2c-wR2Q=.db456071-3b01-45e6-9b2c-9b034681d649@github.com>

On Sat, 26 Jul 2025 02:16:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_oom to emit_old_object_samples

@egahlin 
I added new parameter `emit_event_shutdown` to emit `EventShutdown` in new commit. This change does not change current behavior, and it passed `jdk_jfr` test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3124275944

From duke at openjdk.org  Sun Jul 27 14:45:54 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 27 Jul 2025 14:45:54 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit
In-Reply-To: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
Message-ID: <9NTTOvPZerCNlATyAAyvX9gC7oUyG28_vcHZsnnE-lw=.5a097ef5-26ff-4633-acf5-d588317213dc@github.com>

On Sat, 26 Jul 2025 12:17:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
> 
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
> 
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
> 
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
> 
> -------
> 
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
> 
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
> 
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
> 
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...

src/hotspot/share/oops/compressedKlass.cpp line 346:

> 344: 
> 345: #if NEEDS_CLASS_SPACE
> 346: // On AIX, we cannot mprotect archive space or cwviedwlass space since they are reserved with SystemV shm.

Suggestion:

// On AIX, we cannot mprotect archive space or class space since they are reserved with SystemV shm.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2234013383

From dholmes at openjdk.org  Sun Jul 27 21:36:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 27 Jul 2025 21:36:16 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v3]
In-Reply-To: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
Message-ID: <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>

> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
> 
> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
> 
> Testing:
> - tiers 1-4
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26287/files
  - new: https://git.openjdk.org/jdk/pull/26287/files/820f26e4..d863add5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287

PR: https://git.openjdk.org/jdk/pull/26287

From dholmes at openjdk.org  Sun Jul 27 21:36:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 27 Jul 2025 21:36:16 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <VCQr8k3Ld2fu0mMB4SvqNaDUhlA4p1Gz8gz18jasicw=.2446f1ad-d426-4b06-93f9-12083e4390dc@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <VCQr8k3Ld2fu0mMB4SvqNaDUhlA4p1Gz8gz18jasicw=.2446f1ad-d426-4b06-93f9-12083e4390dc@github.com>
Message-ID: <LoTQNb2wjg2wYyz-rV-L1RIJzQpLSlrSpmlHmgcdJQE=.98d1cf42-d053-4333-8c0e-bc03acfeca1b@github.com>

On Fri, 25 Jul 2025 18:06:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> Thumbs up on the changes. I think I only have a few nits.

Thanks for the review @dcubed-ojdk !

Just need one Reviewer to re-review the nit fix-ups. Thanks

> src/hotspot/share/runtime/threadSMR.cpp line 833:
> 
>> 831:       return false;
>> 832:     } else {
>> 833:       // For virtual thread's we need to extract the carrier's JavaThread - if any.
> 
> nit typo: s/thread's/threads/

Fixed

> src/hotspot/share/runtime/threadSMR.hpp line 72:
> 
>> 70: //   :  // do stuff with 'jt'...
>> 71: //
>> 72: // A JavaThread* that is included in the ThreadsList that is held by
> 
> Why change just this location from `JavaThread *` to `JavaThread*`?
> There are other places that you touched that still use `JavaThread *`.

I started changing them all but changed my mind - I missed reverting this one. Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3124739300
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139881
PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234140216

From dholmes at openjdk.org  Sun Jul 27 21:36:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 27 Jul 2025 21:36:17 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <B5DjmRXjCbHyYUFgOmH2XaJuZuI-PAkM3r2SFnhZxF4=.91594a97-a490-4fed-8693-82b88747df34@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
 <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
 <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>
 <lGDHJ2RP6K7L_Gi0w5VbWE4R8dwBeNjBNkBlAGrgaBU=.3ab6b3cb-8a11-4eea-90a4-1d72d487850d@github.com>
 <B5DjmRXjCbHyYUFgOmH2XaJuZuI-PAkM3r2
 SFnhZxF4=.91594a97-a490-4fed-8693-82b88747df34@github.com>
Message-ID: <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com>

On Fri, 25 Jul 2025 17:48:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> then we can get to L836 even when we started off with a null java_thread.

Sure. My point was more the other way round - we could have a null JavaThread without the null coming from line  836.

The comment was just trying to expand on my previous comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139305

From dholmes at openjdk.org  Sun Jul 27 21:36:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 27 Jul 2025 21:36:17 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <ffNR11hbQks0gBjmnl0RBbvnSofqC5746Haj8IUNn90=.cf495e3f-1497-44f0-8923-09150f148f6c@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <ffNR11hbQks0gBjmnl0RBbvnSofqC5746Haj8IUNn90=.cf495e3f-1497-44f0-8923-09150f148f6c@github.com>
Message-ID: <l5-vSO9lTvsgIprRELNTKyiZuIQ5W4nyrgUX1Ah5WpQ=.7bc675fb-158b-45ce-88fe-b4f2d7f7f0ed@github.com>

On Fri, 25 Jul 2025 16:21:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move comment
>
> src/hotspot/share/runtime/threadSMR.hpp line 48:
> 
>> 46: // perform an operation on a target thread.
>> 47: //
>> 48: // There two ways to refer to java.lang.Thread objects so we have two ways
> 
> Nit: are

Thanks for the review @pchilano ! Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139658

From fyang at openjdk.org  Mon Jul 28 03:59:00 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 28 Jul 2025 03:59:00 GMT
Subject: RFR: 8364120: RISC-V: unify the usage of
 MacroAssembler::instruction_size
In-Reply-To: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>
References: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>
Message-ID: <4uqTw8ShfJydps-v3nCote6jQGt28TsOYyxAT6PW8aI=.453c3ea5-3cdf-4277-af27-f5a4201b3098@github.com>

On Fri, 25 Jul 2025 14:00:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple cleanup?
> 
> in MacroAssembler, some magic number 4 is used for MacroAssembler::instruction_size. We should not use magic number if possible.
> This pr also replaces all the usage of  `instruction_size` with `MacroAssembler::instruction_size`.
> 
> Thanks

Looks fine. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26481#pullrequestreview-3060245312

From stuefe at openjdk.org  Mon Jul 28 04:58:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 04:58:40 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v2]
In-Reply-To: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
Message-ID: <pdYpJM9z1IqgHFyUYN1-jHDqnZ8hJ3haWa_BLzykTb4=.71aca0de-312e-4744-a587-c875fab5128a@github.com>

> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
> 
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
> 
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
> 
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
> 
> -------
> 
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
> 
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
> 
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
> 
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/oops/compressedKlass.cpp
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26491/files
  - new: https://git.openjdk.org/jdk/pull/26491/files/9fef5494..009dceca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491

PR: https://git.openjdk.org/jdk/pull/26491

From stuefe at openjdk.org  Mon Jul 28 05:00:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 05:00:59 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox
In-Reply-To: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
Message-ID: <RtHQrrpEmZj5rtv1ydPA5e8z9Hq3xkuHff2ykYg8FRg=.06d5bda0-5e5a-4029-bae6-1801c4eed38d@github.com>

On Fri, 25 Jul 2025 07:34:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

ping @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26472#issuecomment-3125483595

From dholmes at openjdk.org  Mon Jul 28 05:21:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 05:21:07 GMT
Subject: RFR: 8363584: Sort share/utilities includes [v7]
In-Reply-To: <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
 <xBdEc5VhVEgrvt7Tmb9s0oTF8vHvTPXBhDe7xf0ErkA=.9afc793c-3a83-42b7-b0cd-6844eb3bdb1d@github.com>
Message-ID: <-HTVIKO4cs-4Et_ndgu7UITtdYKouVBFbSlOrH4RGgw=.54ed1725-53eb-492d-a5d4-64cb994dcce8@github.com>

On Fri, 25 Jul 2025 08:49:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 tests and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move up
>  - revert

LGTM2

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26428#pullrequestreview-3060416857

From duke at openjdk.org  Mon Jul 28 05:21:07 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 28 Jul 2025 05:21:07 GMT
Subject: Integrated: 8363584: Sort share/utilities includes
In-Reply-To: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
References: <CSIEs1Qx4tD7yhgey6WHxE3NzOhCbsGdbKf-oLEcf64=.6a357212-79c1-4830-a8e2-3e186f966e61@github.com>
Message-ID: <7EkSAcM2suWJGPTwnG5ZfJjwhu0arBfxCaFyDl389Pk=.a61fa840-d0a3-48e0-a2d5-df043f68adaf@github.com>

On Tue, 22 Jul 2025 14:45:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/utilities using test/hotspot/jtreg/sources/SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 tests and GHA.

This pull request has now been integrated.

Changeset: e307b5cc
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e307b5cca870f7ea9b79b7a9d4e6f7f762c27aa4
Stats:     91 lines in 24 files changed: 45 ins; 41 del; 5 mod

8363584: Sort share/utilities includes

Reviewed-by: kbarrett, dholmes, shade

-------------

PR: https://git.openjdk.org/jdk/pull/26428

From dholmes at openjdk.org  Mon Jul 28 05:35:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 05:35:57 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v2]
In-Reply-To: <pdYpJM9z1IqgHFyUYN1-jHDqnZ8hJ3haWa_BLzykTb4=.71aca0de-312e-4744-a587-c875fab5128a@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <pdYpJM9z1IqgHFyUYN1-jHDqnZ8hJ3haWa_BLzykTb4=.71aca0de-312e-4744-a587-c875fab5128a@github.com>
Message-ID: <oYTzLfqtykNCmIw2sH6sCxHJx9TFMzMySNU8RUA0FJQ=.1c720ea0-dbbc-4647-807b-d55ad535ebc9@github.com>

On Mon, 28 Jul 2025 04:58:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/oops/compressedKlass.cpp
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Overall this looks quite reasonable to me and a good way to tackle the issue of the remaining 32-bit platform.

I will defer to others more versed in this area to do the approvals though.

Thanks

src/hotspot/share/cds/archiveHeapLoader.hpp line 32:

> 30: #include "memory/allStatic.hpp"
> 31: #include "memory/memRegion.hpp"
> 32: #include "oops/compressedKlass.hpp"

Not obvious why this is needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26491#pullrequestreview-3060431758
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2234729671

From dholmes at openjdk.org  Mon Jul 28 05:39:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 05:39:54 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox
In-Reply-To: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
Message-ID: <CRDPpdJNwqrXNati6Hc24_RTAZJc5TxXPAYVepaYhKM=.f893d58b-e9b2-4262-a63e-fd6b6d734f89@github.com>

On Fri, 25 Jul 2025 07:34:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

This looks fine to me. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26472#pullrequestreview-3060467956

From stuefe at openjdk.org  Mon Jul 28 05:43:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 05:43:01 GMT
Subject: RFR: 8340297: Use-after-free recognition for metaspace and class
 space [v2]
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: <qOvexwqS6nXbqdeUq8BpSutCZl0Xdkd7rlKHSMjCO4Y=.3bbcf6c7-e27b-4cc0-8c76-176158d479b1@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 10 commits:

 - merge master
 - copyrights
 - fix big-endian problem on AIX
 - Update klass.cpp
 - Update metaspace.hpp
 - Update metaspace.hpp
 - Update metaspace.hpp
 - fix rebase error
 - fix mac build
 - rebase, fixes

-------------

Changes: https://git.openjdk.org/jdk/pull/25891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=01
  Stats: 485 lines in 26 files changed: 401 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 jbhateja at openjdk.org  Mon Jul 28 05:55:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Jul 2025 05:55:55 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <oduPnBt3gdTm9KsT-KUdoETpBGgX1JXbVxr6qEWK5CE=.6df7c181-0b37-4d24-9a99-aa158198f2d8@github.com>

On Fri, 25 Jul 2025 20:09:40 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:
> 
>   Updating predicate checks

Performance on AVX512 machine


Baseline:
Benchmark                                                (size)   Mode  Cnt      Score       Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    4  35741.780 ?  1561.065  ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    4  35011.929 ?  5886.902  ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    4  32366.844 ?  1489.449  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    4  10636.281 ?   608.705  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    4  10750.833 ?   328.997  ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    4  10257.338 ?  2027.422  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    4   5362.330 ?  4199.651  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    4   4992.399 ?  6053.641  ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    4   4941.258 ?   478.193  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    4  40432.828 ? 26672.673  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    4  41300.811 ? 34342.482  ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    4  36958.309 ?  1899.676  ops/ms

Withopt:
Benchmark                                                (size)   Mode  Cnt      Score       Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt   10  67936.711 ?   389.783  ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt   10  70086.731 ?  5972.968  ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt   10  31879.187 ?   148.213  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt   10  17676.883 ?   217.238  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt   10  16983.007 ?  3988.548  ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt   10   9851.266 ?    31.773  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt   10   9194.216 ?    42.772  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt   10   8411.738 ?    33.209  ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt   10   5244.850 ?    12.214  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt   10  61233.526 ? 20472.895  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt   10  61545.276 ? 20722.066  ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt   10  41208.718 ?  5374.829  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3125629912

From stuefe at openjdk.org  Mon Jul 28 06:31:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 06:31:00 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
Message-ID: <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>

> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
> 
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
> 
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
> 
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
> 
> -------
> 
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
> 
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
> 
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
> 
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Remove stray include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26491/files
  - new: https://git.openjdk.org/jdk/pull/26491/files/009dceca..cdd14445

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491

PR: https://git.openjdk.org/jdk/pull/26491

From stuefe at openjdk.org  Mon Jul 28 06:31:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 06:31:01 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v2]
In-Reply-To: <oYTzLfqtykNCmIw2sH6sCxHJx9TFMzMySNU8RUA0FJQ=.1c720ea0-dbbc-4647-807b-d55ad535ebc9@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <pdYpJM9z1IqgHFyUYN1-jHDqnZ8hJ3haWa_BLzykTb4=.71aca0de-312e-4744-a587-c875fab5128a@github.com>
 <oYTzLfqtykNCmIw2sH6sCxHJx9TFMzMySNU8RUA0FJQ=.1c720ea0-dbbc-4647-807b-d55ad535ebc9@github.com>
Message-ID: <LxLC-XfoNffauL9vqHjio54aYcWmJNoF87n2EYXWaDA=.8fdb04fd-adbd-42e2-afab-b09f3f1fb4c8@github.com>

On Mon, 28 Jul 2025 05:21:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/oops/compressedKlass.cpp
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/hotspot/share/cds/archiveHeapLoader.hpp line 32:
> 
>> 30: #include "memory/allStatic.hpp"
>> 31: #include "memory/memRegion.hpp"
>> 32: #include "oops/compressedKlass.hpp"
> 
> Not obvious why this is needed.

This is a remnant, I'll remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2234843429

From kbarrett at openjdk.org  Mon Jul 28 06:33:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 28 Jul 2025 06:33:54 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox
In-Reply-To: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
Message-ID: <_lYqxXso1Bi648mrXunKgsHMPi9FT1ATnSKS8c92Pq8=.98b442d1-4f0c-457c-a581-9e3debc00061@github.com>

On Fri, 25 Jul 2025 07:34:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/prims/whitebox.cpp line 2734:

> 2732: WB_ENTRY(void, WB_ControlledCrash(JNIEnv* env, jobject o, jint how))
> 2733: #ifdef ASSERT
> 2734:   DEBUG_ONLY(VMError::controlled_crash(how);)

`DEBUG_ONLY` wrapping isn't needed here, since we're in `#ifdef ASSERT` context.

test/lib/jdk/test/whitebox/WhiteBox.java line 564:

> 562: 
> 563:   // Force a controlled crash (debug builds only)
> 564:   public native void controlledCrash(int how);

Please put this somewhere other than in the middle of GC & reference processing related functions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26472#pullrequestreview-3060602512
PR Review Comment: https://git.openjdk.org/jdk/pull/26472#discussion_r2234846750
PR Review Comment: https://git.openjdk.org/jdk/pull/26472#discussion_r2234855579

From sspitsyn at openjdk.org  Mon Jul 28 06:35:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 28 Jul 2025 06:35:42 GMT
Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired [v7]
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <YIzeWbZKmAx1exVYGZNJ3QyRjmQBzenFWS7J04-EudM=.ed9387e2-a9c2-4352-a031-ae22512b26d3@github.com>

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

Serguei Spitsyn 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
 - Merge
 - Merge
 - review: replace RESERVED flag with UNUSED
 - review: keep right order of the obsoleted VM options
 - corrected one assert message
 - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26232/files
  - new: https://git.openjdk.org/jdk/pull/26232/files/80fc70ec..0edab914

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=05-06

  Stats: 14768 lines in 435 files changed: 7261 ins; 5653 del; 1854 mod
  Patch: https://git.openjdk.org/jdk/pull/26232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232

PR: https://git.openjdk.org/jdk/pull/26232

From stuefe at openjdk.org  Mon Jul 28 06:46:28 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 06:46:28 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
Message-ID: <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>

> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Feedback kim

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26472/files
  - new: https://git.openjdk.org/jdk/pull/26472/files/c5542489..883affc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26472&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26472&range=00-01

  Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26472/head:pull/26472

PR: https://git.openjdk.org/jdk/pull/26472

From stuefe at openjdk.org  Mon Jul 28 06:46:28 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 06:46:28 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <_lYqxXso1Bi648mrXunKgsHMPi9FT1ATnSKS8c92Pq8=.98b442d1-4f0c-457c-a581-9e3debc00061@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
 <_lYqxXso1Bi648mrXunKgsHMPi9FT1ATnSKS8c92Pq8=.98b442d1-4f0c-457c-a581-9e3debc00061@github.com>
Message-ID: <OFIvrjdm-wGBZUZSpGweQWoDUde1cJIoIWdT25_3_lA=.7013415f-f219-46bd-9d2d-5c943026e9d1@github.com>

On Mon, 28 Jul 2025 06:30:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback kim
>
> Changes requested by kbarrett (Reviewer).

@kimbarrett Thanks for the review. Done.

> src/hotspot/share/prims/whitebox.cpp line 2734:
> 
>> 2732: WB_ENTRY(void, WB_ControlledCrash(JNIEnv* env, jobject o, jint how))
>> 2733: #ifdef ASSERT
>> 2734:   DEBUG_ONLY(VMError::controlled_crash(how);)
> 
> `DEBUG_ONLY` wrapping isn't needed here, since we're in `#ifdef ASSERT` context.

Thanks, that was a remnant from an earlier version. Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26472#issuecomment-3125755944
PR Review Comment: https://git.openjdk.org/jdk/pull/26472#discussion_r2234896069

From stuefe at openjdk.org  Mon Jul 28 07:09:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 07:09:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
Message-ID: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>

On Sun, 27 Jul 2025 10:02:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add emit_event_shutdown

Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3060786131

From mbaesken at openjdk.org  Mon Jul 28 07:20:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Jul 2025 07:20:54 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
 <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>
Message-ID: <7mFDLTicIzcbaQtIUEfPS-clHQaaRFkgxPGDUNMU2zo=.f438c388-6a07-4fee-965c-1d045955d6ed@github.com>

On Mon, 28 Jul 2025 06:46:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback kim

Might be nicer to have constants for the crash cases with self explaining names, like 2 ->  CRASH_GUARANTEE but this can be done in a follow up if desired.

-------------

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26472#pullrequestreview-3060839003

From stuefe at openjdk.org  Mon Jul 28 07:44:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 07:44:58 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <7mFDLTicIzcbaQtIUEfPS-clHQaaRFkgxPGDUNMU2zo=.f438c388-6a07-4fee-965c-1d045955d6ed@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
 <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>
 <7mFDLTicIzcbaQtIUEfPS-clHQaaRFkgxPGDUNMU2zo=.f438c388-6a07-4fee-965c-1d045955d6ed@github.com>
Message-ID: <ifMi8o69ThvGNa7VH15gzIRoWxkiC1722xn9CZt8l4Y=.6380cd51-b8fc-4e3e-8a09-0cf51e3b84db@github.com>

On Mon, 28 Jul 2025 07:18:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Might be nicer to have constants for the crash cases with self explaining names, like 2 -> CRASH_GUARANTEE but this can be done in a follow up if desired.

True, that is a long-standing issue though. Something for a separate RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26472#issuecomment-3125946537

From mhaessig at openjdk.org  Mon Jul 28 08:04:56 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 28 Jul 2025 08:04:56 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v2]
In-Reply-To: <zhsVj2bFJUQKJE5H8BCEYpAxZFz0zWFAboMFELJmLjM=.2e0d60c7-aa63-4d51-b6a5-7aa9abfc5583@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <APMvkDU_bhQ8SqyFBzPZCSGGxM9BnR1Og4auXT_vY5Y=.32cee6a6-2da8-41bd-b9d2-ae6b6ed4461d@github.com>
 <Ofr8HKJffGBPcsNqHVYHUXBlAbz9H3ByzY34XeYniNw=.706f6d1c-f33c-4dff-b94f-79c563e0c2fe@github.com>
 <zhsVj2bFJUQKJE5H8BCEYpAxZFz0zWFAboMFELJmLjM=.2e0d60c7-aa63-4d51-b6a5-7aa9abfc5583@github.com>
Message-ID: <5AHjMamXpJNedikYebcuP6DhN7NM5Vg5xJgxDnxcV-s=.34299053-9cc9-4035-bcb0-0d23e521162b@github.com>

On Thu, 24 Jul 2025 19:03:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 847:
>> 
>>> 845: 
>>> 846: #ifndef PRODUCT
>>> 847: #ifdef ASSERT
>> 
>> Why is both `NOT_PRODUCT` and `ASSERT` needed here? So far, I thought that `ASSERT` implies `NOT_PRODUCT`.
>
> Unfortunately, they are not the same, thanks to "optimized" builds.  We can clean this up if optimizes builds get removed.  See https://bugs.openjdk.org/browse/JDK-8183287.

Ah, "optimized" is with neither `ASSERT` nor `PRODUCT` defined. Makes sense now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2235198526

From mhaessig at openjdk.org  Mon Jul 28 08:36:55 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 28 Jul 2025 08:36:55 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
Message-ID: <_gJoTNnBpV2Y2ENO9s153NWZeq_ujs40-zoyuZstOqM=.69d1d039-5022-4beb-ae79-7fc4193f3a11@github.com>

On Thu, 24 Jul 2025 20:03:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readability suggestion

Thank you for addressing my comments. I have done another pass and it looks good to me.

-------------

Marked as reviewed by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26121#pullrequestreview-3061222726

From egahlin at openjdk.org  Mon Jul 28 08:57:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 28 Jul 2025 08:57:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <lrozX0_OMkpUOjJVYwqPDKY6GaBpzgwaPvNZYx03dXw=.e9de80fc-50f8-439c-900b-fd62d48b80db@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

It might be better to have a test in test/jdk/jdk/jfr/jvm/, where we have other crash tests.

It's probably best to create a separate test for this, as checking for OOM can be flaky, and it may need to be added to the ProblemList separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3126226149

From tschatzl at openjdk.org  Mon Jul 28 09:12:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 09:12:53 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v45]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <XXmA7QD5fE0Dbv8OtC5xjWw3PhHAnmgBqOh0NA_ftf4=.fbf19b93-d6ab-4efb-a6c4-28681595287c@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - ... and 52 more: https://git.openjdk.org/jdk/compare/bdc1ef20...23aa2c8b

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=44
  Stats: 7123 lines in 112 files changed: 2588 ins; 3593 del; 942 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From vyazici at openjdk.org  Mon Jul 28 09:36:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:36:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
Message-ID: <7pEtXtLj_rHcJb_-M1FNge1GhM48UoW0ZMHhI44HH-w=.5401889c-3613-4cc6-aef6-52266066b821@github.com>

On Fri, 25 Jul 2025 07:40:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` methods<sup>1</sup> (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446)
>> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too
>> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method
>> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag
>> 
>> Following preliminary work needs to be carried out as well:
>> 
>> 1. Add a new `VerifyIntrinsicChecks` VM flag
>> 2. Update `generate_string_range_check` to produce a `HaltNode`.  That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input.
>> 
>> <sup>1</sup>  `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case.
>> 
>> ## Functional and performance tests
>> 
>> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback.
>> 
>> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments.
>> 
>> ## Verification of the VM crash
>> 
>> I've tested the VM crash scenario as follows:
>> 
>> 1. Created the following test program:
>> 
>> public class StrIntri {
>>     public static void main(String[] args) {
>>         Exception lastException = null;
>>         for (int i = 0; i < 1_000_000; i++) {
>>             try {
>>                 jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5);
>>             } catch (Exception exception) {
>>                 lastException = exception;
>>             }
>>         }
>>         if (lastException != null) {
>>             lastException.printStackTrace...
>
> Volkan Yazici 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 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds
>  - Fix bit shifting
>  - Remove superseded `@throws` Javadoc
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/8888d41d...c322f0e0

Status update:

* Changes are pretty-much settled. I'm waiting for a final review from @cl4es.
* Checked the performance impact of changes against [DaCapo](https://www.dacapobench.org/) BioJava, and `org.openjdk.bench.java.lang.String{En,De}code` benchmarks on several platforms. Spotted one consistent significant (i.e., >2%) regression: `StringDecode::decodeShortMixed` ? explicitly forcing inlining<sup>1</sup> did not help either. Granted this is the only, and benchmark- and platform-specific regression, @RogerRiggs suggested creating a follow-up ticket for this particular regression and integrating this PR. I will wait for input from @cl4es.

<sup>1</sup> `-XX:CompileCommand=inline,java.lang.StringCoding::encodeISOArray -XX:CompileCommand=inline,java.lang.StringCoding::encodeAsciiArray`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3126372979

From shade at openjdk.org  Mon Jul 28 10:51:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 10:51:11 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
Message-ID: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>

> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
> 
> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>  - [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:

  Better comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26477/files
  - new: https://git.openjdk.org/jdk/pull/26477/files/bc853287..40761ecc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26477&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26477&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26477/head:pull/26477

PR: https://git.openjdk.org/jdk/pull/26477

From shade at openjdk.org  Mon Jul 28 10:51:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 10:51:11 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <ayKiM0IiwD0anfU-BXp11rJXzghwX0YGLbx0Wvdzlos=.06719ac8-3936-44af-9af0-593bfcbe1b48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <R-kXy3eXQiuJ0MdhH987HUQOmRnYZxmGzLCZIfl3Nb4=.d77e800e-05f6-44f7-adb9-a164426fff11@github.com>
 <RJWSWhCMJwIEWlQE6FAB8kMf6oKTfJKoIgspZ3f1NkM=.a65cd50e-d077-4c68-ab1a-55a1648ecf13@github.com>
 <ANJ-dXebxOOWbPyaOnseOpOPNaYpy_hMOUyH1EFby88=.b6534c28-f91b-4327-b897-9261d96afede@github.com>
 <od7_tN-iw2MSbV3PpNrUK3fpazZuLP_-xxL-Z_U9qhg=.c52d19d6-6d3b-450d-89fc-8dfa9da0f8be@github.com>
 <7ESr0Fa5H-yDf0lpEXCw_ljWScn5egD1COLOl_2yT3A=.1bc0fcda-1ada-48ce-b485-efa171fe5877@github.com>
 <ayKiM0IiwD0anfU-BXp11rJXzghwX0YGLbx0Wvdzlos=.06719ac8-3936-44af-9af0-593bfcbe1b48@github.com>
Message-ID: <yU3SJtoqcYDCYiR54QHw-Wd4gjuMzqr7l5x2uPM5u9A=.4de59707-5798-463d-a8b6-96332d892704@github.com>

On Fri, 25 Jul 2025 17:08:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Pretty exhausted at this point, I'll mull over it after the weekend. But so far I think we are fine. Testing returns clean as well. If you can schedule some aggressive testing over the weekend, it would be helpful.
>
> Wait, it's actually the other way around: we can see `nullptr` it our explicit check for a non-primitive class, stall, get to the assert, _then_ discover that mirror is installed, and falsely fail the assert. Assert *needs* to be removed, did so in new commit. This also matches current behavior better.

Yes, I believe what we have now is correct. We cannot do anything here if Klass* backlink is not yet installed, and GC code needs to handle it separately. I think all GCs already do by e.g. keeping newly allocated classes alive. I polished the comment a bit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2235837704

From ysuenaga at openjdk.org  Mon Jul 28 12:02:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 12:02:47 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/6cf417d8..5ecd4e43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=02-03

  Stats: 111 lines in 1 file changed: 111 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From ysuenaga at openjdk.org  Mon Jul 28 12:07:55 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 12:07:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <1vsjp_sMv3syJEfZWC-yp0mGUwkPyaCfEuL7QKqO0Zw=.7ad75bf3-b257-4fb5-a700-f08bce99a3aa@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add emit_event_shutdown
>
> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

@tstuefe @egahlin 

Thanks for your review and advice!
I added testcase in `test/jdk/jdk/jfr/event/oldobject` because this change is not only crash handler. `before_exit()` calls if OOM happens without `CrashOnOutOfMemoryError`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3126917501

From jsikstro at openjdk.org  Mon Jul 28 12:27:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 12:27:55 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v2]
In-Reply-To: <LpS-8VUiz_jUIWh11mrUCalpa2p_tYfJnEk4-HNvRgI=.993869cb-6296-4cff-9e2b-60a7b6b79774@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <LpS-8VUiz_jUIWh11mrUCalpa2p_tYfJnEk4-HNvRgI=.993869cb-6296-4cff-9e2b-60a7b6b79774@github.com>
Message-ID: <5EOBa4Ln_zybnk-P3s34UxzaB0ahB-1xKL2QMTvuelA=.7635ec72-568d-44e3-98d1-a08123d7e4cc@github.com>

On Wed, 25 Jun 2025 11:19:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
>> 
>> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
>> 
>> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
>> 
>> Testing:
>> * Oracle's tier1-2
>
> Joel Sikstr?m 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8360515_properfmtargs
>  - 8360515: PROPERFMTARGS should always use size_t template specialization for unit

Ping to see if anyone has time to spare reviewing this :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25975#issuecomment-3126996038

From jsikstro at openjdk.org  Mon Jul 28 12:42:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 12:42:40 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v3]
In-Reply-To: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
Message-ID: <-SGVDxJH_y3l8WTIfQl2JdCPCUY02P9qP8b0bwtcAUo=.fd70a0f2-4240-4c53-b417-f388b7121389@github.com>

> Hello,
> 
> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
> 
> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
> 
> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
> 
> Testing:
> * Oracle's tier1-2

Joel Sikstr?m 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 branch 'master' into JDK-8360515_properfmtargs
 - Merge branch 'master' into JDK-8360515_properfmtargs
 - 8360515: PROPERFMTARGS should always use size_t template specialization for unit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25975/files
  - new: https://git.openjdk.org/jdk/pull/25975/files/0d51cb39..1c1ce1cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=01-02

  Stats: 56555 lines in 1666 files changed: 31296 ins; 15611 del; 9648 mod
  Patch: https://git.openjdk.org/jdk/pull/25975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25975/head:pull/25975

PR: https://git.openjdk.org/jdk/pull/25975

From stuefe at openjdk.org  Mon Jul 28 12:49:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 12:49:38 GMT
Subject: RFR: 8364169: (NMT) Move nativeCallStack to nmt
Message-ID: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>

Trivial file move of NativeCallStack to the `nmt` sub directory.

-------------

Commit messages:
 - start

Changes: https://git.openjdk.org/jdk/pull/26498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364169
  Stats: 54 lines in 21 files changed: 20 ins; 20 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26498/head:pull/26498

PR: https://git.openjdk.org/jdk/pull/26498

From jsikstro at openjdk.org  Mon Jul 28 12:50:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 12:50:31 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v4]
In-Reply-To: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
Message-ID: <w4JtkTNGihjxJlUBb_YvVHGK57P2g4QRBFv-GkoHQL0=.07f556e7-83be-44dc-b778-aa3bd229524c@github.com>

> Hello,
> 
> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
> 
> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
> 
> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
> 
> Testing:
> * Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  More consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25975/files
  - new: https://git.openjdk.org/jdk/pull/25975/files/1c1ce1cd..de360885

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25975/head:pull/25975

PR: https://git.openjdk.org/jdk/pull/25975

From jsikstro at openjdk.org  Mon Jul 28 12:50:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 12:50:31 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v2]
In-Reply-To: <szNZsZxs5GcVCrAl4EnLTiIS5zK0GMtHvBhkVeBpxyc=.42570767-7fc9-4f57-90fb-2d38ecd94226@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <LpS-8VUiz_jUIWh11mrUCalpa2p_tYfJnEk4-HNvRgI=.993869cb-6296-4cff-9e2b-60a7b6b79774@github.com>
 <czAGqGZFm23v8c6UXWvezctY7cojS67qzQhgogogKg8=.1caf3f22-129c-400d-8dbe-c7d082f1882c@github.com>
 <A2AhIC9LTO0w0sWxNOsywodWFEmgTq1TJ7HxCM7Zsxk=.ab5690a3-859e-4e13-a60f-46bc176c21a8@github.com>
 <szNZsZxs5GcVCrAl4EnLTiIS5zK0GMtHvBhkVeBpxyc=.42570767-7fc9-4f57-90fb-2d38ecd94226@github.com>
Message-ID: <1m5g17T0vEe4_p4AZFRgwFUNYK_UBrlno0DmVwU-2SI=.15fab87e-916b-455f-bc50-ec6a67deffb7@github.com>

On Thu, 26 Jun 2025 23:48:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I originally wanted this patch to be minimally invasive and just fix the mismatch between PROPERFMT and PROPERFMTARGS. The cast to size_t wasn't added by me, I just changed the format specifier to match the type in PROPERFMTARGS. I agree that it looks a bit weird to have both the expanded macro and PROPERFMTARGS next to each other, and I'm not 100% sure why vm_info.page_size is casted to size_t.
>> 
>> I'm fine with making the usage consistent in this patch, making all the prints use PROPERFMT+PROPERFMTARGS with casts to size_t, or the other way around using the expanded macro.
>
> Sorry for mis-attributing the cast to your change. This could go either way with no way clearly better than the other. Lets see if another reviewer has a strong opinion.

To get this moving I opted to replace the cast with expanded PROPERFMT+PROPERFMTARGS. If someone feels strongly for the other alternative, I'm open to that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25975#discussion_r2236294798

From mli at openjdk.org  Mon Jul 28 12:59:55 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 28 Jul 2025 12:59:55 GMT
Subject: RFR: 8364120: RISC-V: unify the usage of
 MacroAssembler::instruction_size
In-Reply-To: <4uqTw8ShfJydps-v3nCote6jQGt28TsOYyxAT6PW8aI=.453c3ea5-3cdf-4277-af27-f5a4201b3098@github.com>
References: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>
 <4uqTw8ShfJydps-v3nCote6jQGt28TsOYyxAT6PW8aI=.453c3ea5-3cdf-4277-af27-f5a4201b3098@github.com>
Message-ID: <UOsodnD2STGrNGJJdz-FwEp1gVKTNdP2CmrMD6DVXqw=.33520384-d24d-49df-a1ac-d70c46d5239f@github.com>

On Mon, 28 Jul 2025 03:55:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Looks fine. Thanks.

Thank you!

I think this is a trvial patch, I'll just push it in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26481#issuecomment-3126155312

From mli at openjdk.org  Mon Jul 28 13:03:04 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 28 Jul 2025 13:03:04 GMT
Subject: Integrated: 8364120: RISC-V: unify the usage of
 MacroAssembler::instruction_size
In-Reply-To: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>
References: <o7NjE8OdyPaMrCzxs5S7JXvjNnVDwdPaCfVTGIOsGHg=.88fff1fd-9aaf-4cdc-a970-53889e1e9a3a@github.com>
Message-ID: <9xQa1vqEcr9JtnxwY2VIR6wvMLw22pYhBiOJ335LUMY=.0a462209-a67c-4b1e-9398-d7b8940e7b23@github.com>

On Fri, 25 Jul 2025 14:00:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple cleanup?
> 
> in MacroAssembler, some magic number 4 is used for MacroAssembler::instruction_size. We should not use magic number if possible.
> This pr also replaces all the usage of  `instruction_size` with `MacroAssembler::instruction_size`.
> 
> Thanks

This pull request has now been integrated.

Changeset: 7bf4c608
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7bf4c608e7b23398ea89cf0a592e9554af98144e
Stats:     38 lines in 2 files changed: 0 ins; 0 del; 38 mod

8364120: RISC-V: unify the usage of MacroAssembler::instruction_size

Reviewed-by: fyang

-------------

PR: https://git.openjdk.org/jdk/pull/26481

From duke at openjdk.org  Mon Jul 28 13:10:36 2025
From: duke at openjdk.org (Manjunath S Matti.)
Date: Mon, 28 Jul 2025 13:10:36 GMT
Subject: RFR: 8359114: [s390x] Add z17 detection code [v4]
In-Reply-To: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
References: <DlBAuHRf1_-OCJE9QX4Zd8fbZt-lC4RknzHqK7Mn1a8=.6a27af24-7b5f-4da7-85f4-aba7ae6ffce7@github.com>
Message-ID: <pyCDb8oIkw2ibUUwiSAF8FQIX6KNIpyz0woFKkH8wWk=.1c5640a3-054a-4e07-a052-6dd0e23d4e02@github.com>

> Add support to detect the new generation of Z machine (z17).

Manjunath S Matti. has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Update full name
 - Correct the comments for the bits covered in DW[2] and DW[3].
 - Add support to detect the new generation of Z machine (z17).

-------------

Changes: https://git.openjdk.org/jdk/pull/25718/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25718&range=03
  Stats: 21 lines in 2 files changed: 12 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25718/head:pull/25718

PR: https://git.openjdk.org/jdk/pull/25718

From jsikstro at openjdk.org  Mon Jul 28 13:35:14 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 13:35:14 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v5]
In-Reply-To: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
Message-ID: <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>

> Hello,
> 
> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
> 
> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
> 
> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
> 
> Testing:
> * Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:

 - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp
 - Other alternative

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25975/files
  - new: https://git.openjdk.org/jdk/pull/25975/files/de360885..56b0505b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=03-04

  Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25975/head:pull/25975

PR: https://git.openjdk.org/jdk/pull/25975

From jsjolen at openjdk.org  Mon Jul 28 14:02:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 28 Jul 2025 14:02:56 GMT
Subject: RFR: 8364169: (NMT) Move nativeCallStack to nmt
In-Reply-To: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
References: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
Message-ID: <6whLMyqmDLfl7gvjFakgJpAZDrOZv_nsQRY4Trqc3Mw=.30a8b1ae-dd80-4e08-ad9b-52f3e94dbea8@github.com>

On Mon, 28 Jul 2025 08:37:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial file move of NativeCallStack to the `nmt` sub directory.

LGTM, but I want two reviews (in case someone disagrees with the move).

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26498#pullrequestreview-3062917169

From stuefe at openjdk.org  Mon Jul 28 14:17:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 14:17:58 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v5]
In-Reply-To: <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
Message-ID: <pK_T_zqDJ8LdJjUaTfwZPfBrJ7TFr-Ik8VdwxwxSAH0=.309aac03-3281-4651-9aa0-539f394a0496@github.com>

On Mon, 28 Jul 2025 13:35:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
>> 
>> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
>> 
>> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
>> 
>> Testing:
>> * Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp
>  - Other alternative

Why is the cast needed, now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25975#issuecomment-3127441128

From rkennke at openjdk.org  Mon Jul 28 14:31:58 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 28 Jul 2025 14:31:58 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
Message-ID: <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>

On Mon, 28 Jul 2025 06:31:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray include

Looks reasonable to me, I just have some questions below.

src/hotspot/cpu/arm/c1_FrameMap_arm.hpp line 99:

> 97:   static int adjust_reg_range(int range) {
> 98:     return range;
> 99:   }

This looks to me like the whole method could be removed?

src/hotspot/share/classfile/classLoaderDataShared.hpp line 46:

> 44:   static void serialize(SerializeClosure* f);
> 45:   static void clear_archived_oops();
> 46: #if INCLUDE_CDS_JAVA_HEAP

Why is this needed?

src/hotspot/share/memory/universe.cpp line 912:

> 910: 
> 911: #if INCLUDE_CDS
> 912: #if INCLUDE_CDS_JAVA_HEAP

I guess this is related to the Q above. But why is it relevant?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26491#pullrequestreview-3062995609
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2236671932
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2236682858
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2236690253

From stuefe at openjdk.org  Mon Jul 28 14:31:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 14:31:59 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
Message-ID: <vVlqjqQwo8uNAVPSmsVzi6cn-QNhIYcVrByXnuHt2Xs=.bd8be576-98cd-47d8-a7ee-f1b44e3af22c@github.com>

On Mon, 28 Jul 2025 14:14:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray include
>
> src/hotspot/cpu/arm/c1_FrameMap_arm.hpp line 99:
> 
>> 97:   static int adjust_reg_range(int range) {
>> 98:     return range;
>> 99:   }
> 
> This looks to me like the whole method could be removed?

Possibly; but I wanted to keep the change to a minimum. There will be a larger cleanup coming when UseCompressedClassPointers gets removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2236731141

From jsikstro at openjdk.org  Mon Jul 28 14:39:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 28 Jul 2025 14:39:56 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v5]
In-Reply-To: <pK_T_zqDJ8LdJjUaTfwZPfBrJ7TFr-Ik8VdwxwxSAH0=.309aac03-3281-4651-9aa0-539f394a0496@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
 <pK_T_zqDJ8LdJjUaTfwZPfBrJ7TFr-Ik8VdwxwxSAH0=.309aac03-3281-4651-9aa0-539f394a0496@github.com>
Message-ID: <l6vtCTvCPh7CuuZ31E3HpXLa7FX1gobh6GJoMW4QDKQ=.844397ff-0904-450c-9380-52264604a80a@github.com>

On Mon, 28 Jul 2025 14:15:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why is the cast needed, now?

It isn't strictly needed, but IMO is better than implicitly converting from the underlying types (mach_vm_size_t, which is uint64_t) to size_t. vm.page_size must be converted from its original int to size_t explicitly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25975#issuecomment-3127539841

From duke at openjdk.org  Mon Jul 28 14:41:25 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 28 Jul 2025 14:41:25 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
Message-ID: <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>

> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes tier1.

Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8364115
 - sort includes

-------------

Changes: https://git.openjdk.org/jdk/pull/26483/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26483&range=01
  Stats: 42 lines in 12 files changed: 22 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26483/head:pull/26483

PR: https://git.openjdk.org/jdk/pull/26483

From mbaesken at openjdk.org  Mon Jul 28 15:15:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Jul 2025 15:15:17 GMT
Subject: RFR: 8364199: Enhance list of environment variables printed in
 hserr/hsinfo file
Message-ID: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>

We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file.
JAVA_OPTS is used by lots of tools .
WAYLAND_DISPLAY and JDK_AOT_VM_OPTIONS are referenced in the codebase.

-------------

Commit messages:
 - JDK-8364199

Changes: https://git.openjdk.org/jdk/pull/26509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364199
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26509/head:pull/26509

PR: https://git.openjdk.org/jdk/pull/26509

From rkennke at openjdk.org  Mon Jul 28 15:21:55 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 28 Jul 2025 15:21:55 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <vVlqjqQwo8uNAVPSmsVzi6cn-QNhIYcVrByXnuHt2Xs=.bd8be576-98cd-47d8-a7ee-f1b44e3af22c@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
 <vVlqjqQwo8uNAVPSmsVzi6cn-QNhIYcVrByXnuHt2Xs=.bd8be576-98cd-47d8-a7ee-f1b44e3af22c@github.com>
Message-ID: <0yYP0GJXQUrRpJmD5R3tCdvF1IjOgDQnTFzUR-yer8g=.f005ff56-2ce8-4c2e-92f8-c707f19aef1a@github.com>

On Mon, 28 Jul 2025 14:28:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/arm/c1_FrameMap_arm.hpp line 99:
>> 
>>> 97:   static int adjust_reg_range(int range) {
>>> 98:     return range;
>>> 99:   }
>> 
>> This looks to me like the whole method could be removed?
>
> Possibly; but I wanted to keep the change to a minimum. There will be a larger cleanup coming when UseCompressedClassPointers gets removed.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2236918724

From aph at openjdk.org  Mon Jul 28 16:12:10 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 28 Jul 2025 16:12:10 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
In-Reply-To: <LIUOM-VNoW8EAXtu9EmF9hXfE7nWuNrN2zHs_2_ti5o=.4976c619-dfbd-40e5-a167-d72f9762b12f@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <vx-WDBv_anhsYWBkvUbtQzsGzKXDgUknwRg17BpQzPQ=.c20c4309-d73f-4629-b381-23cc58a1c09a@github.com>
 <7AIC7kPYWB133weIDM4wtwDat4H4dfuNqH_alS5wkh4=.f9aa934d-689c-4991-86af-7d61fc4d12d3@github.com>
 <-IINGwsF992Al0naVREDpvE6nE6FamJ1EOIoIB3aEK0=.65daa4d8-af68-4376-a210-5826879d24ed@github.com>
 <LIUOM-VNoW8EAXtu9EmF9hXfE7nWuNrN2zHs_2_ti5o=.4976c619-dfbd-40e5-a167-d72f9762b12f@github.com>
Message-ID: <dXUb68Q54g89PRM9kr_c6HDsPuT9-_ou_MBbAey1GqY=.5e76165f-42ad-428c-9345-e0fdcc192e96@github.com>

On Fri, 25 Jul 2025 19:43:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> In Apple Silicon CPU Optimization Guide I found M4 supports FEAT_SB (Armv8.5-A), FEAT_ECV (Armv8.6-A) and FEAT_WFxT (Armv8.7-A). I will try to get access to it to test the implementation.

Unfortunately, it seems that Apple silicon runs the Arm Generic Timer at 24 Mhz, which I suspect is much too coarse for this use. It might work, but if it doesn't we could use the same algorithm with a spin loop.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3127956749

From aph at openjdk.org  Mon Jul 28 16:17:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 28 Jul 2025 16:17:57 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
Message-ID: <QDrf7Yi7bSnsR3FmBDO4-lPpvdps6ny9kAgGAceRw-Q=.ea5bf5de-c54c-4913-94c3-5c0da8e0927f@github.com>

On Mon, 28 Jul 2025 06:31:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray include

src/hotspot/share/oops/compressedKlass.cpp line 56:

> 54:   // Klass pointers here, coding needs to be revised.
> 55:   // We keep one page safety zone free to guard against size_t overflows on 32-bit. In practice
> 56:   // this is irrelevant, since these upper address space parts are not user-addressable on

Suggestion:

  // this is irrelevant because these upper address space parts are not user-addressable on

Reason: correlation is not causation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2237134166

From aph at openjdk.org  Mon Jul 28 16:20:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 28 Jul 2025 16:20:54 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
Message-ID: <9-fVlgJ0rY7pDb92eZI3WgqzupdlZGCKWf2ln3NOvEk=.e18d3cab-d91b-4d95-8e08-fc1e9a578129@github.com>

On Mon, 28 Jul 2025 06:31:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray include

Very nice! That's come out a lot cleaner than I was expecting.

Building and testing on a Raspberry Pi must have been fun. Not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26491#issuecomment-3128003799

From eastigeevich at openjdk.org  Mon Jul 28 16:33:07 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 28 Jul 2025 16:33:07 GMT
Subject: RFR: 8362193: Re-work MacOS/AArch64 SpinPause to handle SB [v3]
In-Reply-To: <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
References: <U7qmFJic0ZaAqwJpEqjFB6DTGmBrv4ZaZVw1fCNrSLQ=.eac5f558-796c-4573-be61-d45b2faf531b@github.com>
 <5ascwreZnuJZZJ5IctvJrpAkwUo3gS2T1RtSfAdbbMg=.f2cba477-3f2a-402d-bb45-f5685e0beb8a@github.com>
Message-ID: <ViuAz1KTt31Vu7AClFeMyOhFCjB6qWKagqQJ3R7yZpA=.f1a2cb84-dcce-4b87-9092-868c833a6caf@github.com>

On Mon, 21 Jul 2025 20:31:27 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> ### Background
>> 
>> With JDK-8359435 "AArch64: add support for SB instruction to MacroAssembler::spin_wait" we have an option to use the speculation barrier (SB) instruction for `j.l.Thread::onSpinWait` and `SpinPause`. On Linux AArch64 `SpinPause` uses a stub which is generated  with `MacroAssembler::spin_wait`. `j.l.Thread::onSpinWait` uses it as well. As a result tests for `j.l.Thread::onSpinWait`, e.g.`compiler/onSpinWait/TestOnSpinWaitAArch64.java`, cover both `j.l.Thread::onSpinWait` and `SpinPause`. Also we don't need to update `SpinPause` when we add support for a new instruction to `MacroAssembler::spin_wait`.
>> 
>> On Mac AArch64 `SpinPause` does not use the generated stub to  avoid a costly call to `os::current_thread_enable_wx()`. It uses inline assembly instead. As a result we have `SpinWait` implementation details leaking into `SpinPause`. Besides asserts there are no tests covering Mac implementation of `SpinPause`. Testing on Apple M3 Pro showed that `compiler/onSpinWait/TestOnSpinWaitAArch64.java` could not reliably trigger those asserts. `ArchiveWorkers::run_task_multi` did not invoke `spin.wait()`. The inline assembly in Mac AArch64 `SpinPause` has another issue. It uses a jump table. An offset in the table is calculated based on the value of `enum SpinWait::Inst`. When a new value `SB` was added the offset became out of bounds. The jump goes out of the assembly code.
>> 
>> ### Summary of changes
>> 
>> * Rewrote Mac AArch64 `SpinPause` not to use a jump table.
>> * Added `SpinWait::supports()` and `SpinWait::from_name()` methods to validate and convert instruction names into corresponding enum values.
>> * Updated `SpinWait::Inst` enum to use bit flags for simplified assembly testing and added a constructor to initialize `SpinWait` using instruction names.
>> * `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`: Added an assertion to ensure the `sb` instruction is supported by the CPU before generation.
>> * Added `OnSpinWaitInstNameConstraintFunc` for the `OnSpinWaitInst` option to check option's value at parsing.
>> * Added a gtest to verify the functionality of `SpinPause`.
>> * Added a jtreg test to run the gtest for`SpinPause` with various instructions, including the `sb` instruction if supported by the CPU.
>> 
>> ### Testing results: fastdebug, release
>> 
>> - Linux, Graviton 2
>>    - tier1: Passed
>>    - `test/hotspot/jtreg/gtest/TestSpinPauseAArch64.java`: Passed
>>    - `test/hotspot/jtreg/compiler/onSpinWait`: Passed
>> - MacOS, M3 Pro
> ...
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put cases in enum order

At least we can test armv8.7 and armv9.2 features on M4.  The next Neoverse supporting armv9.2 will be N3/V3. Taking into account Neoverse N2/V2 hardware is quite fresh, we might not seen N3/V3 hardware soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26387#issuecomment-3128052931

From adinn at openjdk.org  Mon Jul 28 16:44:06 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 28 Jul 2025 16:44:06 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached code
 stubs
Message-ID: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>

Array copy stubs may legitimately generate SEGV errors during copying. They rely on class UnsafeMemoryAccess to record and expose to the signal handler a table of address ranges within which a SEGV should be dealt with by redirecting execution to an associated handler address. The handler address may lie within the same stub or may default to an independent entry belonging to a specific, non-copy stub within the same blob. Normally entries are added to the table as a side-effect of generating the stub.

This patch implements the preliminary steps needed to enable save and restore of the UnsafeMemoryAccess table entries alongside with their associated AOT compiled copy stubs. It adds the common entry to the entry declarations list so it can be saved to the AOT cache during the assembly phase and reloaded, relocated and installed as the table default entry during a production run. It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.

-------------

Commit messages:
 - enable tracking of unsafe memory ranges and handlers in copy stubs

Changes: https://git.openjdk.org/jdk/pull/26511/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364042
  Stats: 42 lines in 4 files changed: 40 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26511/head:pull/26511

PR: https://git.openjdk.org/jdk/pull/26511

From aph at openjdk.org  Mon Jul 28 16:53:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 28 Jul 2025 16:53:54 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs
In-Reply-To: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
Message-ID: <ckUCrN48RS7-oBNLktWagIH8S_fs97rsen91_QX-weo=.9d0d7166-a0ae-476c-8783-06ce84e485ef@github.com>

On Mon, 28 Jul 2025 16:38:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.

I guess there's no way to test this contribution because the API has no customers, but you'll submit such testing as necessary in a later PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26511#issuecomment-3128130260

From egahlin at openjdk.org  Mon Jul 28 16:54:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 28 Jul 2025 16:54:00 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add emit_event_shutdown
>
> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

> @tstuefe @egahlin
> 
> Thanks for your review and advice! I added testcase in `test/jdk/jdk/jfr/event/oldobject` because this change is not only crash handler. `before_exit()` calls if OOM happens without `CrashOnOutOfMemoryError`.

Does it also happen with -XX:ExitOnOutOfMemoryError?

I'm not sure we want that. Most users, I think, want a quick exit if they have specified that option. They are not interested in having the Java heap swept to find memory leak candidates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3128128908

From stuefe at openjdk.org  Mon Jul 28 16:55:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 16:55:04 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v5]
In-Reply-To: <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
Message-ID: <ibz6Rio4gj1y-pYcF2CoNPbMd87J9OHAs9xlogrGg8w=.8d10f348-aa3d-45fb-abf2-9749e2ff14a1@github.com>

On Mon, 28 Jul 2025 13:35:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
>> 
>> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
>> 
>> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
>> 
>> Testing:
>> * Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp
>  - Other alternative

Okay

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25975#pullrequestreview-3063778131

From asmehra at openjdk.org  Mon Jul 28 18:21:43 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 28 Jul 2025 18:21:43 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
Message-ID: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>

This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0]

[0] https://github.com/openjdk/leyden/pull/84

-------------

Commit messages:
 - 8364128: Improve gathering of cpu feature names using FormatBuffer

Changes: https://git.openjdk.org/jdk/pull/26515/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364128
  Stats: 194 lines in 10 files changed: 97 ins; 29 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/26515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26515/head:pull/26515

PR: https://git.openjdk.org/jdk/pull/26515

From sparasa at openjdk.org  Mon Jul 28 18:38:55 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Jul 2025 18:38:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
Message-ID: <sGS4YO1tkFeVCMVu_D-zTPiZPsGw8IMCEt7IeEMxRCE=.797cdce0-a0f0-4ff2-9b6f-7a3ab4223359@github.com>

On Thu, 17 Jul 2025 18:46:06 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move error bound to separate section in comment header

I reviewed the code, ran the benchmarks and correctness test and verified that it's passing. This PR looks good to me.

-------------

Marked as reviewed by sparasa (Author).

PR Review: https://git.openjdk.org/jdk/pull/26152#pullrequestreview-3064160746

From liach at openjdk.org  Mon Jul 28 19:06:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 19:06:13 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - aot safe markers for runtime setup
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Restore non-public comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Reviews
 - Documentation
 - Don't fail for patching tests
 - Remove design document from code
 - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

-------------

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=12
  Stats: 494 lines in 39 files changed: 324 ins; 150 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

PR: https://git.openjdk.org/jdk/pull/25922

From iklam at openjdk.org  Mon Jul 28 19:47:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Jul 2025 19:47:59 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
In-Reply-To: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
Message-ID: <HKhZRheRVuBFmxhp7lc1WvWjej6acdBAGuncu20_MJw=.eb22b1aa-bb6a-45ad-800f-25d433a6fc17@github.com>

On Mon, 28 Jul 2025 19:06:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - aot safe markers for runtime setup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Restore non-public comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

Updates look good to me.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3064404358

From coleenp at openjdk.org  Mon Jul 28 20:19:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 20:19:31 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
Message-ID: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>

This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
Tested with tier1-4.

-------------

Commit messages:
 - The only caller for getRawClassAccessFlags in Class.java doesn't call it for arrays so we really want the "raw" classfile access flags.
 - Add a comment
 - 8364187: Make getClassAccessFlagsRaw non-native

Changes: https://git.openjdk.org/jdk/pull/26517/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364187
  Stats: 98 lines in 16 files changed: 38 ins; 46 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From coleenp at openjdk.org  Mon Jul 28 20:44:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 20:44:55 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
Message-ID: <WhtQodL_eDBYb0dhN_7SXy-bQjcCVGiHgGjh2CNzxTU=.e4acb00c-ba71-4989-8c9d-1c8b0d08ba6b@github.com>

On Mon, 28 Jul 2025 06:31:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray include

This looks good and minimal.  Nice work!

src/hotspot/share/oops/compressedKlass.cpp line 67:

> 65:     _max_shift = max_shift_coh;
> 66:   } else {
> 67: #ifdef _LP64

It's a bit confusing when we need NEEDS_CLASS_SPACE vs. LP64.  Like here.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26491#pullrequestreview-3064564736
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2237822190

From liach at openjdk.org  Mon Jul 28 21:07:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 21:07:00 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@github.com>
Message-ID: <_daElLoa9OY4GA4XulyLPcf23-SqZ1KkEGASLxUBz_s=.f34f362b-3a84-4b03-a27d-2e5db1b078a8@github.com>

On Thu, 24 Jul 2025 06:07:31 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>>  - Reviews
>>  - Documentation
>>  - Don't fail for patching tests
>>  - Remove design document from code
>>  - Some more from reviews
>>  - Reviewed the diff on github
>>  - Stage
>>  - Missed comment updates
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b
>
> Good fix.  I added some minor comments.  No logic changes requested!
> 
> I'm a little surprised to see the second annotation has survived; I'd prefer to see it totally nuked.  But I am not asking you to remove it; there is an argument that it is helpful.  I requested better documdentation and checking that the two annotations are properly interdependent.  The "runtime setup" annotation should not be allowed except in classes marked as AOT safe.
> 
> In a few places you removed an unrelated "non-public" comment.  That is not a good cleanup to incorporate in passing, since the comment is actually functional.
> 
> If somebody is arguing that such comments are somehow detrimental, let them make a separate argument and a separate PR to purge them.

@rose00 I have re-asserted that AOTRuntimeSetup requires AOTSafeCI as a prerequisite and rolled back `/*non-public/` comment changes. Can you re-review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3129885206

From pchilanomate at openjdk.org  Mon Jul 28 21:52:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Jul 2025 21:52:55 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v3]
In-Reply-To: <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
Message-ID: <GtbOCb5llEtpthsGRW3Fqd_nMamIMhK_iRsBubqhhBs=.43b9a36c-c219-477b-a7fd-3d9163dbccd3@github.com>

On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Marked as reviewed by pchilanomate (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3064697749

From liach at openjdk.org  Mon Jul 28 22:00:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 22:00:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>

On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

src/java.base/share/classes/java/lang/Class.java line 1012:

> 1010:     private transient Object[] signers; // Read by VM, mutable
> 1011:     private final transient char modifiers;  // Set by the VM
> 1012:     private final transient char rawAccessFlags;  // Set by the VM

I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2237933184

From dcubed at openjdk.org  Mon Jul 28 22:03:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 28 Jul 2025 22:03:55 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v3]
In-Reply-To: <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
Message-ID: <lU8-__Bxq6KDgxExDlO6fyy36w5C0LfKrdo-_u-DFVY=.d56061f9-40cf-4b2b-a1fb-b0f1fd5def51@github.com>

On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Thanks for the updates. Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3064713285

From dcubed at openjdk.org  Mon Jul 28 22:03:56 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 28 Jul 2025 22:03:56 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v2]
In-Reply-To: <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <unc82i_UE83IbmGE__MCc_67qAsQ9UFHyUjgwS4B4K8=.dc6ef926-4c41-4e9b-a8ec-a4fc98e8c014@github.com>
 <XU6dP6v9oYzlN6xTh2Q9IspZL2y_IjyyPug9tb1NfAM=.715b9b4c-6499-4a22-b4af-15264d0c333a@github.com>
 <dyMpEPmdGJxhl6cZx_uWRL9qGvuNrxxhdfdHOAqs19w=.e63818e2-9a38-4904-9564-ba80a7fc6179@github.com>
 <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com>
 <hTa9nTwToaSWIcEcJsITJujDqkfNAwo14AFT0I1sSFU=.27b364af-4a72-496c-8a5e-502f256c0fe4@github.com>
 <x-Dn7cQ-d2XW6Wu8p_AkzjITU4GocDW-xkhGaH_I7VU=.c5860540-aaf1-4940-9bec-60b52b70237f@github.com>
 <Rl-RDfzcmK03A8xvFiaxrthLQDzDq1OsAix5gofcYAI=.80ea71db-4671-4d34-92fe-4d9de20fe9f5@github.com>
 <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com>
 <lGDHJ2RP6K7L_Gi0w5VbWE4R8dwBeNjBNkBlAGrgaBU=.3ab6b3cb-8a11-4eea-90a4-1d72d487850d@github.com>
 <B5DjmRXjCbHyYUFgOmH2XaJuZuI-PAkM3r2
 SFnhZxF4=.91594a97-a490-4fed-8693-82b88747df34@github.com>
 <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com>
Message-ID: <dHaWsVYEFuSJGuzqprpJP-RxEoxR8hFNz9E7oCRdyDg=.b23fab5e-f847-4a5b-b0e2-1aeb53212c79@github.com>

On Sun, 27 Jul 2025 21:27:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Note that java_thread may already be null so we don't get to execute line 836.
>> 
>> I'm having some trouble with this statement. Working backwards from L836, I see
>> the nullptr check on L826 and the check for non-virtual thread and bail on L827
>> and L831. However, if we saw nullptr on L826 and we have a virtual thread, then
>> we can get to L836 even when we started off with a null java_thread.
>> 
>> So I guess I'm not sure what point you're trying to make with the statement.
>
>> then we can get to L836 even when we started off with a null java_thread.
> 
> Sure. My point was more the other way round - we could have a null JavaThread without the null coming from line  836.
> 
> The comment was just trying to expand on my previous comment.

Thanks for the clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2237939518

From rasbold at openjdk.org  Mon Jul 28 22:45:21 2025
From: rasbold at openjdk.org (Chuck Rasbold)
Date: Mon, 28 Jul 2025 22:45:21 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
Message-ID: <fhC2bpA0L213EgaN8rHBRnta9_8OSQkkHD0CZSsK7Xk=.5101ea19-8beb-4175-8d42-4826cb12dd55@github.com>

On Fri, 25 Jul 2025 17:42:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>> 
>> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @eastig review comment:
>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

Marked as reviewed by rasbold (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26395#pullrequestreview-3064766667

From jiangli at openjdk.org  Mon Jul 28 23:02:29 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Jul 2025 23:02:29 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <fhC2bpA0L213EgaN8rHBRnta9_8OSQkkHD0CZSsK7Xk=.5101ea19-8beb-4175-8d42-4826cb12dd55@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <fhC2bpA0L213EgaN8rHBRnta9_8OSQkkHD0CZSsK7Xk=.5101ea19-8beb-4175-8d42-4826cb12dd55@github.com>
Message-ID: <WNB6PsF_xiH-whzUHb_imK8xtV4AR1ymjngJp18C6LY=.bd9fdf49-da21-45e8-9ea0-3314833adfc9@github.com>

On Mon, 28 Jul 2025 22:41:47 GMT, Chuck Rasbold <rasbold at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @eastig review comment:
>>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.
>
> Marked as reviewed by rasbold (Reviewer).

@rasbold Thanks for the review!

@eastig Please let me know if there are any addition comments/thoughts on the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3130069873

From dholmes at openjdk.org  Mon Jul 28 23:56:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 23:56:54 GMT
Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread
 does not deal with a virtual thread's carrier thread [v3]
In-Reply-To: <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
 <uOm3miCRO6PuxAXTH67cPqcW3cPtfxVCYjfsz5S-Bs0=.9f2ad714-272b-4d21-a88a-476a97973862@github.com>
Message-ID: <ilArHoiMTLdc4mFjCdMK9KMjd4QdBPN930u0N0ky3Ac=.ee8f765a-a641-44e8-b141-7033a54ab2d9@github.com>

On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
>> 
>> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
>> 
>> Testing:
>> - tiers 1-4
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Thanks Dan!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3130141978

From dholmes at openjdk.org  Mon Jul 28 23:56:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Jul 2025 23:56:54 GMT
Subject: Integrated: 8361912:
 ThreadsListHandle::cv_internal_thread_to_JavaThread  does not deal with a
 virtual thread's carrier thread
In-Reply-To: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
References: <blOP1FcZVGe7jf6wp0QY1AD2aRq_xa_ZKyHaOerE-xk=.437ffdd1-e9e3-4687-b95e-70197afd2a18@github.com>
Message-ID: <fNRHNReviIBk7GOmbl9-UqrDyHzZK3y2hmHgmyWgYFY=.50f4f424-9926-4702-98a3-3016742f76c3@github.com>

On Mon, 14 Jul 2025 05:34:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads).
> 
> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed.
> 
> Testing:
> - tiers 1-4
> 
> Thanks

This pull request has now been integrated.

Changeset: 46690051
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4669005123420d8dbe86740dd9bcbee04735bc4f
Stats:     84 lines in 4 files changed: 18 ins; 54 del; 12 mod

8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread  does not deal with a virtual thread's carrier thread

Reviewed-by: pchilanomate, dcubed, amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/26287

From ysuenaga at openjdk.org  Mon Jul 28 23:58:44 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 23:58:44 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
 <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>
Message-ID: <eZx0id3f9UllTaK9T4AcxbreJzUn-4QNudElMvKFegU=.ec0638fe-324d-4854-9cbf-112155a98e38@github.com>

On Mon, 28 Jul 2025 16:51:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Does it also happen with -XX:ExitOnOutOfMemoryError?

No.
This change affects `CrashOnOutOutOfMemoryError`, but this does not change `ExitOnOutOfMemoryError` behavior. VM would shutdown immediately without emergency dump if OOM happened when the user adds `ExitOnOutOfMemoryError`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3130151589

From kbarrett at openjdk.org  Tue Jul 29 01:44:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Jul 2025 01:44:45 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
Message-ID: <VFdncvXl7yvYFjIS1FX26Efo6hR7cLsd8VLj7mZxU0k=.966cf833-e879-4493-a28a-a7fa0bd0151a@github.com>

On Fri, 27 Jun 2025 07:30:26 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 8357086: Fxied return value
>  - 8357086: Fixed whitespaces
>  - 8357086: Introduced usage pattern
>  - 8357086: Fixed typo
>  - 8357086: Refactored physical_memory in different OS
>  - 8357086: Small fixes 2
>  - 8357086: Small fixes 1.
>  - 8357086: Refactored physical_memory()
>  - 8357086: Refactored free_swap_space()
>  - 8357086: Refactored total_swap_space()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333

Maybe we should have an `ATTRIBUTE_NODISCARD` macro with an always empty
definition, and add it to all the functions being changed? Otherwise, once
`[[nodiscard]]` becomes available, someone is going to have to hunt down all
the relevant functions. Once we have C++17 we can revisit. It might take some
preliminary call-site fixes before we can change the macro (or more likely,
remove it and just use `[[nodiscard]]` directly).

@toxaart - Before you do anything about that, what do other reviewers think?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3064900011

From jrose at openjdk.org  Tue Jul 29 01:54:17 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 29 Jul 2025 01:54:17 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
In-Reply-To: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
Message-ID: <T2W0A5jcwk0nIKNIXtFqz-uDrYUQXQYyEJT5wll6B3M=.2f966afe-2b27-415b-81b2-05a032744fbf@github.com>

On Mon, 28 Jul 2025 19:06:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - aot safe markers for runtime setup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Restore non-public comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
>  - Reviews
>  - Documentation
>  - Don't fail for patching tests
>  - Remove design document from code
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

I sent you some updates to the javadocs.  Otherwise, everything is (still) ready to ship.

[Annotation-Javadoc-Updates.zip](https://github.com/user-attachments/files/21479022/Annotation-Javadoc-Updates.zip)

-------------

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3064951754
PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3130301216

From duke at openjdk.org  Tue Jul 29 02:26:08 2025
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 29 Jul 2025 02:26:08 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers
 to long
Message-ID: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>

Hi all,

Fixed type errors in documentation, minor changes.

Thanks!

-------------

Commit messages:
 - 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long

Changes: https://git.openjdk.org/jdk/pull/26521/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363920
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26521/head:pull/26521

PR: https://git.openjdk.org/jdk/pull/26521

From stuefe at openjdk.org  Tue Jul 29 05:49:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 05:49:54 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
Message-ID: <kn-4WeTnd_z241iZmnpqlv8W4GUN-xmgNc3pmXAcsNI=.2199e6f7-1156-443a-bd3e-93ab50e4bb3a@github.com>

On Mon, 28 Jul 2025 14:17:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray include
>
> src/hotspot/share/classfile/classLoaderDataShared.hpp line 46:
> 
>> 44:   static void serialize(SerializeClosure* f);
>> 45:   static void clear_archived_oops();
>> 46: #if INCLUDE_CDS_JAVA_HEAP
> 
> Why is this needed?

This is an unrelated build breakage in CDS on 32-bit (see https://bugs.openjdk.org/browse/JDK-8364202). I'll remove this and fix it with JDK-8364202.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2238598265

From alanb at openjdk.org  Tue Jul 29 06:22:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 06:22:59 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
Message-ID: <TK0nysSbnpqXY28ALHjwIDEu1RZ4zDnDLVNiqUaw96s=.52dfe543-20fb-4a18-b3b3-3007f4cc8fc5@github.com>

On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> Fixed type errors in documentation, minor changes.
> 
> Thanks!

Good spot, a long standing copy and paste issue it seems.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3065673109

From stuefe at openjdk.org  Tue Jul 29 06:23:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:23:57 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
Message-ID: <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>

On Mon, 28 Jul 2025 12:02:47 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add testcase

Looks good to me, provided Erik is happy.

test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:

> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
> 69:         p.waitFor();
> 70:         var output = new OutputAnalyzer(p);

I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.

Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3065672936
PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2238651593

From stuefe at openjdk.org  Tue Jul 29 06:26:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:26:55 GMT
Subject: RFR: 8364169: (NMT) Move nativeCallStack to nmt
In-Reply-To: <6whLMyqmDLfl7gvjFakgJpAZDrOZv_nsQRY4Trqc3Mw=.30a8b1ae-dd80-4e08-ad9b-52f3e94dbea8@github.com>
References: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
 <6whLMyqmDLfl7gvjFakgJpAZDrOZv_nsQRY4Trqc3Mw=.30a8b1ae-dd80-4e08-ad9b-52f3e94dbea8@github.com>
Message-ID: <AYOHeLSM3f4hwwJX4F1qg9-oJQhNYehKNq-Ygh9lEpM=.354ead61-34a2-4057-b39d-e0a33087a951@github.com>

On Mon, 28 Jul 2025 13:59:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> LGTM, but I want two reviews (in case someone disagrees with the move).

Sure. Thanks, @jdksjolen !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26498#issuecomment-3130864117

From stuefe at openjdk.org  Tue Jul 29 06:28:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:28:54 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
Message-ID: <xP2djPnbvwzBFqCuz-jnPENgH_jy3mTEhQPQwNyecvg=.67d39937-7144-4a91-a0ef-5d6f742a7edf@github.com>

On Mon, 28 Jul 2025 10:51:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [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:
> 
>   Better comment

The new comment is a lot better, thanks.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26477#pullrequestreview-3065690895

From stuefe at openjdk.org  Tue Jul 29 06:41:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:41:54 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
Message-ID: <xcDbi4BuW8HAcU9YsePgfe0mJGEFToUVXfIAi240NXE=.035a77ea-fb5c-444f-8766-49f4a9c44822@github.com>

On Mon, 28 Jul 2025 10:51:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [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:
> 
>   Better comment

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 126:

> 124: 
> 125:   if (Devirtualizer::do_metadata(closure)) {
> 126:     if (mr.contains(obj)) {

Unrelated, we could probably move mr.contains up to include `InstanceKlass::oop_oop_iterate_bounded<T>(obj, closure, mr);` to prevent the double check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2238687566

From stuefe at openjdk.org  Tue Jul 29 06:56:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:56:54 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
Message-ID: <xNNknOo6cXQQerTaC0MmJfP52IcGevslsW0jJReF9eg=.77e2f5bf-07eb-43a6-a7ac-aff997ce0016@github.com>

On Mon, 28 Jul 2025 10:51:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [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:
> 
>   Better comment

I wondered briefly whether the allowance ("CLD = null is okay for newly-loaded classes") should be also made in https://github.com/openjdk/jdk/blob/4669005123420d8dbe86740dd9bcbee04735bc4f/src/hotspot/share/memory/iterator.inline.hpp#L57-L59 

But since we now handle mirror->referee Klass correctly in IMK, this only path affects oop->its Klass, and no instances exist yet for that Klass, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26477#issuecomment-3130944972

From stuefe at openjdk.org  Tue Jul 29 07:18:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 07:18:12 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v4]
In-Reply-To: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
Message-ID: <ZR1zcpPoRfn4n1i-mGVCjSpVIE9bOVcHBie0uw1HFqo=.331b5b09-f481-4692-b62f-34897476e857@github.com>

> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
> 
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
> 
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
> 
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
> 
> -------
> 
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
> 
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
> 
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
> 
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  since to because
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26491/files
  - new: https://git.openjdk.org/jdk/pull/26491/files/cdd14445..377ee7bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491

PR: https://git.openjdk.org/jdk/pull/26491

From stuefe at openjdk.org  Tue Jul 29 07:18:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 07:18:12 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <9-fVlgJ0rY7pDb92eZI3WgqzupdlZGCKWf2ln3NOvEk=.e18d3cab-d91b-4d95-8e08-fc1e9a578129@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <9-fVlgJ0rY7pDb92eZI3WgqzupdlZGCKWf2ln3NOvEk=.e18d3cab-d91b-4d95-8e08-fc1e9a578129@github.com>
Message-ID: <AtGVlwzvnqmRp0KtWRu1kNHAU1EykZUQNL_kwXJnKTE=.9987ad0f-8dab-4e7e-a02c-10df4679e35d@github.com>

On Mon, 28 Jul 2025 16:18:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Very nice! That's come out a lot cleaner than I was expecting.
> 
> Building and testing on a Raspberry Pi must have been fun. Not.

I did crossbuild on x64, so it was fast. Testing was not fun, though.

> src/hotspot/share/oops/compressedKlass.cpp line 56:
> 
>> 54:   // Klass pointers here, coding needs to be revised.
>> 55:   // We keep one page safety zone free to guard against size_t overflows on 32-bit. In practice
>> 56:   // this is irrelevant, since these upper address space parts are not user-addressable on
> 
> Suggestion:
> 
>   // this is irrelevant because these upper address space parts are not user-addressable on
> 
> Reason: correlation is not causation.

I did not know this distinction, had to look it up. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26491#issuecomment-3131022431
PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2238771664

From jsjolen at openjdk.org  Tue Jul 29 07:21:55 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 29 Jul 2025 07:21:55 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
Message-ID: <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>

On Mon, 28 Jul 2025 18:16:16 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
> Platforms affected: x86-64 and aarch64
> Other platforms can be done if and when Leyden changes are ported to them.
> 
> [0] https://github.com/openjdk/leyden/pull/84

It seems like we can just use a `stringStream` instead and not have to deal with any overflow of some buffer, since we strdup at the end.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1111:

> 1109:   assert(!info_buffer.overflow(), "not enough buffer size");
> 1110:   int features_offset = info_buffer.length();
> 1111:   insert_features_names(_features, info_buffer);

Can't you just check the overflow at the end?

src/hotspot/cpu/x86/vm_version_x86.cpp line 1113:

> 1111:   insert_features_names(_features, info_buffer);
> 1112: 
> 1113:   _cpu_info_string = os::strdup(info_buffer);

Sorry, I'm going to need some help here :-). How can passing a `FormatBuffer` to `os::strdup` not fail to compile?

src/hotspot/share/runtime/abstract_vm_version.hpp line 48:

> 46: #endif // CPU_INFO_BUF_SIZE
> 47: 
> 48: template<size_t bufsz> class FormatBuffer;

Style: `template <size_t bufsz>`.

src/hotspot/share/runtime/abstract_vm_version.hpp line 50:

> 48: template<size_t bufsz> class FormatBuffer;
> 49: 
> 50: using CpuInfoBuffer = FormatBuffer<CPU_INFO_BUF_SIZE>;

Is it important that we avoid dynamic allocation at this stage of VM initialization? Is that why we can't use `stringStream` instead?

src/hotspot/share/utilities/formatBuffer.hpp line 90:

> 88:     }
> 89:     return;
> 90:   }

This method seems overly specific to the use-case.

Something like this is more widely applicable.

```c++
// Append strings returned by gen, separating each with separator.
// Stops when gen returns null or when buffer is out of space.
template <typename Generator>
void join(Generator gen, const char* separator) {
    bool first = true;
    const char* str = gen();
    while (str != nullptr) {
      const char* sep = first ? "" : separator;
      int result = append("%s%s", sep, str);
      if (result < 0) {
        return;
      }
      first = false;
    }
  return;
}


Example usage:

```c++
void VM_Version::insert_features_names(uint64_t features, CpuInfoBuffer& info_buffer) {
  int i = 0;
  info_buffer.join([&]() {
    while (!supports_feature((VM_Version::Feature_Flag)i) && i < MAX_CPU_FEATURES) {
      i++;
    }
    if (i >= MAX_CPU_FEATURES) {
      return nullptr;
    }
    return _features_names[i];
  }, ", ");
  assert(!info_buffer.overflow(), "not enough buffer size");
}

-------------

PR Review: https://git.openjdk.org/jdk/pull/26515#pullrequestreview-3065756178
PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238736430
PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238721100
PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238700284
PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238707903
PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238778395

From jsjolen at openjdk.org  Tue Jul 29 07:21:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 29 Jul 2025 07:21:56 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
In-Reply-To: <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
 <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
Message-ID: <baw5o4WZsa7yPUeqBKRX3ylc-_2dLNke-ijPvYDRqSE=.ce87266e-77ec-4884-bc7a-e9f971389c80@github.com>

On Tue, 29 Jul 2025 06:54:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
>> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
>> Platforms affected: x86-64 and aarch64
>> Other platforms can be done if and when Leyden changes are ported to them.
>> 
>> [0] https://github.com/openjdk/leyden/pull/84
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1113:
> 
>> 1111:   insert_features_names(_features, info_buffer);
>> 1112: 
>> 1113:   _cpu_info_string = os::strdup(info_buffer);
> 
> Sorry, I'm going to need some help here :-). How can passing a `FormatBuffer` to `os::strdup` not fail to compile?

And here we do `os::strdup`, so now we do have dynamic allocation, so maybe just use a `stringStream`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2238737303

From adinn at openjdk.org  Tue Jul 29 07:29:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 07:29:42 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs [v2]
In-Reply-To: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
Message-ID: <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>

> Array copy stubs may legitimately generate SEGV errors during copying. They rely on class UnsafeMemoryAccess to record and expose to the signal handler a table of address ranges within which a SEGV should be dealt with by redirecting execution to an associated handler address. The handler address may lie within the same stub or may default to an independent entry belonging to a specific, non-copy stub within the same blob. Normally entries are added to the table as a side-effect of generating the stub.
> 
> This patch implements the preliminary steps needed to enable save and restore of the UnsafeMemoryAccess table entries alongside with their associated AOT compiled copy stubs. It adds the common entry to the entry declarations list so it can be saved to the AOT cache during the assembly phase and reloaded, relocated and installed as the table default entry during a production run. It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  update all arches to set unsafecopy_common entry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26511/files
  - new: https://git.openjdk.org/jdk/pull/26511/files/362e7e4d..a3b7c241

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26511&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26511&range=00-01

  Stats: 35 lines in 4 files changed: 23 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26511/head:pull/26511

PR: https://git.openjdk.org/jdk/pull/26511

From adinn at openjdk.org  Tue Jul 29 07:29:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 07:29:42 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs
In-Reply-To: <ckUCrN48RS7-oBNLktWagIH8S_fs97rsen91_QX-weo=.9d0d7166-a0ae-476c-8783-06ce84e485ef@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
 <ckUCrN48RS7-oBNLktWagIH8S_fs97rsen91_QX-weo=.9d0d7166-a0ae-476c-8783-06ce84e485ef@github.com>
Message-ID: <sqCnKV0GzGy5kN7NQffoDPbVfZu9TwweHdykLqQ2sMM=.a7d1be37-74fd-475e-bfaa-feba2478812f@github.com>

On Mon, 28 Jul 2025 16:51:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I guess there's no way to test this contribution because the API has no customers, but you'll submit such testing as necessary in a later PR.

Yes, that's right. This will be used by a PR I am working on to save and restore stubgenerator stubs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26511#issuecomment-3131054936

From duke at openjdk.org  Tue Jul 29 08:29:00 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Jul 2025 08:29:00 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
Message-ID: <o2gR8L42uFfc0o8HyY5NPYGHd3tXMgr0p3-WS0xtH0w=.1542be53-a623-42b0-a4a1-bb32ec950812@github.com>

On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> Fixed type errors in documentation, minor changes.
> 
> Thanks!

@Korov 
Your change (at version b6a19df4f83266856f9688f4ac204055908b89a8) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26521#issuecomment-3131256382

From shade at openjdk.org  Tue Jul 29 08:30:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 08:30:56 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <xNNknOo6cXQQerTaC0MmJfP52IcGevslsW0jJReF9eg=.77e2f5bf-07eb-43a6-a7ac-aff997ce0016@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
 <xNNknOo6cXQQerTaC0MmJfP52IcGevslsW0jJReF9eg=.77e2f5bf-07eb-43a6-a7ac-aff997ce0016@github.com>
Message-ID: <o5CPa6RjBy3P0wD8iRKSTA-kiGDvczWqm0UH0iUr2BA=.88a17ef6-ca99-4d1f-9e3a-55be1070d940@github.com>

On Tue, 29 Jul 2025 06:54:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I wondered briefly whether the allowance ("CLD = null is okay for newly-loaded classes") should be also made in
> 
> https://github.com/openjdk/jdk/blob/4669005123420d8dbe86740dd9bcbee04735bc4f/src/hotspot/share/memory/iterator.inline.hpp#L57-L59
> 
> But since we now handle mirror->referee Klass correctly in IMK, this only path affects oop->its Klass, and no instances exist yet for that Klass, right?

`ClaimMetadataVisitingOopIterateClosure::do_klass`  called from other places, not only IMK. So I believe those asserts could be reached through other means. What we handle here is only IMK.

> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 126:
> 
>> 124: 
>> 125:   if (Devirtualizer::do_metadata(closure)) {
>> 126:     if (mr.contains(obj)) {
> 
> Unrelated, we could probably move mr.contains up to include `InstanceKlass::oop_oop_iterate_bounded<T>(obj, closure, mr);` to prevent the double check.

I am not sure about that, since `InstanceKlass::oop_oop_iterate_bounded` iterates the oop maps themselves, so the `mr.contains(obj)` likely filters too much. Anyway, since this is change in shared code, I would prefer to make the minimal possible thing to avoid accidentally breaking more stuff. So I am keeping this code as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26477#issuecomment-3131262981
PR Review Comment: https://git.openjdk.org/jdk/pull/26477#discussion_r2238961893

From ayang at openjdk.org  Tue Jul 29 09:42:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Jul 2025 09:42:50 GMT
Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox FullGC
Message-ID: <MQ31Ok-NNG66SPysEMeFjYBm3CoK49RWqGjWL1_CPyc=.395d2819-ffb2-4635-8ec2-51cc78a63a7e@github.com>

Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already.

Test: tier1-3

-------------

Commit messages:
 - sgc-whitebox

Changes: https://git.openjdk.org/jdk/pull/26528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364254
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26528/head:pull/26528

PR: https://git.openjdk.org/jdk/pull/26528

From stuefe at openjdk.org  Tue Jul 29 10:17:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 10:17:56 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <_lYqxXso1Bi648mrXunKgsHMPi9FT1ATnSKS8c92Pq8=.98b442d1-4f0c-457c-a581-9e3debc00061@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
 <_lYqxXso1Bi648mrXunKgsHMPi9FT1ATnSKS8c92Pq8=.98b442d1-4f0c-457c-a581-9e3debc00061@github.com>
Message-ID: <GCDUAR7TCROIVNXOw4goIKIJh-P25u_iwaoE_K-H7t4=.b47c5d15-042b-41a2-b219-258a1d18354c@github.com>

On Mon, 28 Jul 2025 06:30:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback kim
>
> Changes requested by kbarrett (Reviewer).

@kimbarrett are you happy with the latest version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26472#issuecomment-3131742681

From egahlin at openjdk.org  Tue Jul 29 11:05:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 11:05:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
Message-ID: <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>

On Tue, 29 Jul 2025 06:20:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add testcase
>
> test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:
> 
>> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
>> 69:         p.waitFor();
>> 70:         var output = new OutputAnalyzer(p);
> 
> I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.
> 
> Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.

I'm going to run some testing before approving. 

I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
https://openjdk.org/projects/amber/guides/lvti-style-guide

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2239410134

From kbarrett at openjdk.org  Tue Jul 29 11:29:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Jul 2025 11:29:55 GMT
Subject: RFR: 8364004: Expose VMError::controlledCrash via Whitebox [v2]
In-Reply-To: <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
 <1oHOS0ZRVh4I_w_EVsze_5tqPhsw6Y-1mmEKL1Iio4k=.5c0a996d-0212-4c4e-a690-e70cbefd55e2@github.com>
Message-ID: <EHra3vY0u7o0HPzvjxfxemROb0yW65rjTRy1-Tqzvss=.919537ae-4949-4188-b605-0fb141a3fb32@github.com>

On Mon, 28 Jul 2025 06:46:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback kim

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26472#pullrequestreview-3066997553

From jsikstro at openjdk.org  Tue Jul 29 11:34:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 11:34:07 GMT
Subject: RFR: 8364248: Separate memory limit detection
Message-ID: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>

The function os::has_allocatable_memory() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.

ZGC currently uses os::has_allocatable_memory() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.

As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).

Testing:
* Oracle's tier1-2
* Manual testing on Linux by limiting the virtual address space:

$ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

-------------

Commit messages:
 - 8364248: Separate memory limit detection

Changes: https://git.openjdk.org/jdk/pull/26530/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364248
  Stats: 38 lines in 4 files changed: 26 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From stefank at openjdk.org  Tue Jul 29 11:59:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 11:59:04 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
Message-ID: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>

On Fri, 27 Jun 2025 07:30:26 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 8357086: Fxied return value
>  - 8357086: Fixed whitespaces
>  - 8357086: Introduced usage pattern
>  - 8357086: Fixed typo
>  - 8357086: Refactored physical_memory in different OS
>  - 8357086: Small fixes 2
>  - 8357086: Small fixes 1.
>  - 8357086: Refactored physical_memory()
>  - 8357086: Refactored free_swap_space()
>  - 8357086: Refactored total_swap_space()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333

I went over this and have some more comments. The two main concerns I have are:
1) I really would like to see all the UL "X failed" log lines removed from this patch.
2) Callers that discard the return value should be clearly marked that they do so. (Alternatively, provide APIs that clearly returns 0 on failure).

src/hotspot/os/aix/os_aix.cpp line 296:

> 294:   size_t phys_mem = Aix::physical_memory();
> 295:   if (phys_mem == std::numeric_limits<size_t>::max())
> 296:   {

Suggestion:

  if (phys_mem == std::numeric_limits<size_t>::max()) {

src/hotspot/os/bsd/os_bsd.cpp line 160:

> 158:     available = (vmstat.free_count + vmstat.inactive_count + vmstat.purgeable_count) * os::vm_page_size();
> 159:   } else {
> 160:     return false;

This looks like a change in behavior, but I guess it is a situation we shouldn't encounter or we would have hit the assert above.

src/hotspot/os/bsd/os_bsd.cpp line 290:

> 288:   if (sysctl(mib, 2, &mem_val, &len, nullptr, 0) != -1) {
> 289:     assert(len == sizeof(mem_val), "unexpected data size");
> 290:     _physical_memory = static_cast<size_t>(mem_val);

The `__OpenBSD__` section below still uses `julong`.

src/hotspot/os/bsd/os_bsd.cpp line 1477:

> 1475:   if (!os::physical_memory(phys_mem)) {
> 1476:     log_debug(os, thread)("os::physical_memory() failed");
> 1477:   }

It's not clear to me that we want to have a side-effect of logging to UL here. Wouldn't it make more sense to log that physical memory info is not available to the provided `st` stream?

src/hotspot/os/bsd/os_bsd.cpp line 1482:

> 1480:   size_t avail_mem = 0;
> 1481:   if (!os::available_memory(avail_mem))
> 1482:   {

Suggestion:

  if (!os::available_memory(avail_mem)) {

src/hotspot/os/linux/os_linux.cpp line 297:

> 295:   if (OSContainer::is_containerized()) {
> 296:     if (OSContainer::memory_limit_in_bytes() > 0) {
> 297:       value = static_cast<size_t>(OSContainer::memory_and_swap_limit_in_bytes() - OSContainer::memory_limit_in_bytes());

I might have wondered about this before, but can't `memory_and_swap_limit_in_bytes` return `-1` even when `memory_limit_in_bytes > 0` since -1 is treated as an "unlimited limit" here:

jlong CgroupV1MemoryController::read_mem_swap(julong host_total_memsw) {
  julong memswlimit;
  CONTAINER_READ_NUMBER_CHECKED(reader(), "/memory.memsw.limit_in_bytes", "Memory and Swap Limit", memswlimit);
  if (memswlimit >= host_total_memsw) {
    log_trace(os, container)("Memory and Swap Limit is: Unlimited");
    return (jlong)-1;
  }

Maybe this will be handled in a cleanup to the container subsystem?

src/hotspot/os/windows/os_windows.cpp line 900:

> 898:   size_t phys_mem = win32::physical_memory();
> 899:   if (phys_mem == std::numeric_limits<size_t>::max())
> 900:   {

Suggestion:

  if (phys_mem == std::numeric_limits<size_t>::max()) {

src/hotspot/share/compiler/compileBroker.cpp line 1062:

> 1060:   // Now, we do the more expensive operations.
> 1061:   size_t free_memory = 0;
> 1062:   os::free_memory(free_memory);

I wonder if this should be changed to something like this:
Suggestion:

  // Return value ignored - defaulting to 0 on failure.
  (void)os::free_memory(free_memory);

to clearly indicate the intent to skip the error check?

src/hotspot/share/gc/shared/gcInitLogger.cpp line 70:

> 68:     log_debug_p(gc, init)("os::physical_memory() failed");
> 69:   }
> 70:   julong memory = static_cast<julong>(phys_mem);

I would prefer to not have the extra logging in the GC code + some extra restructuring:

  size_t memory = 0;
  if (os::physical_memory(memory)) {
    log_info_p(gc, init)("Memory: %zu%s",
                         byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
  } else {
    log_info_p(gc, init)("Memory: NA");
  }

src/hotspot/share/gc/z/zLargePages.cpp line 37:

> 35:     log_debug_p(gc, init)("os::physical_memory() failed");
> 36:   }
> 37:   log_info_p(gc, init)("Memory: %zuM", phys_mem / M);

I have the same comment about this change as I have for `GCInitLogger::print_memory`.

src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 406:

> 404: 
> 405: JVM_ENTRY_NO_ENV(jlong, jfr_host_total_memory(JNIEnv* env, jclass jvm))
> 406:   size_t phys_mem = 0;

This can be moved below where it is used. I would probably also be good to explicitly show that the return value is skipped.

With that said, now I've seen this pattern a number of times and think that it might be cleaner to have a function named `os::physical_memory_or_0()` (just like we have a bunch of "_or_null" functions) that returns 0 on failure. The code could then be:

#ifdef LINUX
  // We want the host memory, not the container limit.
  // os::physical_memory() would return the container limit.
  return os::Linux::physical_memory();
#else
  return os::physical_memory_or_0();
#endif

We can think about that proposal as a follow-up RFE.

src/hotspot/share/prims/whitebox.cpp line 2515:

> 2513:   LINUX_ONLY(return os::Linux::physical_memory();)
> 2514:   os::physical_memory(phys_mem);
> 2515:   return static_cast<jlong>(phys_mem);

This looks like the JFR code that doesn't want to report the container limits. We should probably have an os:: function that returns this value that both these functions wants. Maybe `os::host_physical_memory`. Something for a future RFE.

-------------

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3066796623
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239340170
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239354684
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239388371
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239394003
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239389671
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239429254
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239466558
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239489983
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239528661
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239540372
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239550486
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239557604

From stefank at openjdk.org  Tue Jul 29 11:59:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 11:59:04 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <08Vitu5-rVx8f40vvl-WU4EE6ebzpUXVG-EbB_6kr6M=.cb45b7f9-d314-46ce-b912-e19e056ec77d@github.com>

On Tue, 29 Jul 2025 10:53:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - 8357086: Fxied return value
>>  - 8357086: Fixed whitespaces
>>  - 8357086: Introduced usage pattern
>>  - 8357086: Fixed typo
>>  - 8357086: Refactored physical_memory in different OS
>>  - 8357086: Small fixes 2
>>  - 8357086: Small fixes 1.
>>  - 8357086: Refactored physical_memory()
>>  - 8357086: Refactored free_swap_space()
>>  - 8357086: Refactored total_swap_space()
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333
>
> src/hotspot/os/bsd/os_bsd.cpp line 290:
> 
>> 288:   if (sysctl(mib, 2, &mem_val, &len, nullptr, 0) != -1) {
>> 289:     assert(len == sizeof(mem_val), "unexpected data size");
>> 290:     _physical_memory = static_cast<size_t>(mem_val);
> 
> The `__OpenBSD__` section below still uses `julong`.

It is also "interesting" that the BSD port doesn't propagate the failure to set up `_physical_memory` but the other platforms do. This adds an inconsistency across our platforms and I think that would be good to unify the behavior around that.

> src/hotspot/os/bsd/os_bsd.cpp line 1477:
> 
>> 1475:   if (!os::physical_memory(phys_mem)) {
>> 1476:     log_debug(os, thread)("os::physical_memory() failed");
>> 1477:   }
> 
> It's not clear to me that we want to have a side-effect of logging to UL here. Wouldn't it make more sense to log that physical memory info is not available to the provided `st` stream?

FWIW, I find all these UL logging statements in the os::xxx_memory functions highly dubious, and think that it would be better to have some carefully thought-through places where we log system memory information. The spread-out of the UL logging in the various memory functions look like debugging aid for HotSpot devs and not really for the users of the JVM. So, maybe they could be at most be develop logging statements. I think this could be a discussion that needs to be done outside of this PR, but since even more logging statements are added with this PR I'm bringing this up here. Could we at least skip adding these log lines in this PR? The same comment goes for the rest of the platform files.

> src/hotspot/share/gc/shared/gcInitLogger.cpp line 70:
> 
>> 68:     log_debug_p(gc, init)("os::physical_memory() failed");
>> 69:   }
>> 70:   julong memory = static_cast<julong>(phys_mem);
> 
> I would prefer to not have the extra logging in the GC code + some extra restructuring:
> 
>   size_t memory = 0;
>   if (os::physical_memory(memory)) {
>     log_info_p(gc, init)("Memory: %zu%s",
>                          byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
>   } else {
>     log_info_p(gc, init)("Memory: NA");
>   }

Alternatively:

  size_t memory = 0;
  (void)os::physical_memory(memory);
  log_info_p(gc, init)("Memory: %zu%s",
                       byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239481478
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239463594
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2239533880

From coleenp at openjdk.org  Tue Jul 29 12:02:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 12:02:14 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
Message-ID: <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>

On Mon, 28 Jul 2025 21:56:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> src/java.base/share/classes/java/lang/Class.java line 1012:
> 
>> 1010:     private transient Object[] signers; // Read by VM, mutable
>> 1011:     private final transient char modifiers;  // Set by the VM
>> 1012:     private final transient char rawAccessFlags;  // Set by the VM
> 
> I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.

This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2239571176

From adinn at openjdk.org  Tue Jul 29 12:21:07 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 12:21:07 GMT
Subject: RFR: 8364269: Simplify code cache API by storing adapter entry offsets
 in blob
Message-ID: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>

The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.

-------------

Commit messages:
 - simplify code cache API by storing adapter entry offsets in blob

Changes: https://git.openjdk.org/jdk/pull/26532/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26532&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364269
  Stats: 95 lines in 5 files changed: 30 ins; 42 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26532/head:pull/26532

PR: https://git.openjdk.org/jdk/pull/26532

From stuefe at openjdk.org  Tue Jul 29 12:38:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 12:38:01 GMT
Subject: Integrated: 8364004: Expose VMError::controlledCrash via Whitebox
In-Reply-To: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
References: <gmnlWr2Dv_ypeyOcTeuSzI7A1YjEO-MwFQVQ8Da_R0c=.634feec1-a2da-4bd0-9294-003850a5d3e7@github.com>
Message-ID: <_Q-XS7LerIgbODAkwVxvmCF5-v73AiMVoKUeWISlkSM=.ade9282f-26e6-4ced-8f45-9ca879d6c590@github.com>

On Fri, 25 Jul 2025 07:34:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small addition to the circle of WhiteBox functions to allow more controlled crashes triggered from jtreg tests.

This pull request has now been integrated.

Changeset: 0226c029
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0226c0298f5398c185db3df30ad35ee6022aab1b
Stats:     29 lines in 3 files changed: 24 ins; 1 del; 4 mod

8364004: Expose VMError::controlledCrash via Whitebox

Reviewed-by: kbarrett, mbaesken, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26472

From shade at openjdk.org  Tue Jul 29 12:45:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 12:45:56 GMT
Subject: RFR: 8364269: Simplify code cache API by storing adapter entry
 offsets in blob
In-Reply-To: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
References: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
Message-ID: <pQdqPQ_SjSr8XMTZArEVOZNVQtqeP1d8b6i5i-mUb-k=.96bc647a-08eb-4111-9305-ed583c3a6c9d@github.com>

On Tue, 29 Jul 2025 12:15:48 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.

Cross-compile GHA jobs would be fixed once you pull from recent master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3132350482

From stuefe at openjdk.org  Tue Jul 29 12:47:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 12:47:54 GMT
Subject: RFR: 8364248: Separate memory limit detection
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>

On Tue, 29 Jul 2025 11:24:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Generally good. But why not simply return the limit. Unlimited = size_max. 

Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.

Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3067358463

From adinn at openjdk.org  Tue Jul 29 13:03:54 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 13:03:54 GMT
Subject: RFR: 8364269: Simplify code cache API by storing adapter entry
 offsets in blob
In-Reply-To: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
References: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
Message-ID: <hgtlya8lBsW9Hnb4aaztztxW2XTNk8o8rCo6M-ITp08=.22f33eb2-29d5-4e6e-b033-dba4bfb8ade9@github.com>

On Tue, 29 Jul 2025 12:15:48 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.

Testing: tier1 + runtime/cds/appcds

@ashu-mehra @vnkozlov could you review this cleanup?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3132435041
PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3132437030

From jsikstro at openjdk.org  Tue Jul 29 13:14:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:14:55 GMT
Subject: RFR: 8364248: Separate memory limit detection
In-Reply-To: <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
Message-ID: <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>

On Tue, 29 Jul 2025 12:44:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Generally good. But why not simply return the limit. Unlimited = size_max.
> 
> Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.

This would make the ZGC could read more nicely I think. I like it!

> Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.

Do you think it would be prudent to add this now? To clarify, if there is a limit on POSIX, return `(size_t)rlim.rlim_cur - vm_min_address()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132483693

From adinn at openjdk.org  Tue Jul 29 13:28:15 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 13:28:15 GMT
Subject: RFR: 8364269: Simplify code cache API by storing adapter entry
 offsets in blob [v2]
In-Reply-To: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
References: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
Message-ID: <nRXklgQwULUswAo4-TFzFsorEZcgnTXiF2F_I3uclVs=.fa3dd0a0-2df3-4985-86b0-0a07b87f53e5@github.com>

> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.

Andrew Dinn 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8364269
 - simplify code cache API by storing adapter entry offsets in blob

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26532/files
  - new: https://git.openjdk.org/jdk/pull/26532/files/452f2d86..ad4a1a27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26532&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26532&range=00-01

  Stats: 35069 lines in 964 files changed: 19845 ins; 10641 del; 4583 mod
  Patch: https://git.openjdk.org/jdk/pull/26532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26532/head:pull/26532

PR: https://git.openjdk.org/jdk/pull/26532

From jsikstro at openjdk.org  Tue Jul 29 13:34:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:34:51 GMT
Subject: RFR: 8364248: Separate memory limit detection [v2]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename to os::address_space_limit() and return limit only, no boolean

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/05d6b351..4c86e1b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=00-01

  Stats: 24 lines in 4 files changed: 1 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From jsikstro at openjdk.org  Tue Jul 29 13:42:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/4c86e1b2..c4f27529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=01-02

  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From stuefe at openjdk.org  Tue Jul 29 13:42:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <EzevJXiqD8Y0dMB4GrQCgqZtfcpedIgQ5jft0toIc0Q=.b400b571-e0e5-4f81-91e6-8ec30097e853@github.com>
 <GeN5zUHFvxj6vW9KQIHGIvVb24v7gZ1qY0WJuQXAWzE=.70e2b200-26ad-4332-bd41-141b6cadea9e@github.com>
Message-ID: <cOSJzA2lGOizrqiJffQkuu1QXQzeFeuZXcxRaQyXZkk=.63855b14-8d46-4e30-aeca-e24801e77afc@github.com>

On Tue, 29 Jul 2025 13:12:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> > Generally good. But why not simply return the limit. Unlimited = size_max.
> > Oh, I see ZGC does that already. I would adopt that for has_limited_virtual_address_space. Then you can remove the ZGC implementation completely.
> 
> This would make the ZGC could read more nicely I think. I like it!
> 
> > Side note, to be unbearably nitpicky, it should theoretically be "address space limit - os::vm_min_address()" since the OS does not allow low-address mappings below that.
> 
> Do you think it would be prudent to add this now? To clarify, if there is a limit on POSIX, return `(size_t)rlim.rlim_cur - vm_min_address()`?

Nah, this was a half joke tbh. I don't think this fidelity is needed, and it may confuse people if we get a weirdly unaligned size back. E.g. if on Linux, the min map is configured to be just one page, you could get something like "4PB - 4K".

Also, you won't ever be able to use the full extend of that size anyway, since of course it is pre-populated with all kind of mappings, is fragmented, etc.

Side note, it would be valuable to have a sister function to os::vm_min_address() that returns the maximum mappable user address. I did hard code values at various places, but I believe ZGC has some function like this that is more elegant and more truthful. Would be nice to have this in os space.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132578396

From jsikstro at openjdk.org  Tue Jul 29 13:42:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 13:42:40 GMT
Subject: RFR: 8364248: Separate memory limit detection [v2]
In-Reply-To: <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <5h8I8ktWP7Wm8QmTu7iNRl2rSc699WEjTswu5FLEv_k=.0a89523f-5c06-4117-8d44-8760835157d4@github.com>
Message-ID: <UrLtb8tbBT-Nfy9zB9EbMFIGGOiU8HPn8JDEyCzlBMI=.c01dbc43-45f7-4584-8e79-ea7861f547f0@github.com>

On Tue, 29 Jul 2025 13:34:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to os::address_space_limit() and return limit only, no boolean

@stefank suggested to rename has_allocatable_memory_limit() to allocatable_memory_limit() while we're on this. This is in line with what @toxaart is doing for multiple os:: functions in https://github.com/openjdk/jdk/pull/25450.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132587277

From coleenp at openjdk.org  Tue Jul 29 13:43:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 13:43:35 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/b4daf731..163a8e5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=00-01

  Stats: 57 lines in 6 files changed: 32 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From stuefe at openjdk.org  Tue Jul 29 14:09:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 14:09:55 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <-bN2Wn_RhD_qTDG6sVzQoyPG5_ncVet_WdPC5So-w7w=.8202558b-e465-42ca-9878-500b3a868a5a@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.

"allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size. 

For example, how much you can *commit* depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.

I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132713524

From jsikstro at openjdk.org  Tue Jul 29 14:32:54 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 29 Jul 2025 14:32:54 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

Just want to start of by saying thank you for taking the time with this.

> I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> 
> "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> 
> For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> 
> I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.

I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.

On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132826631

From liach at openjdk.org  Tue Jul 29 14:37:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 14:37:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
 <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
Message-ID: <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>

On Tue, 29 Jul 2025 11:58:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1012:
>> 
>>> 1010:     private transient Object[] signers; // Read by VM, mutable
>>> 1011:     private final transient char modifiers;  // Set by the VM
>>> 1012:     private final transient char rawAccessFlags;  // Set by the VM
>> 
>> I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.
>
> This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.

Thanks for the rename. I think `raw annotations` means the uninterpreted byte data in the attribute is carried over raw; this concept is less applicable to the access_flags u2 value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240075254

From stefank at openjdk.org  Tue Jul 29 14:38:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Jul 2025 14:38:57 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
Message-ID: <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>

On Tue, 29 Jul 2025 13:42:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

src/hotspot/os/posix/os_posix.cpp line 738:

> 736:   // On POSIX systems, the amount of allocatable memory is limited by the
> 737:   // size of the virtual address space.
> 738:   *limit = address_space_limit();

In @toxaart's PR the out parameter is never set if the return value is false. I think the reason why that was done was so that code could be written like this:

size_t value = 0;
if (os::memory_function(value)) {
  // Succeeded - do stuff
} else {
  // Failed - do other stuff
}

// Use 0 if the function returned an error
use(value);


I think we should strive for unification around that in the various os:: memory functions. I also think that he used `&` in his patch and this function uses a pointer with the output parameter. Unification around would be good as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2240073711

From jiangli at openjdk.org  Tue Jul 29 14:52:04 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Jul 2025 14:52:04 GMT
Subject: Integrated: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
In-Reply-To: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
Message-ID: <9tMYAoKMXGgywhvXWMHVkLMhn0N81EjOyfTzXQy1UsI=.253e9c94-599a-415f-94b9-6c90de41d5b8@github.com>

On Fri, 18 Jul 2025 19:33:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
> 
> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.

This pull request has now been integrated.

Changeset: c239c0ab
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588
Stats:     5 lines in 2 files changed: 3 ins; 0 del; 2 mod

8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on x86_64 with AVX instruction extensions

Reviewed-by: rasbold

-------------

PR: https://git.openjdk.org/jdk/pull/26395

From rriggs at openjdk.org  Tue Jul 29 15:02:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 15:02:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
Message-ID: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>

On Tue, 29 Jul 2025 13:43:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.

src/java.base/share/classes/java/lang/Class.java line 248:

> 246:         protectionDomain = pd;
> 247:         primitive = isPrim;
> 248:         classFileAccessFlags = flags;

Its not that hard to add a field, why not have done this for identity?

src/java.base/share/classes/java/lang/Class.java line 4143:

> 4141:       * {@code FINAL}.
> 4142:       * If this {@code Class} object represents an array type return 0. This
> 4143:       * is not called in Class but can be called with an array type in Reflection.

The comment about "not called in Class" may get stale. I don't think it needs to be specified.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:

> 85:         class Holder {
> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 87:         }

Yuck, another class and another shared secret.
There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
It just returning a value from a static field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240132537
PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240117128
PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240126279

From eastigeevich at openjdk.org  Tue Jul 29 15:10:02 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 29 Jul 2025 15:10:02 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
Message-ID: <s_q_z4IXZuzFU3YqYj-Vle_hJvU0U2_jOmtY_f5bTi4=.54a50c9f-a5b5-4bc7-b6d8-483e42a54377@github.com>

On Fri, 25 Jul 2025 17:42:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>> 
>> Also included as part of the PR (suggested by @rasbold), moved the assert to after the `stubs` log info output.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @eastig review comment:
>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

lgtm

-------------

PR Review: https://git.openjdk.org/jdk/pull/26395#pullrequestreview-3068022638

From adinn at openjdk.org  Tue Jul 29 15:10:57 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 29 Jul 2025 15:10:57 GMT
Subject: RFR: 8364269: Simplify code cache API by storing adapter entry
 offsets in blob [v2]
In-Reply-To: <nRXklgQwULUswAo4-TFzFsorEZcgnTXiF2F_I3uclVs=.fa3dd0a0-2df3-4985-86b0-0a07b87f53e5@github.com>
References: <a1A-ARHjCbBU1DKDqZZZFH-rF0PiTETca7sK_P-F55U=.7a596a78-72ef-4125-89b4-ebcca5ceb47f@github.com>
 <nRXklgQwULUswAo4-TFzFsorEZcgnTXiF2F_I3uclVs=.fa3dd0a0-2df3-4985-86b0-0a07b87f53e5@github.com>
Message-ID: <wakC-ApngC6Wc8n4tdiIXsdMVsXtlhux4V0JIzK1Obw=.d753dc9a-8888-4d5a-b614-214a6fe4e46c@github.com>

On Tue, 29 Jul 2025 13:28:15 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.
>
> Andrew Dinn 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364269
>  - simplify code cache API by storing adapter entry offsets in blob

Ah, sorry, the merge appears to have caused some issues in debug builds. Will let you know when this is ready again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3132969223

From liach at openjdk.org  Tue Jul 29 15:26:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 15:26:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>

On Tue, 29 Jul 2025 14:55:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/java/lang/Class.java line 248:
> 
>> 246:         protectionDomain = pd;
>> 247:         primitive = isPrim;
>> 248:         classFileAccessFlags = flags;
> 
> Its not that hard to add a field, why not have done this for identity?

Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240207422

From stuefe at openjdk.org  Tue Jul 29 15:38:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 15:38:57 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
Message-ID: <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>

On Tue, 29 Jul 2025 14:29:54 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Just want to start of by saying thank you for taking the time with this.
> 
> > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
> 
> I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
> 
> On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.

Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be  good name. It will always be a guess anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3133066781

From jiangli at openjdk.org  Tue Jul 29 16:04:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Jul 2025 16:04:02 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
Message-ID: <iLEzquu7YGFACkgpv48-CpLsfbjOyfuqPbj2fqXaLok=.1c2db186-609e-455e-a52d-89b73fe0baf0@github.com>

On Fri, 25 Jul 2025 17:42:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @eastig review comment:
>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

Thanks. I also updated the PR description to reflect the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3133151673

From asmehra at openjdk.org  Tue Jul 29 16:22:54 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Jul 2025 16:22:54 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs [v2]
In-Reply-To: <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
 <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>
Message-ID: <QaPnqXAqjM9hm4X1TssXwD7NpZSKDZaNPe-Akf3BuHA=.ca98f2ec-10bb-4805-a710-99790b915f40@github.com>

On Tue, 29 Jul 2025 07:29:42 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Array copy stubs may legitimately generate SEGV errors during copying. They rely on class UnsafeMemoryAccess to record and expose to the signal handler a table of address ranges within which a SEGV should be dealt with by redirecting execution to an associated handler address. The handler address may lie within the same stub or may default to an independent entry belonging to a specific, non-copy stub within the same blob. Normally entries are added to the table as a side-effect of generating the stub.
>> 
>> This patch implements the preliminary steps needed to enable save and restore of the UnsafeMemoryAccess table entries alongside with their associated AOT compiled copy stubs. It adds the common entry to the entry declarations list so it can be saved to the AOT cache during the assembly phase and reloaded, relocated and installed as the table default entry during a production run. It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update all arches to set unsafecopy_common entry

looks fine to me

-------------

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26511#pullrequestreview-3068293619

From liach at openjdk.org  Tue Jul 29 16:32:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 16:32:51 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Docs from Rose

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/49f7bd5b..d979778d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=12-13

  Stats: 127 lines in 2 files changed: 77 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/25922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922

PR: https://git.openjdk.org/jdk/pull/25922

From kvn at openjdk.org  Tue Jul 29 16:35:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 16:35:56 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs [v2]
In-Reply-To: <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
 <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>
Message-ID: <R0LyfCy1eb1lab1_MV5LAUJ1aUg4oEUwAKozOWZVfdI=.6415a134-8de2-4161-b4a1-6305a889232a@github.com>

On Tue, 29 Jul 2025 07:29:42 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Array copy stubs may legitimately generate SEGV errors during copying. They rely on class UnsafeMemoryAccess to record and expose to the signal handler a table of address ranges within which a SEGV should be dealt with by redirecting execution to an associated handler address. The handler address may lie within the same stub or may default to an independent entry belonging to a specific, non-copy stub within the same blob. Normally entries are added to the table as a side-effect of generating the stub.
>> 
>> This patch implements the preliminary steps needed to enable save and restore of the UnsafeMemoryAccess table entries alongside with their associated AOT compiled copy stubs. It adds the common entry to the entry declarations list so it can be saved to the AOT cache during the assembly phase and reloaded, relocated and installed as the table default entry during a production run. It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update all arches to set unsafecopy_common entry

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26511#pullrequestreview-3068334611

From duke at openjdk.org  Tue Jul 29 16:42:56 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 16:42:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>

On Tue, 29 Jul 2025 14:52:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:
> 
>> 85:         class Holder {
>> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
>> 87:         }
> 
> Yuck, another class and another shared secret.
> There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
> It just returning a value from a static field.

Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240401098

From asmehra at openjdk.org  Tue Jul 29 16:57:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Jul 2025 16:57:56 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
In-Reply-To: <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
 <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
Message-ID: <hunLzgP9z6mdqQMvlrA0IVKpr-JPhAiE8Xp8v5jRhYs=.409db0b7-2f13-44e6-8bef-1f9969e1c4cb@github.com>

On Tue, 29 Jul 2025 06:48:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
>> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
>> Platforms affected: x86-64 and aarch64
>> Other platforms can be done if and when Leyden changes are ported to them.
>> 
>> [0] https://github.com/openjdk/leyden/pull/84
>
> src/hotspot/share/runtime/abstract_vm_version.hpp line 50:
> 
>> 48: template<size_t bufsz> class FormatBuffer;
>> 49: 
>> 50: using CpuInfoBuffer = FormatBuffer<CPU_INFO_BUF_SIZE>;
> 
> Is it important that we avoid dynamic allocation at this stage of VM initialization? Is that why we can't use `stringStream` instead?

Yeah, I think stringStream can be used as well. Dynamic allocation shouldn't be a concern. I can set the initial size to be same as the CPU_INFO_BUF_SIZE to reduce churn a bit. I will try this out. Thanks for the suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2240438860

From jrose at openjdk.org  Tue Jul 29 18:06:59 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 29 Jul 2025 18:06:59 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <pqu5PL1gbS0T8-oTG9tYv825aSj_ggQGfPTBA3mnGcs=.317bf43b-1285-4fa2-a717-02cdb7ee53a0@github.com>

On Tue, 29 Jul 2025 16:32:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Docs from Rose

Marked as reviewed by jrose (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3068641494

From amenkov at openjdk.org  Tue Jul 29 18:11:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Jul 2025 18:11:02 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
Message-ID: <w-MEFRXL_10nmhgyp279YB0eZXGnbZIQSsguRbFrGG8=.68bf779c-9316-433d-a237-0f2a00bd5045@github.com>

On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> Fixed type errors in documentation, minor changes.
> 
> Thanks!

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3068654927

From kvn at openjdk.org  Tue Jul 29 18:20:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 18:20:06 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
Message-ID: <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>

On Fri, 25 Jul 2025 17:42:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @eastig review comment:
>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

There was no GHA testing for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3133566090

From asmehra at openjdk.org  Tue Jul 29 18:22:03 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Jul 2025 18:22:03 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
In-Reply-To: <baw5o4WZsa7yPUeqBKRX3ylc-_2dLNke-ijPvYDRqSE=.ce87266e-77ec-4884-bc7a-e9f971389c80@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
 <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
 <baw5o4WZsa7yPUeqBKRX3ylc-_2dLNke-ijPvYDRqSE=.ce87266e-77ec-4884-bc7a-e9f971389c80@github.com>
Message-ID: <nT4AzjCU7E9yG1sMlHDbmM-tUZLBWZlx43o4jG85Ls0=.9dc6a176-c196-4028-b3e0-6fd86d1af82b@github.com>

On Tue, 29 Jul 2025 07:00:10 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 1113:
>> 
>>> 1111:   insert_features_names(_features, info_buffer);
>>> 1112: 
>>> 1113:   _cpu_info_string = os::strdup(info_buffer);
>> 
>> Sorry, I'm going to need some help here :-). How can passing a `FormatBuffer` to `os::strdup` not fail to compile?
>
> And here we do `os::strdup`, so now we do have dynamic allocation, so maybe just use a `stringStream`?

> Sorry, I'm going to need some help here :-). How can passing a FormatBuffer to os::strdup not fail to compile?

It works because of this trick in its base class FormatBufferBase:


operator const char *() const { return _buf; }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2240612588

From asmehra at openjdk.org  Tue Jul 29 18:22:07 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Jul 2025 18:22:07 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer
In-Reply-To: <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
 <WXyP6I43UfF1_MJfp9D_MZQfKCqWBxchur4O2kkZq30=.7ae21b14-134e-4eaf-8c7c-659c960f8100@github.com>
Message-ID: <g3HlpZPyVH6i57BF-rlZIat5LP46Q-vRxfA57qqBAl8=.29b59e41-1193-4dac-a5ef-4f1c4b5586d7@github.com>

On Tue, 29 Jul 2025 07:16:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
>> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
>> Platforms affected: x86-64 and aarch64
>> Other platforms can be done if and when Leyden changes are ported to them.
>> 
>> [0] https://github.com/openjdk/leyden/pull/84
>
> src/hotspot/share/utilities/formatBuffer.hpp line 90:
> 
>> 88:     }
>> 89:     return;
>> 90:   }
> 
> This method seems overly specific to the use-case.
> 
> Something like this is more widely applicable.
> 
> ```c++
> // Append strings returned by gen, separating each with separator.
> // Stops when gen returns null or when buffer is out of space.
> template <typename Generator>
> void join(Generator gen, const char* separator) {
>     bool first = true;
>     const char* str = gen();
>     while (str != nullptr) {
>       const char* sep = first ? "" : separator;
>       int result = append("%s%s", sep, str);
>       if (result < 0) {
>         return;
>       }
>       first = false;
>     }
>   return;
> }
> 
> 
> Example usage:
> 
> ```c++
> void VM_Version::insert_features_names(uint64_t features, CpuInfoBuffer& info_buffer) {
>   int i = 0;
>   info_buffer.join([&]() {
>     while (!supports_feature((VM_Version::Feature_Flag)i) && i < MAX_CPU_FEATURES) {
>       i++;
>     }
>     if (i >= MAX_CPU_FEATURES) {
>       return nullptr;
>     }
>     return _features_names[i];
>   }, ", ");
>   assert(!info_buffer.overflow(), "not enough buffer size");
> }

+1
I can add this to the stringStream class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26515#discussion_r2240617283

From jiangli at openjdk.org  Tue Jul 29 18:30:01 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Jul 2025 18:30:01 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
Message-ID: <h6Q5WqfRqr3_ubJoq5X9tPIX902db46eAqxg8jwRD9o=.2732c845-d7b7-49b7-9c0e-608f5593c2e4@github.com>

On Tue, 29 Jul 2025 18:17:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> There was no GHA testing for this.

@vnkozlov Do you referring to the PR testing? It's https://github.com/openjdk/jdk/pull/26395/checks, thanks.

For the specific bug manifesting with TestLWLockingCodeGen.java failure, currently GHA doesn't run tests on debug build for static jdk jobs. It also requires the testing x86_64 machine support AVX extensions to show the issue. That's the reason why GHA has not found the issue yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3133597439

From iklam at openjdk.org  Tue Jul 29 18:52:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Jul 2025 18:52:00 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <VEyiMBwGZC0dwBCZQPVETSm9tgMaO2wMiPnnxSZBDR0=.2ab71d4e-194d-45fb-8f76-965c8a1e9643@github.com>

On Tue, 29 Jul 2025 16:32:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Docs from Rose

Good to go!

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3068776696

From coleenp at openjdk.org  Tue Jul 29 19:58:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <0vCCEQN8w5kI1KG08bFyMXlpNkQ0ijhI6SSxrhkWPUs=.8104e221-c4fc-4524-ba67-79ab6b080dc0@github.com>

On Tue, 29 Jul 2025 14:49:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/java/lang/Class.java line 4143:
> 
>> 4141:       * {@code FINAL}.
>> 4142:       * If this {@code Class} object represents an array type return 0. This
>> 4143:       * is not called in Class but can be called with an array type in Reflection.
> 
> The comment about "not called in Class" may get stale. I don't think it needs to be specified.

Okay, I'll remove it.  I wanted to explain the change of the algorithm, and why I removed the handling for arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240785622

From coleenp at openjdk.org  Tue Jul 29 19:58:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:10 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v3]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments and remove Holder.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/163a8e5c..a4974473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From coleenp at openjdk.org  Tue Jul 29 19:58:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:14 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
Message-ID: <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>

On Tue, 29 Jul 2025 16:40:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:
>> 
>>> 85:         class Holder {
>>> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
>>> 87:         }
>> 
>> Yuck, another class and another shared secret.
>> There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
>> It just returning a value from a static field.
>
> Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.

Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.

I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240789122

From coleenp at openjdk.org  Tue Jul 29 19:58:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:11 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
Message-ID: <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>

On Tue, 29 Jul 2025 15:22:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 248:
>> 
>>> 246:         protectionDomain = pd;
>>> 247:         primitive = isPrim;
>>> 248:         classFileAccessFlags = flags;
>> 
>> Its not that hard to add a field, why not have done this for identity?
>
> Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.

For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240783242

From egahlin at openjdk.org  Tue Jul 29 20:15:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 20:15:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
Message-ID: <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>

On Tue, 29 Jul 2025 11:02:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:
>> 
>>> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
>>> 69:         p.waitFor();
>>> 70:         var output = new OutputAnalyzer(p);
>> 
>> I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.
>> 
>> Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.
>
> I'm going to run some testing before approving. 
> 
> I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
> https://openjdk.org/projects/amber/guides/lvti-style-guide

I get the following failure when testing your change:

`----------System.err:(15/955)----------
java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2240881106

From egahlin at openjdk.org  Tue Jul 29 20:35:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 20:35:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
Message-ID: <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>

On Tue, 29 Jul 2025 20:12:54 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I'm going to run some testing before approving. 
>> 
>> I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
>> https://openjdk.org/projects/amber/guides/lvti-style-guide
>
> I get the following failure when testing your change:
> 
> `----------System.err:(15/955)----------
> java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
> 	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.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1474)` 
> 	
> 	
> It is hard to guarantee a memory-leak sample. Other tests for OldObjectSample run in a loop until they succeed.
> 
> In the test, you use path-to-gc-roots=true. Is that really needed?

Using an EventStream might simplify the filtering, e.g.

        AtomicLong oldObjects = new AtomicLong();
        AtomicReference<String> reason = new AtomicReference<>();
        try (EventStream stream = EventStream.openFile(...)) {
            stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
            stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
            stream.start();
        }
        if (shouldCrash) {
            // validation
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2240950420

From liach at openjdk.org  Tue Jul 29 20:46:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 20:46:12 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <RuJVFyrfMPhXBVElRJ6jdP4Qbb-FGTOyQnenYyHJMjw=.8aeae265-bae2-4052-afea-d1b6022b5ffb@github.com>

On Tue, 29 Jul 2025 16:32:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
>> 
>> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
>> 
>> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
>> 
>> ---
>> 
>> Old description:
>> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Docs from Rose

Thanks for the reviews! I will go ahead and integrate to facilitate further work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3134009692

From liach at openjdk.org  Tue Jul 29 20:46:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 20:46:13 GMT
Subject: Integrated: 8360163: Replace hard-coded checks with AOTRuntimeSetup
 and AOTSafeClassInitializer
In-Reply-To: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <rpKLbPIgjNoo382AHdiGkDJoKsyEI8ydp-hPSCLozGI=.5f99f2e1-aa0e-482c-8dee-0eba9e66e541@github.com>

On Sat, 21 Jun 2025 00:03:26 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model.
> 
> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch.
> 
> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations.
> 
> ---
> 
> Old description:
> Currently, the list of classes that have <clinit> interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later.

This pull request has now been integrated.

Changeset: 330ee871
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/330ee871315348594171c43aa75b58f6027001af
Stats:     571 lines in 39 files changed: 401 ins; 150 del; 20 mod

8360163: Replace hard-coded checks with AOTRuntimeSetup and AOTSafeClassInitializer

Reviewed-by: jrose, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/25922

From asmehra at openjdk.org  Tue Jul 29 21:26:17 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Jul 2025 21:26:17 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer [v2]
In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
Message-ID: <j7XZblUCMZ_qI-pfSiUp_J1PVvTNy7yEtZbat6aAQbU=.74c6beab-7c39-4c16-8b56-8ace1a8a54fc@github.com>

> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
> Platforms affected: x86-64 and aarch64
> Other platforms can be done if and when Leyden changes are ported to them.
> 
> [0] https://github.com/openjdk/leyden/pull/84

Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:

 - Add changes missed in vm_version_bsd_aarch64.cpp
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Revert FormatBuffer changes
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Use stringStream instead of FormatBuffer
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26515/files
  - new: https://git.openjdk.org/jdk/pull/26515/files/704b12c4..6ab46995

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=00-01

  Stats: 136 lines in 10 files changed: 25 ins; 56 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/26515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26515/head:pull/26515

PR: https://git.openjdk.org/jdk/pull/26515

From duke at openjdk.org  Tue Jul 29 22:11:58 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 22:11:58 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v3]
In-Reply-To: <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>
Message-ID: <aWPGX886C2xiXvj-FM0Zuv_0n-lBkxu9FvJO_KgFDAE=.117026b1-282e-4b54-9b2f-34e965c2869b@github.com>

On Tue, 29 Jul 2025 19:58:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments and remove Holder.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 86:

> 84:     public static int getClassAccessFlags(Class<?> c) {
> 85:         JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 86:         return JLA.getClassFileAccessFlags(c);

Suggestion:

        return SharedSecrets.getJavaLangAccess().getClassFileAccessFlags(c);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2241101969

From duke at openjdk.org  Tue Jul 29 22:11:58 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 22:11:58 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
Message-ID: <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>

On Tue, 29 Jul 2025 19:46:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.
>
> Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.
> 
> I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.

I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.

Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.

[^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2241100994

From kvn at openjdk.org  Tue Jul 29 22:14:00 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 22:14:00 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
Message-ID: <1rVq_PPL7LUt9FNl9CZrndJ_ufDc_WAK1qlg11eAXR8=.85ce7377-81ef-4be0-8a33-f1cd706b852e@github.com>

On Tue, 29 Jul 2025 18:17:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @eastig review comment:
>>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.
>
> There was no GHA testing for this.

> @vnkozlov Do you refer to the PR testing? It's https://github.com/openjdk/jdk/pull/26395/checks, thanks.

Yes, that. I did not realize that GitHub removes it from main PR tab after integration.

Good, it was tested.  I think GitHub actions use AVX512 machines.  But I remember that static build testing was excluded.

First, I am fine with fix you pushed. But it is strange.

There should be no difference in stubs sizes running with regular JDK on avx512 machine and static JDK. I don't see how we don't trigger this issue in our testing - we regularly running on AVX512 machines.

Do you have additional code somewhere in macro assembler for static build? Is it possible to compare assembler code?
I see you posted sizes in bug report. Can you compare code for `StubRoutines::forward_exception()` which has smallest size to see what is difference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3134218373

From kvn at openjdk.org  Tue Jul 29 22:14:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 22:14:01 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
Message-ID: <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>

On Fri, 25 Jul 2025 17:42:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that increases the x86 initial stubs size to `21000` for `NOT_PRODUCT` only case.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @eastig review comment:
>   - Reverted change for moving the assert. Added code_size, buffer size and free to the assert output.

Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3134219400

From kvn at openjdk.org  Tue Jul 29 22:17:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Jul 2025 22:17:02 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <1rVq_PPL7LUt9FNl9CZrndJ_ufDc_WAK1qlg11eAXR8=.85ce7377-81ef-4be0-8a33-f1cd706b852e@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
 <1rVq_PPL7LUt9FNl9CZrndJ_ufDc_WAK1qlg11eAXR8=.85ce7377-81ef-4be0-8a33-f1cd706b852e@github.com>
Message-ID: <kIff57CEdzMcuxhA9vC0ysPSxRnpee5D8uKcW1sVGlU=.005bef07-6f3d-4b9a-9e16-d9ddb63d27e3@github.com>

On Tue, 29 Jul 2025 22:11:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Can you compare code for StubRoutines::forward_exception() which has smallest size to see what is difference.

Please run both, regular and static JDK, on AVX512 machine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3134224483

From amenkov at openjdk.org  Tue Jul 29 22:46:31 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Jul 2025 22:46:31 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v5]
In-Reply-To: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
Message-ID: <_GQzlne4wZImhl1_kpjq1fYPzGM3EE50Q21xStHNOOk=.9fbf6480-9564-4087-ba00-e486c0f7c920@github.com>

> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
> 
> Testing: tier1..5

Alex Menkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into tlh_stack_trace
 - carrier in TLH
 - removed comment
 - Update javaClasses.cpp
 - Merge branch 'master' into tlh_stack_trace
 - fix

-------------

Changes: https://git.openjdk.org/jdk/pull/26119/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=04
  Stats: 31 lines in 3 files changed: 1 ins; 7 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119

PR: https://git.openjdk.org/jdk/pull/26119

From jiangli at openjdk.org  Tue Jul 29 23:00:03 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Jul 2025 23:00:03 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <kIff57CEdzMcuxhA9vC0ysPSxRnpee5D8uKcW1sVGlU=.005bef07-6f3d-4b9a-9e16-d9ddb63d27e3@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
 <1rVq_PPL7LUt9FNl9CZrndJ_ufDc_WAK1qlg11eAXR8=.85ce7377-81ef-4be0-8a33-f1cd706b852e@github.com>
 <kIff57CEdzMcuxhA9vC0ysPSxRnpee5D8uKcW1sVGlU=.005bef07-6f3d-4b9a-9e16-d9ddb63d27e3@github.com>
Message-ID: <R5XJVa2cXrIMZI5GE_6-LaiO8f2l-FEgGiZN33PkTmI=.d633f6ff-3b35-4e09-ae75-63dbcd1b99c7@github.com>

On Tue, 29 Jul 2025 22:14:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> @vnkozlov Do you refer to the PR testing? It's https://github.com/openjdk/jdk/pull/26395/checks, thanks.
>> 
>> Yes, that. I did not realize that GitHub removes it from main PR tab after integration.
>> 
>> Good, it was tested.  I think GitHub actions use AVX512 machines.  But I remember that static build testing was excluded.
>> 
>> First, I am fine with fix you pushed. But it is strange.
>> 
>> There should be no difference in stubs sizes running with regular JDK on avx512 machine and static JDK. I don't see how we don't trigger this issue in our testing - we regularly running on AVX512 machines.
>> 
>> Do you have additional code somewhere in macro assembler for static build? Is it possible to compare assembler code?
>> I see you posted sizes in bug report. Can you compare code for `StubRoutines::forward_exception()` which has smallest size to see what is difference.
>
>> Can you compare code for StubRoutines::forward_exception() which has smallest size to see what is difference.
> 
> Please run both, regular and static JDK, on AVX512 machine.

Thanks for clarification @vnkozlov. 

> First, I am fine with fix you pushed. But it is strange.
> 
> There should be no difference in stubs sizes running with regular JDK on avx512 machine and static JDK. I don't see how we don't trigger this issue in our testing - we regularly running on AVX512 machines.

I was wondering the same initially, for regular JDK vs static JDK. So I did some measurements and confirmed the difference. Here is the data from the tests that I ran on machines with AVX extensions. I haven't looked into details of the generated instructions to see which ones are related, though.

static JDK

StubRoutines::forward_exception [0x00007f2b2e000ee0, 0x00007f2b2e001031] (337 bytes)

StubRoutines::call_stub [0x00007f2b2e001031, 0x00007f2b2e00142a] (1017 bytes)

StubRoutines::catch_exception [0x00007f2b2e00142a, 0x00007f2b2e00161d] (499 bytes)

StubRoutines::updateBytesCRC32 [0x00007f2b2e0017e0, 0x00007f2b2e001c8e] (1198 bytes)

StubRoutines::updateBytesCRC32C [0x00007f2b2e001ca0, 0x00007f2b2e0023b4] (1812 bytes)

StubRoutines::dsin [0x00007f2b2e0023cc, 0x00007f2b2e002b11] (1861 bytes)

StubRoutines::dtan [0x00007f2b2e003212, 0x00007f2b2e003b1a] (2312 bytes)

StubRoutines::dtanh [0x00007f2b2e003b1a, 0x00007f2b2e003e75] (859 bytes)

StubRoutines::dcbrt [0x00007f2b2e003e75, 0x00007f2b2e0040ea] (629 bytes)

StubRoutines::dexp [0x00007f2b2e0040ea, 0x00007f2b2e004477] (909 bytes)

StubRoutines::dpow [0x00007f2b2e004477, 0x00007f2b2e005652] (4571 bytes)

StubRoutines::dlog [0x00007f2b2e005652, 0x00007f2b2e0058e6] (660 bytes)

StubRoutines::dlog10 [0x00007f2b2e0058e6, 0x00007f2b2e005bce] (744 bytes)

StubRoutines::fmod [0x00007f2b2e005be0, 0x00007f2b2e005de7] (519 bytes)

[0.009s][info][stubs] StubRoutines (initialstubs) [0x00007f2b2e000ee0, 0x00007f2b2e006228] used: 20231, free: 1089;


regular JDK

StubRoutines::forward_exception [0x00007f018e000ee0, 0x00007f018e001015] (309 bytes)

StubRoutines::call_stub [0x00007f018e001015, 0x00007f018e0013c8] (947 bytes)

StubRoutines::catch_exception [0x00007f018e0013c8, 0x00007f018e001598] (464 bytes)

StubRoutines::updateBytesCRC32 [0x00007f018e001760, 0x00007f018e001bf9] (1177 bytes)

StubRoutines::updateBytesCRC32C [0x00007f018e001c00, 0x00007f018e002304] (1796 bytes)

StubRoutines::dsin [0x00007f018e00231c, 0x00007f018e0029ab] (1679 bytes)

StubRoutines::dcos [0x00007f018e0029ab, 0x00007f018e00301c] (1649 bytes)

StubRoutines::dtan [0x00007f018e00301c, 0x00007f018e003864] (2120 bytes)

StubRoutines::dtanh [0x00007f018e003864, 0x00007f018e003b48] (740 bytes)

StubRoutines::dcbrt [0x00007f018e003b48, 0x00007f018e003d5b] (531 bytes)

StubRoutines::dexp [0x00007f018e003d5b, 0x00007f018e004078] (797 bytes)

StubRoutines::dpow [0x00007f018e004078, 0x00007f018e005161] (4329 bytes)

StubRoutines::dlog [0x00007f018e005161, 0x00007f018e0053d2] (625 bytes)

StubRoutines::dlog10 [0x00007f018e0053d2, 0x00007f018e00567b] (681 bytes)

StubRoutines::fmod [0x00007f018e005680, 0x00007f018e005867] (487 bytes)

[0.005s][info][stubs] StubRoutines (initialstubs) [0x00007f018e000ee0, 0x00007f018e006228] used: 18823, free: 2497; code_size: 21000

>
> Do you have additional code somewhere in macro assembler for static build? Is it possible to compare assembler code? I see you posted sizes in bug report. Can you compare code for StubRoutines::forward_exception() which has smallest size to see what is difference.

> Please run both, regular and static JDK, on AVX512 machine.

There was not static specific in macro assembler. Let me try running the tests again and update ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3134308400

From amenkov at openjdk.org  Wed Jul 30 01:43:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 30 Jul 2025 01:43:37 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v6]
In-Reply-To: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
Message-ID: <Auu-gcX-tdhEoLeHkRwBDacsP980oh6gG7gxAQL0sMI=.53989ec7-47f9-4f37-ac82-59f5c45b90e1@github.com>

> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
> 
> Testing: tier1..5

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  fix broken build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26119/files
  - new: https://git.openjdk.org/jdk/pull/26119/files/6e5d0511..30275945

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26119&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26119/head:pull/26119

PR: https://git.openjdk.org/jdk/pull/26119

From duke at openjdk.org  Wed Jul 30 01:59:54 2025
From: duke at openjdk.org (Lei Zhu)
Date: Wed, 30 Jul 2025 01:59:54 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <w-MEFRXL_10nmhgyp279YB0eZXGnbZIQSsguRbFrGG8=.68bf779c-9316-433d-a237-0f2a00bd5045@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
 <w-MEFRXL_10nmhgyp279YB0eZXGnbZIQSsguRbFrGG8=.68bf779c-9316-433d-a237-0f2a00bd5045@github.com>
Message-ID: <FdiRtx3oZjY86K7qMG7CKdelnDoBZ51hh0bJIihR9JY=.3bb43be2-b18c-4d85-bd4f-85ee867bb876@github.com>

On Tue, 29 Jul 2025 18:08:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Hi all,
>> 
>> Fixed type errors in documentation, minor changes.
>> 
>> Thanks!
>
> Marked as reviewed by amenkov (Reviewer).

@alexmenkov Thank you for the review! And can you help me execute `/sponsor` command.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26521#issuecomment-3134616477

From sspitsyn at openjdk.org  Wed Jul 30 05:14:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 05:14:55 GMT
Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
Message-ID: <bQG9CVCOb6_j4BEXY4YeaCB1BXF09hncZ65JTUpT4CY=.83374f8a-e06e-4224-8f74-2b1551851c7e@github.com>

On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> Fixed type errors in documentation, minor changes.
> 
> Thanks!

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3069907149

From ysuenaga at openjdk.org  Wed Jul 30 05:16:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 05:16:42 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v5]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <TpROAmt5YuMtjVkKwByrfvVcZn309l6pQd-jlZ1bbBc=.2e5a5922-5e2f-4bd5-8eb2-45e62326a0cb@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update TestEmergencyDumpAtOOM.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/5ecd4e43..a20d56a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=03-04

  Stats: 58 lines in 1 file changed: 22 ins; 11 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From ysuenaga at openjdk.org  Wed Jul 30 05:16:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 05:16:42 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
Message-ID: <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>

On Tue, 29 Jul 2025 20:33:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I get the following failure when testing your change:
>> 
>> `----------System.err:(15/955)----------
>> java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
>> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
>> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
>> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
>> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
>> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
>> 	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.MainWrapper$MainTask.run(MainWrapper.java:138)
>> 	at java.base/java.lang.Thread.run(Thread.java:1474)` 
>> 	
>> 	
>> It is hard to guarantee a memory-leak sample. Other tests for OldObjectSample run in a loop until they succeed.
>> 
>> In the test, you use path-to-gc-roots=true. Is that really needed?
>
> Using an EventStream might simplify the filtering, e.g.
> 
>         AtomicLong oldObjects = new AtomicLong();
>         AtomicReference<String> reason = new AtomicReference<>();
>         try (EventStream stream = EventStream.openFile(...)) {
>             stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
>             stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
>             stream.start();
>         }
>         if (shouldCrash) {
>             // validation
>         }

I updated the test. I hope it works on your environment.

- Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
- Use `EventStream` to check JFR events as Erik shown
- Repeat the test if `OldObjectSample` does not appear on the flight record
- Remove `var` from test code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241548770

From duke at openjdk.org  Wed Jul 30 05:21:00 2025
From: duke at openjdk.org (Lei Zhu)
Date: Wed, 30 Jul 2025 05:21:00 GMT
Subject: Integrated: 8363920: JVMTI Documentation for GetLocalDouble is wrong:
 refers to long
In-Reply-To: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
References: <r8EY7u2emobxLhp8L1WMjFr0A6XvWHDA6aVULZsy7-s=.09effcf0-5322-468d-b9ed-bf84d9fff1f9@github.com>
Message-ID: <Sg6EOXcdAGA-IYFhCUHc0KoW9QjiTCY1uw0hr5aEln4=.553c37e5-e8b8-49e1-b0d6-5bb810b2324c@github.com>

On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Hi all,
> 
> Fixed type errors in documentation, minor changes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 1be412dc
Author:    Lei Zhu <korov9.c at gmail.com>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1be412dca08028d37a90cff1d4a67007c6b2d690
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long

Reviewed-by: alanb, amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/26521

From chagedorn at openjdk.org  Wed Jul 30 05:55:53 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 30 Jul 2025 05:55:53 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt, metaprogramming
In-Reply-To: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
Message-ID: <fW12DmE9OvzH5ReslAiXvL6TyqopOwlDuxGSLL7Es8c=.dbd858ca-3fa5-425e-ad32-eebf7c291bb6@github.com>

On Thu, 24 Jul 2025 13:19:36 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
> - hotspot/share/adlc 
> - hotspot/share/libadt
> - hotspot/share/metaprogramming
> 
> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
> 
> I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 and GHA.

Looks good, thanks for cleaning it up!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26460#pullrequestreview-3069974635

From sspitsyn at openjdk.org  Wed Jul 30 06:02:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Jul 2025 06:02:56 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
 <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
Message-ID: <VXhX0JjVKL3G2dxVI3HTyxNzYWeZzp-yJ27-catQeak=.bd6e70c2-901c-4888-846c-d29e88b8e348@github.com>

On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8364115
>  - sort includes

This looks okay

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3069986642

From haosun at openjdk.org  Wed Jul 30 06:04:55 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 30 Jul 2025 06:04:55 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <4Mxnjj-pjt-LP4gFxL8HMA5805Nam6TbotfFsuC5Oj8=.65109ba8-508a-4674-9d32-82ec1b2fd80f@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> 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, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

### some details

JDK source: master
jtreg version: `8+2` version
JDK build: `fastdebug`
OS: `ubuntu 24.04`
two jtreg test cases

test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java

how to reproduce:

make test TEST="test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java"
make test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java


### the snippet of error log for case `TestSPISigned.java` on AArch64


STDERR:                                                                                                                                                                                                                                                      
java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-calendar-provider/TestSPISigned.d/../provider/.                   
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)                                   
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:57)
        at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:161)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.base/java.nio.file.Files.readAttributes(Files.java:1702)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:216)                                                                                                                                                                     
        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:268)   
        at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:306)                                                                                                                                                                              
        at java.base/java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:69)                                          
        at java.base/java.nio.file.Files.find(Files.java:3649)                                                                
        at jdk.test.lib.util.JarUtils.findAllRegularFiles(JarUtils.java:425)                                                                                                                                                                                 
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:75)                                                         
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:106)                                                        
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:115)                                                        
        at TestSPISigned.main(TestSPISigned.java:84)                                                                                                                                                                                                         
        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)
                                                                                                                                                                                                                                                             
JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException                                                     
JavaTest Message: shutting down test                 
                                                               
                                                                                                                                                                                                                                                             
TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-cal
endar-provider/TestSPISigned.d/../provider/.
--------------------------------------------------
Test results: failed: 1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3134956713

From egahlin at openjdk.org  Wed Jul 30 07:15:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 30 Jul 2025 07:15:56 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
 <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
Message-ID: <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>

On Wed, 30 Jul 2025 05:13:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Using an EventStream might simplify the filtering, e.g.
>> 
>>         AtomicLong oldObjects = new AtomicLong();
>>         AtomicReference<String> reason = new AtomicReference<>();
>>         try (EventStream stream = EventStream.openFile(...)) {
>>             stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
>>             stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
>>             stream.start();
>>         }
>>         if (shouldCrash) {
>>             // validation
>>         }
>
> I updated the test. I hope it works on your environment.
> 
> - Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
> - Use `EventStream` to check JFR events as Erik shown
> - Repeat the test if `OldObjectSample` does not appear on the flight record
> - Remove `var` from test code

I will try running it. I think readability can be improved if everything under shouldCrash is grouped together, e.g.


if (oldObjects.get() > 0L) {
    if (shouldCrash) {
        Asserts.assertEquals("VM Error", shutdownReason.get());
        Asserts.assertEquals("Out of Memory", dumpReason.get());
    } else {
        Asserts.assertEquals("No remaining non-daemon Java threads", shutdownReason.get());
    }
    return;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241742584

From ayang at openjdk.org  Wed Jul 30 07:18:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 07:18:01 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
 <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
Message-ID: <jD2wx2otjtEnbESoFOV_imKiK3mJHSwP2b9IxiDJPjA=.7b6c48ea-c257-4c23-ba0f-2b01857c9a4a@github.com>

On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8364115
>  - sort includes

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3070189802

From lucy at openjdk.org  Wed Jul 30 07:23:57 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 30 Jul 2025 07:23:57 GMT
Subject: RFR: 8364199: Enhance list of environment variables printed in
 hserr/hsinfo file
In-Reply-To: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
References: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
Message-ID: <4JW9Tbafq2nq7hL1jy5witkTB0QS6F1XkX-xS-xTjB0=.e74db360-6423-4edf-8e48-736f44475f21@github.com>

On Mon, 28 Jul 2025 15:09:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file.
> JAVA_OPTS is used by lots of tools .
> WAYLAND_DISPLAY ( https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L492)  
> and JDK_AOT_VM_OPTIONS (https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.base/share/man/java.md?plain=1#L4052) are referenced in the codebase.

Change looks reasonable.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26509#pullrequestreview-3070205316

From ayang at openjdk.org  Wed Jul 30 07:27:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 07:27:58 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
Message-ID: <I5bFurUbu5kk6fFfwmhcu5HWqSMhI_C0bcyFK5bEX4s=.76405a1a-690e-459c-8747-8b2e592373af@github.com>

On Mon, 28 Jul 2025 10:51:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [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:
> 
>   Better comment

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26477#pullrequestreview-3070214352

From alanb at openjdk.org  Wed Jul 30 07:29:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 07:29:57 GMT
Subject: RFR: 8361103: java_lang_Thread::async_get_stack_trace does not
 properly protect JavaThread [v6]
In-Reply-To: <Auu-gcX-tdhEoLeHkRwBDacsP980oh6gG7gxAQL0sMI=.53989ec7-47f9-4f37-ac82-59f5c45b90e1@github.com>
References: <k2qOJ6aaZX8W9Bcp67upEG3HO6zDz7LFI54g_J3N_FM=.94a5caae-8dd1-4382-830f-be4c8e0440fa@github.com>
 <Auu-gcX-tdhEoLeHkRwBDacsP980oh6gG7gxAQL0sMI=.53989ec7-47f9-4f37-ac82-59f5c45b90e1@github.com>
Message-ID: <5w23bjrO_bq2kLPosHLsPiLSLLCelNaNQr2cLNs9b_E=.f4baadda-bcea-4f78-97f4-40df83fc65ed@github.com>

On Wed, 30 Jul 2025 01:43:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `java_lang_Thread::async_get_stack_trace()` (used by `java.lang.Thread.getStackTrace()` to get stack trace for platform and mounted virtual threads) to correctly use `ThreadListHandle` for thread protection.
>> 
>> Testing: tier1..5
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken build

I've created JDK-8364343 with a stress test that tickles several asserts that we can use for follow-on issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26119#issuecomment-3135161288

From mbaesken at openjdk.org  Wed Jul 30 07:33:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Jul 2025 07:33:05 GMT
Subject: RFR: 8364199: Enhance list of environment variables printed in
 hserr/hsinfo file
In-Reply-To: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
References: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
Message-ID: <dFAxNxS9mn8MWMU15PJbBzJkwdUUbPzF24la4nOrprw=.d36965cd-f6ca-4d1a-b926-662991bf34d5@github.com>

On Mon, 28 Jul 2025 15:09:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file.
> JAVA_OPTS is used by lots of tools .
> WAYLAND_DISPLAY ( https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L492)  
> and JDK_AOT_VM_OPTIONS (https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.base/share/man/java.md?plain=1#L4052) are referenced in the codebase.

Thanks for the review !

May I have a second review ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26509#issuecomment-3135169533

From ayang at openjdk.org  Wed Jul 30 07:36:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 07:36:55 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt, metaprogramming
In-Reply-To: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
Message-ID: <evgVVB0Akw6CU2y8djWwed4LaVH8IU13BfwBhxxwLs4=.4d0a4b4d-1e0a-48b9-9fa3-d69eac091612@github.com>

On Thu, 24 Jul 2025 13:19:36 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
> - hotspot/share/adlc 
> - hotspot/share/libadt
> - hotspot/share/metaprogramming
> 
> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
> 
> I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 and GHA.

src/hotspot/share/libadt/dict.cpp line 29:

> 27: // %%%%% includes not needed with AVM framework - Ungar
> 28: 
> 29: #include "libadt/dict.hpp"

Usually, "includes" proceeds doc-comments. Can you move up `assert.h` instead? (Also, I didn't find assert-usage in this file. Is it actually needed?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26460#discussion_r2241786693

From duke at openjdk.org  Wed Jul 30 07:59:55 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 07:59:55 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <jD2wx2otjtEnbESoFOV_imKiK3mJHSwP2b9IxiDJPjA=.7b6c48ea-c257-4c23-ba0f-2b01857c9a4a@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
 <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
 <jD2wx2otjtEnbESoFOV_imKiK3mJHSwP2b9IxiDJPjA=.7b6c48ea-c257-4c23-ba0f-2b01857c9a4a@github.com>
Message-ID: <6vjiWhh9MBkSMv0aX8btnSZzmRgA-fQigxyQKLfiWtI=.480621a3-cb5e-4281-8a87-def5e9e65606@github.com>

On Wed, 30 Jul 2025 07:15:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8364115
>>  - sort includes
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @sspitsyn thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26483#issuecomment-3135239668

From duke at openjdk.org  Wed Jul 30 07:59:56 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 07:59:56 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
 <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
Message-ID: <frxmE9h0LocxlZBc2eyi97NaNKISODtN92DXeivnj0Q=.ff0c93be-da5b-4d93-8969-cadc314ff831@github.com>

On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8364115
>  - sort includes

@fandreuz 
Your change (at version bd7c21eaba4f91797c6aee9ea0af9314a29f78cf) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26483#issuecomment-3135241941

From ysuenaga at openjdk.org  Wed Jul 30 08:37:37 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 08:37:37 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Refactor TestEmergencyDumpAtOOM.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/a20d56a7..544e7415

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=04-05

  Stats: 11 lines in 1 file changed: 3 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

PR: https://git.openjdk.org/jdk/pull/26468

From ysuenaga at openjdk.org  Wed Jul 30 08:37:38 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 08:37:38 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
 <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
 <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>
Message-ID: <o9cLr1LllrJGGgEQytVd5cQXriHScAwtWMRO8sNJpYY=.f06c7b4d-8771-4015-b2a2-0b5148f80720@github.com>

On Wed, 30 Jul 2025 07:13:38 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I updated the test. I hope it works on your environment.
>> 
>> - Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
>> - Use `EventStream` to check JFR events as Erik shown
>> - Repeat the test if `OldObjectSample` does not appear on the flight record
>> - Remove `var` from test code
>
> I will try running it. I think readability can be improved if everything under shouldCrash is grouped together, e.g.
> 
> 
> if (oldObjects.get() > 0L) {
>     if (shouldCrash) {
>         Asserts.assertEquals("VM Error", shutdownReason);
>         Asserts.assertEquals("Out of Memory", dumpReason);
>     } else {
>         Asserts.assertEquals("No remaining non-daemon Java threads", shutdownReason);
>     }
>     return;
> }

@egahlin 
I updated testcase as you shown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241927247

From duke at openjdk.org  Wed Jul 30 08:49:13 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 08:49:13 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v2]
In-Reply-To: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
Message-ID: <gobVJsNxvWVhZstcyJabgcjmcWUwN_3kBGhZErlcZFM=.86c71cd0-a345-479c-943a-c003d68900a2@github.com>

> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
> - hotspot/share/adlc 
> - hotspot/share/libadt
> - hotspot/share/metaprogramming
> 
> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
> 
> I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 and GHA.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  assert not needed. move up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26460/files
  - new: https://git.openjdk.org/jdk/pull/26460/files/82a437cb..bcddcb9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26460&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26460&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26460/head:pull/26460

PR: https://git.openjdk.org/jdk/pull/26460

From duke at openjdk.org  Wed Jul 30 08:49:13 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 08:49:13 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v2]
In-Reply-To: <evgVVB0Akw6CU2y8djWwed4LaVH8IU13BfwBhxxwLs4=.4d0a4b4d-1e0a-48b9-9fa3-d69eac091612@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
 <evgVVB0Akw6CU2y8djWwed4LaVH8IU13BfwBhxxwLs4=.4d0a4b4d-1e0a-48b9-9fa3-d69eac091612@github.com>
Message-ID: <HTE0e0qxdIK_yNw5OwSFy0fGVDR0xkbuNpDuVCo7Kxw=.b2c463ae-02a9-4487-b2df-3ad97628a5c3@github.com>

On Wed, 30 Jul 2025 07:34:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Can you move up assert.h instead? (Also, I didn't find assert-usage in this file. Is it actually needed?)

Actually, I found out `assert.h` is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26460#discussion_r2241956351

From ayang at openjdk.org  Wed Jul 30 09:09:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 09:09:54 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v2]
In-Reply-To: <gobVJsNxvWVhZstcyJabgcjmcWUwN_3kBGhZErlcZFM=.86c71cd0-a345-479c-943a-c003d68900a2@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
 <gobVJsNxvWVhZstcyJabgcjmcWUwN_3kBGhZErlcZFM=.86c71cd0-a345-479c-943a-c003d68900a2@github.com>
Message-ID: <C7-KuN1-9eKDR5Bm37YqwyeQF2aeaUs4-4qciRZiWvo=.b99e73f5-d2c2-4d05-b744-b314e5c75718@github.com>

On Wed, 30 Jul 2025 08:49:13 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
>> - hotspot/share/adlc 
>> - hotspot/share/libadt
>> - hotspot/share/metaprogramming
>> 
>> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
>> 
>> I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert not needed. move up

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26460#pullrequestreview-3070543595

From duke at openjdk.org  Wed Jul 30 09:19:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 09:19:22 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v14]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <ECt1DMDAJSm9fjVP5Goq0iATM0w-pMgw7tQHrl8AX7g=.9fa4da9f-7a91-416a-9a72-0a576d818042@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov 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 remote-tracking branch 'origin/master' into JDK-8357086_size_t_memfuncs
 - 8357086: Fxied return value
 - 8357086: Fixed whitespaces
 - 8357086: Introduced usage pattern
 - 8357086: Fixed typo
 - 8357086: Refactored physical_memory in different OS
 - 8357086: Small fixes 2
 - 8357086: Small fixes 1.
 - 8357086: Refactored physical_memory()
 - 8357086: Refactored free_swap_space()
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7b9a701a...372593b4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/e4698333..372593b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=12-13

  Stats: 60433 lines in 1772 files changed: 32969 ins; 17475 del; 9989 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From jsikstro at openjdk.org  Wed Jul 30 09:35:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:35:50 GMT
Subject: RFR: 8364248: Separate memory limit detection [v4]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  os:: unification in allocatable_memory_limit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/c4f27529..9b9d9f7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=02-03

  Stats: 22 lines in 4 files changed: 6 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From jsikstro at openjdk.org  Wed Jul 30 09:35:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:35:52 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <7A5dxzkgMGySA-ymfuhmhF6dqKpVvxFGt9ypRdJMfCs=.f62fc5ad-86e7-47e3-989a-c98e34f902d3@github.com>
Message-ID: <dGZniGfA9q_X2B7_ycEfxQUyJymR1UUtxPjPpMSY6EY=.6ffc3403-bb9b-42af-8b80-ca4dff4336ea@github.com>

On Tue, 29 Jul 2025 14:34:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()
>
> src/hotspot/os/posix/os_posix.cpp line 738:
> 
>> 736:   // On POSIX systems, the amount of allocatable memory is limited by the
>> 737:   // size of the virtual address space.
>> 738:   *limit = address_space_limit();
> 
> In @toxaart's PR the out parameter is never set if the return value is false. I think the reason why that was done was so that code could be written like this:
> 
> size_t value = 0;
> if (os::memory_function(value)) {
>   // Succeeded - do stuff
> } else {
>   // Failed - do other stuff
> }
> 
> // Use 0 if the function returned an error
> use(value);
> 
> 
> I think we should strive for unification around that in the various os:: memory functions. I also think that he used `&` in his patch and this function uses a pointer with the output parameter. Unification around would be good as well.

Sounds good. I'll change to using a reference instead of a pointer and only set the out-parameter if we return true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2242063296

From jsikstro at openjdk.org  Wed Jul 30 09:39:59 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:39:59 GMT
Subject: RFR: 8364248: Separate memory limit detection [v3]
In-Reply-To: <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
Message-ID: <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>

On Tue, 29 Jul 2025 15:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Just want to start of by saying thank you for taking the time with this.
> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
> > 
> > 
> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
> 
> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.

I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.

I'm open to chaning os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3135543197

From jsikstro at openjdk.org  Wed Jul 30 09:44:41 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:44:41 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v6]
In-Reply-To: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
Message-ID: <4P-hI1f0bLknqyybmbVFKn4FbpP91ClS_nlpmgrvnEs=.0b2a81f2-0fdc-4b6e-9dda-d7ad0e38ac1f@github.com>

> Hello,
> 
> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
> 
> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
> 
> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
> 
> Testing:
> * Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Revert extra whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25975/files
  - new: https://git.openjdk.org/jdk/pull/25975/files/56b0505b..b4f7c18e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25975&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25975/head:pull/25975

PR: https://git.openjdk.org/jdk/pull/25975

From jsikstro at openjdk.org  Wed Jul 30 09:44:41 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 30 Jul 2025 09:44:41 GMT
Subject: RFR: 8360515: PROPERFMTARGS should always use size_t template
 specialization for unit [v5]
In-Reply-To: <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
References: <PCWkd_yTgFKSAfy1cP2FbICVy7kx3B4nCREIfyMCefE=.a590a72c-5088-4ae9-92d9-054afab2a0f6@github.com>
 <L71WkhPYh8cFI63n2S1RykOXX_dmiWyUbowS-mSn7IE=.f257ee72-3563-4143-a008-039825302334@github.com>
Message-ID: <7QFvXLTQ0-16a3DITwu-g4DkrU0ltuvP8DGK1phAOsg=.a490d05f-faaf-4e2c-bd27-b8eedaf9297c@github.com>

On Mon, 28 Jul 2025 13:35:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> PROPERFMT is defined as the format string "%zu%s", which expects a size_t as input argument. When used in combination with PROPERFMTARGS, which uses the templated byte_size_in_proper_units, the byte size may not be size_t if the input is some other type.
>> 
>> To minimize confusion, PROPERFMTARGS should always use the size_t template specilization of byte_size_in_proper_units, to match PROPERFMT. Places that use byte_size_in_proper_units with other types can still use it, but should use their own format strings instead of PROPERFMT.
>> 
>> ProcSmapsSummary::print_on in memMapPrinter_macosx is the only place that uses PROPERFMTARGS with a type that is not size_t. I have changed those places to use the expanded version of the macro, which uses the templated version of byte_size_in_proper_unit instead.
>> 
>> Testing:
>> * Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace PROPERFMTARGs with expanded version in psAdaptiveSizePolicy.cpp
>  - Other alternative

Ping @dholmes-ora. Do you think this looks good?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25975#issuecomment-3135549555

From adinn at openjdk.org  Wed Jul 30 10:11:00 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 30 Jul 2025 10:11:00 GMT
Subject: RFR: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs [v2]
In-Reply-To: <R0LyfCy1eb1lab1_MV5LAUJ1aUg4oEUwAKozOWZVfdI=.6415a134-8de2-4161-b4a1-6305a889232a@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
 <t0irH2D5eE1PCUqoC6dIkO7QHvTnZI-I7Tffx3O075U=.1e6ddd23-6f24-4692-af89-e8f036a734b8@github.com>
 <R0LyfCy1eb1lab1_MV5LAUJ1aUg4oEUwAKozOWZVfdI=.6415a134-8de2-4161-b4a1-6305a889232a@github.com>
Message-ID: <uYY5G9aOpmcGQI1nSCjCKwOvjv0cVX7dxJ-t1HzzMU4=.866ce2ea-18e8-4a5b-bd61-282836a07dc8@github.com>

On Tue, 29 Jul 2025 16:33:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update all arches to set unsafecopy_common entry
>
> Good.

@vnkozlov @ashu-mehra Thanks for the reviews! Integrating now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26511#issuecomment-3135655848

From adinn at openjdk.org  Wed Jul 30 10:11:01 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 30 Jul 2025 10:11:01 GMT
Subject: Integrated: 8364042: UnsafeMemoryAccess will not work with AOT cached
 code stubs
In-Reply-To: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
References: <JFR-aBwAr2cnKBvNnZO7TvAJAI3Zhdlwy6VJLbzARHI=.ae2a3fd0-2eb6-4f00-8057-0c89f02b9754@github.com>
Message-ID: <4Sdqy374NHuaRcZ1J_YjAlU7XAoRSE0mOgxiFR2p_9o=.30334b09-07bd-443c-8d3a-56d52cd9545e@github.com>

On Mon, 28 Jul 2025 16:38:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Array copy stubs may legitimately generate SEGV errors during copying. They rely on class UnsafeMemoryAccess to record and expose to the signal handler a table of address ranges within which a SEGV should be dealt with by redirecting execution to an associated handler address. The handler address may lie within the same stub or may default to an independent entry belonging to a specific, non-copy stub within the same blob. Normally entries are added to the table as a side-effect of generating the stub.
> 
> This patch implements the preliminary steps needed to enable save and restore of the UnsafeMemoryAccess table entries alongside with their associated AOT compiled copy stubs. It adds the common entry to the entry declarations list so it can be saved to the AOT cache during the assembly phase and reloaded, relocated and installed as the table default entry during a production run. It also implements an API that allows table entries associated with a given stub to be identified and saved during an assembly run, and retrieved, relocated and restored to the table during a production run.

This pull request has now been integrated.

Changeset: a6fb87db
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6fb87dbe8c4165ca498caa23541f6aa4426b71d
Stats:     77 lines in 8 files changed: 63 ins; 12 del; 2 mod

8364042: UnsafeMemoryAccess will not work with AOT cached code stubs

Reviewed-by: asmehra, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/26511

From duke at openjdk.org  Wed Jul 30 10:15:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 10:15:54 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v2]
In-Reply-To: <gobVJsNxvWVhZstcyJabgcjmcWUwN_3kBGhZErlcZFM=.86c71cd0-a345-479c-943a-c003d68900a2@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
 <gobVJsNxvWVhZstcyJabgcjmcWUwN_3kBGhZErlcZFM=.86c71cd0-a345-479c-943a-c003d68900a2@github.com>
Message-ID: <3OiQW9llkDJVTrRNN0SNI4ykk1ZZI1ZhUd5TY4IXExo=.1fec98b8-f0cf-4b2c-90da-d539de650992@github.com>

On Wed, 30 Jul 2025 08:49:13 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
>> - hotspot/share/adlc 
>> - hotspot/share/libadt
>> - hotspot/share/metaprogramming
>> 
>> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
>> 
>> I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 and GHA.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert not needed. move up

@fandreuz 
Your change (at version bcddcb9e87af0d8fca7e70ee8b890b9c73c10971) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26460#issuecomment-3135674592

From shade at openjdk.org  Wed Jul 30 10:32:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 10:32:04 GMT
Subject: RFR: 8364115: Sort share/services includes [v2]
In-Reply-To: <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
 <Ew_Pi6E2hzQIm9xR3Ge8r_CQ5rKO2hxC6SO7Yfd6mgw=.734591d6-9045-44f9-9e3b-709423629a6a@github.com>
Message-ID: <btXMYilMHnwxgm0lyrB8SxPVzHWAcVSF9STEZ0yxEyA=.f4e471c6-4701-4037-9335-6b342e461999@github.com>

On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
>> 
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8364115
>  - sort includes

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3070803706

From duke at openjdk.org  Wed Jul 30 10:32:05 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 10:32:05 GMT
Subject: Integrated: 8364115: Sort share/services includes
In-Reply-To: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com>
Message-ID: <OnanYvPsDt6WeL0Z_sdSZkX-UzNSr8AHgtx5oac1cbw=.27585c4e-1413-4856-883b-1667ebf4114a@github.com>

On Fri, 25 Jul 2025 16:05:15 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`.
> 
> Passes tier1.

This pull request has now been integrated.

Changeset: c8517356
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8517356314c9dd1123401a21968009066053e5b
Stats:     42 lines in 12 files changed: 22 ins; 19 del; 1 mod

8364115: Sort share/services includes

Reviewed-by: sspitsyn, ayang, shade

-------------

PR: https://git.openjdk.org/jdk/pull/26483

From duke at openjdk.org  Wed Jul 30 10:36:15 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 10:36:15 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v3]
In-Reply-To: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
Message-ID: <x74xY9m2QFyYjTom2aV8p6Mmy3qcqxiC5QzePob8X2s=.496dc988-686b-4625-84ee-16d082fcb36b@github.com>

> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
> - hotspot/share/adlc 
> - hotspot/share/libadt
> - hotspot/share/metaprogramming
> 
> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
> 
> I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 and GHA.

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:

 - Merge branch 'master' into JDK-8364037
 - assert not needed. move up
 - move comment
 - sort

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26460/files
  - new: https://git.openjdk.org/jdk/pull/26460/files/bcddcb9e..caf2a092

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26460&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26460&range=01-02

  Stats: 4763 lines in 253 files changed: 2027 ins; 2203 del; 533 mod
  Patch: https://git.openjdk.org/jdk/pull/26460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26460/head:pull/26460

PR: https://git.openjdk.org/jdk/pull/26460

From coleenp at openjdk.org  Wed Jul 30 10:59:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 10:59:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
Message-ID: <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>

On Tue, 29 Jul 2025 21:59:41 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.
>> 
>> I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.
>
> I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.
> 
> Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.
> 
> [^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92

I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2242267576

From coleenp at openjdk.org  Wed Jul 30 11:05:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 11:05:34 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/a4974473..45b92c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From clanger at openjdk.org  Wed Jul 30 11:47:53 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 30 Jul 2025 11:47:53 GMT
Subject: RFR: 8364199: Enhance list of environment variables printed in
 hserr/hsinfo file
In-Reply-To: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
References: <fcRve_JhUhpR3vJTcjZY_54aLTFJMSoMEp2NnXhE5yI=.6f0b04ba-60aa-4237-8550-2397231d2f34@github.com>
Message-ID: <UXtLO82LBetsXMo6gPJJY5w22Zrb1HED6TWbEWutzYI=.deeb4178-b4a6-4bfe-8ac5-3717f2b71c68@github.com>

On Mon, 28 Jul 2025 15:09:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a number of interesting environment variables influencing the JVM/JDK that could be added to the list of environment variables printed in the hserr/hsinfo file.
> JAVA_OPTS is used by lots of tools .
> WAYLAND_DISPLAY ( https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L492)  
> and JDK_AOT_VM_OPTIONS (https://github.com/openjdk/jdk/blob/965b68107ffe1c1c988d4faf6d6742629407451b/src/java.base/share/man/java.md?plain=1#L4052) are referenced in the codebase.

Looks like reasonable additions.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26509#pullrequestreview-3071027124

From thartmann at openjdk.org  Wed Jul 30 12:23:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 30 Jul 2025 12:23:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
Message-ID: <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>

On Wed, 30 Jul 2025 11:05:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/hotspot/share/opto/memnode.cpp line 1986:

> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
> 1985:     assert(Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
> 1986:     return TypeInt::make(klass->access_flags());

I think this optimization should stay because the `_getSuperclass` intrinsic still emits a load from `Klass::access_flags_offset()` that could potentially be optimized here, see:
https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L4081-L4088
->
https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L3970-L3973

You can still remove the lines referencing `Reflection.getClassAccessFlags`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2242464835

From duke at openjdk.org  Wed Jul 30 13:34:57 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 13:34:57 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <tcI8HTc55K1JEVyGJGy2aX6iWIw9sisaKvDSM0kE1b8=.43e2ee12-6d17-4085-8fad-4d32c3a521d2@github.com>

On Tue, 29 Jul 2025 11:56:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 1. I really would like to see all the UL "X failed" log lines removed from this patch.

@stefank I understand your concerns. I can remove the logging for failed cases, but it will demise the proposed pattern. Without consensus on how to log such cases for JVM users, which is to be done in a later phase, I suggest to put TODO comments to the places where such logging should be done. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3136375559

From duke at openjdk.org  Wed Jul 30 13:38:11 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 13:38:11 GMT
Subject: RFR: 8364037: Sort share includes: adlc, libadt,
 metaprogramming [v3]
In-Reply-To: <x74xY9m2QFyYjTom2aV8p6Mmy3qcqxiC5QzePob8X2s=.496dc988-686b-4625-84ee-16d082fcb36b@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
 <x74xY9m2QFyYjTom2aV8p6Mmy3qcqxiC5QzePob8X2s=.496dc988-686b-4625-84ee-16d082fcb36b@github.com>
Message-ID: <DrQZ6uG9stD4Ntj71bl64Z4KcHfNoobaPpI_U1z-Phc=.848a9e15-e3b3-4f91-8cc8-494844326cb7@github.com>

On Wed, 30 Jul 2025 10:36:15 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
>> - hotspot/share/adlc 
>> - hotspot/share/libadt
>> - hotspot/share/metaprogramming
>> 
>> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
>> 
>> I'm also adding the directory to TestIncludesAreSorted.java.
>> 
>> Passes tier1 and GHA.
>
> 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:
> 
>  - Merge branch 'master' into JDK-8364037
>  - assert not needed. move up
>  - move comment
>  - sort

@fandreuz 
Your change (at version caf2a092a25bfc79620fb688e689fbb17179297a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26460#issuecomment-3136386728

From duke at openjdk.org  Wed Jul 30 13:47:05 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 30 Jul 2025 13:47:05 GMT
Subject: Integrated: 8364037: Sort share includes: adlc, libadt,
 metaprogramming
In-Reply-To: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
References: <JhEDfOnxmeE1gjPwTdFcWu7oFfJWyLStaskpkLL33oI=.3b2f7160-09b1-4de4-a90d-c2c9c1b42414@github.com>
Message-ID: <-6hsgk8_goTKaf5b9xIIJ_LouwbNjohONjN2sKm67lU=.7defbddd-ab43-4ee7-8b6b-eed6238a4aa9@github.com>

On Thu, 24 Jul 2025 13:19:36 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts includes using test/hotspot/jtreg/sources/SortIncludes.java in:
> - hotspot/share/adlc 
> - hotspot/share/libadt
> - hotspot/share/metaprogramming
> 
> I noticed some missing includes in several header files in`adlc/`, which caused compilation success to be dependent on the order of include statements in `adlc.hpp`. I moved the include statements to `adlparse.hpp` and `forms.hpp`.
> 
> I'm also adding the directory to TestIncludesAreSorted.java.
> 
> Passes tier1 and GHA.

This pull request has now been integrated.

Changeset: a2e86ff3
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2e86ff3c56209a14c6e9730781eecd12c81d170
Stats:     26 lines in 6 files changed: 14 ins; 11 del; 1 mod

8364037: Sort share includes: adlc, libadt, metaprogramming

Reviewed-by: ayang, chagedorn

-------------

PR: https://git.openjdk.org/jdk/pull/26460

From ayang at openjdk.org  Wed Jul 30 13:49:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Jul 2025 13:49:55 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
Message-ID: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>

On Wed, 30 Jul 2025 09:37:08 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...

Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.

> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...

I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3136433057

From asmehra at openjdk.org  Wed Jul 30 14:01:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 30 Jul 2025 14:01:56 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer [v3]
In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
Message-ID: <tIAj379LvkRpARNSsJ6bne7-gGaJSV6zERRIG6GA93o=.069b2b80-6c61-477f-869f-d10ad58f88de@github.com>

> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
> Platforms affected: x86-64 and aarch64
> Other platforms can be done if and when Leyden changes are ported to them.
> 
> [0] https://github.com/openjdk/leyden/pull/84

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Fix compile failures
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26515/files
  - new: https://git.openjdk.org/jdk/pull/26515/files/6ab46995..f3c80d7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=01-02

  Stats: 8 lines in 4 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26515/head:pull/26515

PR: https://git.openjdk.org/jdk/pull/26515

From duke at openjdk.org  Wed Jul 30 14:05:00 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:05:00 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <mG8KPBj5gvI6eMxbFaUV8ls09VtbsMinmvg2yp9YFak=.04465ba4-e0a6-4305-a33c-5b8e25707f4c@github.com>

On Tue, 29 Jul 2025 10:39:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - 8357086: Fxied return value
>>  - 8357086: Fixed whitespaces
>>  - 8357086: Introduced usage pattern
>>  - 8357086: Fixed typo
>>  - 8357086: Refactored physical_memory in different OS
>>  - 8357086: Small fixes 2
>>  - 8357086: Small fixes 1.
>>  - 8357086: Refactored physical_memory()
>>  - 8357086: Refactored free_swap_space()
>>  - 8357086: Refactored total_swap_space()
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333
>
> src/hotspot/os/bsd/os_bsd.cpp line 160:
> 
>> 158:     available = (vmstat.free_count + vmstat.inactive_count + vmstat.purgeable_count) * os::vm_page_size();
>> 159:   } else {
>> 160:     return false;
> 
> This looks like a change in behavior, but I guess it is a situation we shouldn't encounter or we would have hit the assert above.

I made it to be consistent with behavior of this method implementation on other platforms. Yes, the assert just about it should be hit before that.

> src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 406:
> 
>> 404: 
>> 405: JVM_ENTRY_NO_ENV(jlong, jfr_host_total_memory(JNIEnv* env, jclass jvm))
>> 406:   size_t phys_mem = 0;
> 
> This can be moved below where it is used. I would probably also be good to explicitly show that the return value is skipped.
> 
> With that said, now I've seen this pattern a number of times and think that it might be cleaner to have a function named `os::physical_memory_or_0()` (just like we have a bunch of "_or_null" functions) that returns 0 on failure. The code could then be:
> 
> #ifdef LINUX
>   // We want the host memory, not the container limit.
>   // os::physical_memory() would return the container limit.
>   return os::Linux::physical_memory();
> #else
>   return os::physical_memory_or_0();
> #endif
> 
> We can think about that proposal as a follow-up RFE.

I do not agree that it is clearer to have a function named   `os::physical_memory_or_0()`, because 0 does not necessarily mean a failure. It may well be a valid value for something on a system level. Not even touching various posix stuff returning 0 in case of success.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242800170
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242797831

From duke at openjdk.org  Wed Jul 30 14:11:58 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:11:58 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <VFdncvXl7yvYFjIS1FX26Efo6hR7cLsd8VLj7mZxU0k=.966cf833-e879-4493-a28a-a7fa0bd0151a@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <VFdncvXl7yvYFjIS1FX26Efo6hR7cLsd8VLj7mZxU0k=.966cf833-e879-4493-a28a-a7fa0bd0151a@github.com>
Message-ID: <2HazQXRv2W1X8noflzufBpZEZtxURBLlelofJz36G18=.8f9d4c0e-9af4-4c70-a156-b57b6c9a39d4@github.com>

On Tue, 29 Jul 2025 00:57:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Maybe we should have an `ATTRIBUTE_NODISCARD` macro with an always empty
> definition, and add it to all the functions being changed? Otherwise, once
> `[[nodiscard]]` becomes available, someone is going to have to hunt down all
> the relevant functions. Once we have C++17 we can revisit. It might take some
> preliminary call-site fixes before we can change the macro (or more likely,
> remove it and just use `[[nodiscard]]` directly).

@kimbarrett How about to change the return type from bool to some enum class? They are not implicitly convertible to integers, so one should not be able to ignore the return value of a function then. And we will not need a `[[nodiscard]]` in this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3136523519

From duke at openjdk.org  Wed Jul 30 14:20:00 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:20:00 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <yxNmHedbphTYSuGIAG1lrVj_eE_EYX-sysB-YcSIK8s=.0f74e187-b25b-44f9-ac83-e954be0e1dac@github.com>

On Tue, 29 Jul 2025 11:32:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - 8357086: Fxied return value
>>  - 8357086: Fixed whitespaces
>>  - 8357086: Introduced usage pattern
>>  - 8357086: Fixed typo
>>  - 8357086: Refactored physical_memory in different OS
>>  - 8357086: Small fixes 2
>>  - 8357086: Small fixes 1.
>>  - 8357086: Refactored physical_memory()
>>  - 8357086: Refactored free_swap_space()
>>  - 8357086: Refactored total_swap_space()
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333
>
> src/hotspot/share/compiler/compileBroker.cpp line 1062:
> 
>> 1060:   // Now, we do the more expensive operations.
>> 1061:   size_t free_memory = 0;
>> 1062:   os::free_memory(free_memory);
> 
> I wonder if this should be changed to something like this:
> Suggestion:
> 
>   // Return value ignored - defaulting to 0 on failure.
>   (void)os::free_memory(free_memory);
> 
> to clearly indicate the intent to skip the error check?

This is a valid point, but then we'll need to address it somehow else once a pattern with `[[nodiscard]]` or enum class return value is introduced. Or, simply add an empty clause for failure. For now, I will just put a comment there as suggested.

> src/hotspot/share/prims/whitebox.cpp line 2515:
> 
>> 2513:   LINUX_ONLY(return os::Linux::physical_memory();)
>> 2514:   os::physical_memory(phys_mem);
>> 2515:   return static_cast<jlong>(phys_mem);
> 
> This looks like the JFR code that doesn't want to report the container limits. We should probably have an os:: function that returns this value that both these functions wants. Maybe `os::host_physical_memory`. Something for a future RFE.

Agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242853425
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242858331

From duke at openjdk.org  Wed Jul 30 14:28:16 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:28:16 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v15]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Addressed reviewer's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/372593b4..b032b4dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=13-14

  Stats: 25 lines in 8 files changed: 7 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From duke at openjdk.org  Wed Jul 30 14:28:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:28:17 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <08Vitu5-rVx8f40vvl-WU4EE6ebzpUXVG-EbB_6kr6M=.cb45b7f9-d314-46ce-b912-e19e056ec77d@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <08Vitu5-rVx8f40vvl-WU4EE6ebzpUXVG-EbB_6kr6M=.cb45b7f9-d314-46ce-b912-e19e056ec77d@github.com>
Message-ID: <90FVHLdsathnlui4pBNGDYHfm-XDukiyd3VYKy8kD78=.3962068f-9b8c-42da-9932-b0776b1c8227@github.com>

On Tue, 29 Jul 2025 11:29:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/os/bsd/os_bsd.cpp line 290:
>> 
>>> 288:   if (sysctl(mib, 2, &mem_val, &len, nullptr, 0) != -1) {
>>> 289:     assert(len == sizeof(mem_val), "unexpected data size");
>>> 290:     _physical_memory = static_cast<size_t>(mem_val);
>> 
>> The `__OpenBSD__` section below still uses `julong`.
>
> It is also "interesting" that the BSD port doesn't propagate the failure to set up `_physical_memory` but the other platforms do. This adds an inconsistency across our platforms and I think that would be good to unify the behavior around that.

Thanks for spotting the missed code for __OpenBSD__ section. Addressed. 

I agree that BSD behaves somewhat differently compared to other platforms from this perspective. I suggest to create a separate issue and harmonize the behavior later separately.

>> src/hotspot/os/bsd/os_bsd.cpp line 1477:
>> 
>>> 1475:   if (!os::physical_memory(phys_mem)) {
>>> 1476:     log_debug(os, thread)("os::physical_memory() failed");
>>> 1477:   }
>> 
>> It's not clear to me that we want to have a side-effect of logging to UL here. Wouldn't it make more sense to log that physical memory info is not available to the provided `st` stream?
>
> FWIW, I find all these UL logging statements in the os::xxx_memory functions highly dubious, and think that it would be better to have some carefully thought-through places where we log system memory information. The spread-out of the UL logging in the various memory functions look like debugging aid for HotSpot devs and not really for the users of the JVM. So, maybe they could be at most be develop logging statements. I think this could be a discussion that needs to be done outside of this PR, but since even more logging statements are added with this PR I'm bringing this up here. Could we at least skip adding these log lines in this PR? The same comment goes for the rest of the platform files.

Logging removed, a proper one to be added back later.

>> src/hotspot/share/gc/shared/gcInitLogger.cpp line 70:
>> 
>>> 68:     log_debug_p(gc, init)("os::physical_memory() failed");
>>> 69:   }
>>> 70:   julong memory = static_cast<julong>(phys_mem);
>> 
>> I would prefer to not have the extra logging in the GC code + some extra restructuring:
>> 
>>   size_t memory = 0;
>>   if (os::physical_memory(memory)) {
>>     log_info_p(gc, init)("Memory: %zu%s",
>>                          byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
>>   } else {
>>     log_info_p(gc, init)("Memory: NA");
>>   }
>
> Alternatively:
> 
>   size_t memory = 0;
>   (void)os::physical_memory(memory);
>   log_info_p(gc, init)("Memory: %zu%s",
>                        byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));

Thanks, addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242880460
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242883898
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242888685

From duke at openjdk.org  Wed Jul 30 14:28:18 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:28:18 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <5ivPXgxObWJOIOa1bWaK6HNl0M2tPauhVEN1mZmO41I=.659e7fe7-c4ad-48db-984b-69721ed46a44@github.com>

On Tue, 29 Jul 2025 10:53:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - 8357086: Fxied return value
>>  - 8357086: Fixed whitespaces
>>  - 8357086: Introduced usage pattern
>>  - 8357086: Fixed typo
>>  - 8357086: Refactored physical_memory in different OS
>>  - 8357086: Small fixes 2
>>  - 8357086: Small fixes 1.
>>  - 8357086: Refactored physical_memory()
>>  - 8357086: Refactored free_swap_space()
>>  - 8357086: Refactored total_swap_space()
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333
>
> src/hotspot/os/bsd/os_bsd.cpp line 1482:
> 
>> 1480:   size_t avail_mem = 0;
>> 1481:   if (!os::available_memory(avail_mem))
>> 1482:   {
> 
> Suggestion:
> 
>   if (!os::available_memory(avail_mem)) {

Addressed.

> src/hotspot/os/windows/os_windows.cpp line 900:
> 
>> 898:   size_t phys_mem = win32::physical_memory();
>> 899:   if (phys_mem == std::numeric_limits<size_t>::max())
>> 900:   {
> 
> Suggestion:
> 
>   if (phys_mem == std::numeric_limits<size_t>::max()) {

Thanks, addressed.

> src/hotspot/share/gc/z/zLargePages.cpp line 37:
> 
>> 35:     log_debug_p(gc, init)("os::physical_memory() failed");
>> 36:   }
>> 37:   log_info_p(gc, init)("Memory: %zuM", phys_mem / M);
> 
> I have the same comment about this change as I have for `GCInitLogger::print_memory`.

Thanks, addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242885773
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242887388
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242889176

From stefank at openjdk.org  Wed Jul 30 14:35:59 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 14:35:59 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <yxNmHedbphTYSuGIAG1lrVj_eE_EYX-sysB-YcSIK8s=.0f74e187-b25b-44f9-ac83-e954be0e1dac@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <yxNmHedbphTYSuGIAG1lrVj_eE_EYX-sysB-YcSIK8s=.0f74e187-b25b-44f9-ac83-e954be0e1dac@github.com>
Message-ID: <Uz4PNJI3IKGGn8qtUMnm-Mv0Kq3-tVwpqBouF8lXmpw=.ba7cb3f2-e44a-45a8-8e73-5c5fc77908b0@github.com>

On Wed, 30 Jul 2025 14:16:16 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/share/compiler/compileBroker.cpp line 1062:
>> 
>>> 1060:   // Now, we do the more expensive operations.
>>> 1061:   size_t free_memory = 0;
>>> 1062:   os::free_memory(free_memory);
>> 
>> I wonder if this should be changed to something like this:
>> Suggestion:
>> 
>>   // Return value ignored - defaulting to 0 on failure.
>>   (void)os::free_memory(free_memory);
>> 
>> to clearly indicate the intent to skip the error check?
>
> This is a valid point, but then we'll need to address it somehow else once a pattern with `[[nodiscard]]` or enum class return value is introduced. Or, simply add an empty clause for failure. For now, I will just put a comment there as suggested.

Note that the main point here was the cast to (void) used to indicate that the return value is explicitly discarded. Does that not work with the [[nodiscard]]?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242915387

From duke at openjdk.org  Wed Jul 30 14:40:58 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:40:58 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
Message-ID: <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>

On Tue, 29 Jul 2025 11:11:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - 8357086: Fxied return value
>>  - 8357086: Fixed whitespaces
>>  - 8357086: Introduced usage pattern
>>  - 8357086: Fixed typo
>>  - 8357086: Refactored physical_memory in different OS
>>  - 8357086: Small fixes 2
>>  - 8357086: Small fixes 1.
>>  - 8357086: Refactored physical_memory()
>>  - 8357086: Refactored free_swap_space()
>>  - 8357086: Refactored total_swap_space()
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/75ce44aa...e4698333
>
> src/hotspot/os/linux/os_linux.cpp line 297:
> 
>> 295:   if (OSContainer::is_containerized()) {
>> 296:     if (OSContainer::memory_limit_in_bytes() > 0) {
>> 297:       value = static_cast<size_t>(OSContainer::memory_and_swap_limit_in_bytes() - OSContainer::memory_limit_in_bytes());
> 
> I might have wondered about this before, but can't `memory_and_swap_limit_in_bytes` return `-1` even when `memory_limit_in_bytes > 0` since -1 is treated as an "unlimited limit" here:
> 
> jlong CgroupV1MemoryController::read_mem_swap(julong host_total_memsw) {
>   julong memswlimit;
>   CONTAINER_READ_NUMBER_CHECKED(reader(), "/memory.memsw.limit_in_bytes", "Memory and Swap Limit", memswlimit);
>   if (memswlimit >= host_total_memsw) {
>     log_trace(os, container)("Memory and Swap Limit is: Unlimited");
>     return (jlong)-1;
>   }
> 
> Maybe this will be handled in a cleanup to the container subsystem?

I think we have discussed it above. In `os::free_swap_space(size_t& value)` implementation in `os_linux.cpp` the value returned by `OSContainer::memory_and_swap_limit_in_bytes()` is kept in a signed variable of `jlong` type. Then, if that value is negative, `host_free_swap_val` value will be returned, as that one is non-negative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242929678

From stefank at openjdk.org  Wed Jul 30 14:40:59 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 14:40:59 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <mG8KPBj5gvI6eMxbFaUV8ls09VtbsMinmvg2yp9YFak=.04465ba4-e0a6-4305-a33c-5b8e25707f4c@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <mG8KPBj5gvI6eMxbFaUV8ls09VtbsMinmvg2yp9YFak=.04465ba4-e0a6-4305-a33c-5b8e25707f4c@github.com>
Message-ID: <fOxKBGMlYStjljiwD7pY2jOLfEqefSGu3EP3M7_RqBg=.2e1ef4f8-b1ba-4ff1-ad6c-fb5a240fbd6f@github.com>

On Wed, 30 Jul 2025 14:02:05 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 406:
>> 
>>> 404: 
>>> 405: JVM_ENTRY_NO_ENV(jlong, jfr_host_total_memory(JNIEnv* env, jclass jvm))
>>> 406:   size_t phys_mem = 0;
>> 
>> This can be moved below where it is used. I would probably also be good to explicitly show that the return value is skipped.
>> 
>> With that said, now I've seen this pattern a number of times and think that it might be cleaner to have a function named `os::physical_memory_or_0()` (just like we have a bunch of "_or_null" functions) that returns 0 on failure. The code could then be:
>> 
>> #ifdef LINUX
>>   // We want the host memory, not the container limit.
>>   // os::physical_memory() would return the container limit.
>>   return os::Linux::physical_memory();
>> #else
>>   return os::physical_memory_or_0();
>> #endif
>> 
>> We can think about that proposal as a follow-up RFE.
>
> I do not agree that it is clearer to have a function named   `os::physical_memory_or_0()`, because 0 does not necessarily mean a failure. It may well be a valid value for something on a system level. Not even touching various posix stuff returning 0 in case of success.

I think there's a disconnect in our discussion here. My point is that we "laundry" whatever system level error you can get and instead return 0 whenever we can't figure out the amount of physical memory. The thinking is that surely 0 isn't a valid amount of physical memory, so lets have a convenient function that that is easy to use and returns 0 on failure? And the point is that let's use that instead of the handful places that perform the error handling just to convert it to 0 anyways.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242932188

From duke at openjdk.org  Wed Jul 30 14:44:59 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 14:44:59 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <Uz4PNJI3IKGGn8qtUMnm-Mv0Kq3-tVwpqBouF8lXmpw=.ba7cb3f2-e44a-45a8-8e73-5c5fc77908b0@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <yxNmHedbphTYSuGIAG1lrVj_eE_EYX-sysB-YcSIK8s=.0f74e187-b25b-44f9-ac83-e954be0e1dac@github.com>
 <Uz4PNJI3IKGGn8qtUMnm-Mv0Kq3-tVwpqBouF8lXmpw=.ba7cb3f2-e44a-45a8-8e73-5c5fc77908b0@github.com>
Message-ID: <ZUsUzs7gq4qU3DJPb5-qMxLCkAXqwEcE9ZcENPzgxv0=.dc3530f0-9434-4116-a40d-c8a5cfdc0983@github.com>

On Wed, 30 Jul 2025 14:32:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is a valid point, but then we'll need to address it somehow else once a pattern with `[[nodiscard]]` or enum class return value is introduced. Or, simply add an empty clause for failure. For now, I will just put a comment there as suggested.
>
> Note that the main point here was the cast to (void) used to indicate that the return value is explicitly discarded. Does that not work with the [[nodiscard]]?

Sorry, I completely missed that point. Need to check this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242944621

From stefank at openjdk.org  Wed Jul 30 14:57:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 14:57:04 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v15]
In-Reply-To: <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
Message-ID: <98vbaRlubl_2yNqNI_RDK9ponEsuEnWHl6x-eldK67U=.41e1a076-5a95-45d5-bab0-d5d4c5a6901f@github.com>

On Wed, 30 Jul 2025 14:28:16 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Addressed reviewer's comments

* I added some comments to the old resolved comments (Mentioning because they can be easy to miss).
* Some double-logging
* Small nits with the curly brackets
* There's still a bunch of logging that I don't think should be included.

src/hotspot/share/gc/shared/gcInitLogger.cpp line 71:

> 69:     log_info_p(gc, init)("Memory: NA");
> 70:   }
> 71:   julong memory = static_cast<julong>(phys_mem);

Something went wrong here. The old logging is still left. Could you get rid of size_t ?`phys_mem` and only have a `size_t memory` variable?

src/hotspot/share/gc/z/zLargePages.cpp line 37:

> 35:     log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(phys_mem), proper_unit_for_byte_size(phys_mem));
> 36:   }
> 37:   else {

Suggestion:

  } else {

src/hotspot/share/gc/z/zLargePages.cpp line 40:

> 38:     log_info_p(gc, init)("Memory: NA");
> 39:   }
> 40:   log_info_p(gc, init)("Memory: %zuM", phys_mem / M);

There's double-logging here now.

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 534:

> 532:   if (!os::physical_memory(phys_mem)) {
> 533:     log_debug(jfr, system)("os::physical_memory() failed");
> 534:   }

Suggestion:

  // Ignore return value
  (void)os::physical_memory(phys_mem);

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 541:

> 539:   if (!os::available_memory(avail_mem)) {
> 540:     log_debug(jfr, system)("os::available_memory() failed");
> 541:   }

Suggestion:

  // Ignore return value
  (void)os::available_memory(avail_mem);

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 551:

> 549:   if (!os::total_swap_space(total_swap_space)) {
> 550:     log_debug(jfr, system)("os::total_swap_space() failed");
> 551:   }

Suggestion:

  // Ignore return value
  (void)os::total_swap_space(total_swap_space);

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 556:

> 554:   if (!os::free_swap_space(free_swap_space)) {
> 555:     log_debug(jfr, system)("os::free_swap_space() failed");
> 556:   }

Suggestion:

  // Ignore return value
  (void)os::free_swap_space(free_swap_space);

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1364:

> 1362:     if (!os::available_memory(avail_mem)) {
> 1363:       log_debug(redefine, class, load)("os::available_memory() failed");
> 1364:     }

Suggestion:

    // Ignore return value
    (void)os::available_memory(avail_mem);

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4446:

> 4444:     if (!os::available_memory(avail_mem)) {
> 4445:       log_debug(redefine, class, load)("os::available_memory() failed");
> 4446:     }

Suggestion:

    // Ignore return value
    (void)os::available_memory(avail_mem);

src/hotspot/share/runtime/arguments.cpp line 1525:

> 1523:       if (!os::physical_memory(physical_mem_val)) {
> 1524:         log_debug(os)("os::physical_memory() failed");
> 1525:       }

Suggestion:

      // Ignore return value
      (void)os::physical_memory(physical_mem_val);

src/hotspot/share/runtime/arguments.cpp line 1535:

> 1533:     if (!os::physical_memory(physical_mem_val)) {
> 1534:       log_debug(os)("os::physical_memory() failed");
> 1535:     }

Suggestion:

    // Ignore return value
    (void)os::physical_memory(physical_mem_val);

src/hotspot/share/runtime/os.cpp line 1189:

> 1187:   if (!physical_memory(phys_mem)) {
> 1188:     log_debug(os)("os::physical_memory() failed");
> 1189:   }

Suggestion:

  // Ignore return value
  (void)physical_memory(phys_mem);

src/hotspot/share/runtime/os.cpp line 1950:

> 1948:   if (!os::physical_memory(phys_mem)) {
> 1949:     log_debug(os)("os::physical_memory() failed");
> 1950:   }

Suggestion:

  // Ignore return value
  (void)os::physical_memory(phys_mem);

src/hotspot/share/services/heapDumper.cpp line 2618:

> 2616:     if (!os::free_memory(free_memory)) {
> 2617:       log_debug(heapdump)("os::free_memory() failed");
> 2618:     }

Suggestion:

    (void)os::free_memory(free_memory);

-------------

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3071953120
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242945249
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242946849
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242949676
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242955062
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242956509
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242958211
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242963383
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242964402
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242972650
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242976795
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242978435
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242980698
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242983028
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2242985342

From stefank at openjdk.org  Wed Jul 30 15:00:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 15:00:01 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v15]
In-Reply-To: <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
Message-ID: <J1Rb5auOF83rb6SuDAIZnKNSpW6vYlbbyTVH8VbAgtY=.6e98bc31-46eb-40de-9e37-da7a5c7b58b0@github.com>

On Wed, 30 Jul 2025 14:28:16 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Addressed reviewer's comments

We try to refrain from adding TODO / FIXME comments in the code. If there's something that really needs to be done we tend to put that into a JBS issue instead.

-------------

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3072048580

From duke at openjdk.org  Wed Jul 30 15:09:41 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:09:41 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v16]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <fWBk8z83BhuDBDqKDLsR3f9EHWVCpKmsLtouZaN7e4Q=.59eff9b9-20c7-43ff-9ae3-717b0077533d@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Addressed reviewer's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/b032b4dd..0ed9b2e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=14-15

  Stats: 36 lines in 11 files changed: 8 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From stefank at openjdk.org  Wed Jul 30 15:09:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 15:09:41 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v16]
In-Reply-To: <fWBk8z83BhuDBDqKDLsR3f9EHWVCpKmsLtouZaN7e4Q=.59eff9b9-20c7-43ff-9ae3-717b0077533d@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <fWBk8z83BhuDBDqKDLsR3f9EHWVCpKmsLtouZaN7e4Q=.59eff9b9-20c7-43ff-9ae3-717b0077533d@github.com>
Message-ID: <2gVnCsryX3WJhStNa1JyzkCPRc2ln1CQCagLYJUd9eI=.793afca7-538c-430a-8b9d-2aaca77d1aa6@github.com>

On Wed, 30 Jul 2025 15:06:01 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Addressed reviewer's comments

I proposed the usage of (void) but you instead used static_cast<void>. We have an overwhelmingly larger set of (void) usages so I think you should stick to using the prevalent form.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3072087365

From stefank at openjdk.org  Wed Jul 30 15:09:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 15:09:42 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>
Message-ID: <cuR4GXKpL45Akw2pFcIHxGEikHBXZvwAKWOhN2E49II=.773f3f92-0eb9-4386-9947-059c49a80bb5@github.com>

On Wed, 30 Jul 2025 14:37:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 297:
>> 
>>> 295:   if (OSContainer::is_containerized()) {
>>> 296:     if (OSContainer::memory_limit_in_bytes() > 0) {
>>> 297:       value = static_cast<size_t>(OSContainer::memory_and_swap_limit_in_bytes() - OSContainer::memory_limit_in_bytes());
>> 
>> I might have wondered about this before, but can't `memory_and_swap_limit_in_bytes` return `-1` even when `memory_limit_in_bytes > 0` since -1 is treated as an "unlimited limit" here:
>> 
>> jlong CgroupV1MemoryController::read_mem_swap(julong host_total_memsw) {
>>   julong memswlimit;
>>   CONTAINER_READ_NUMBER_CHECKED(reader(), "/memory.memsw.limit_in_bytes", "Memory and Swap Limit", memswlimit);
>>   if (memswlimit >= host_total_memsw) {
>>     log_trace(os, container)("Memory and Swap Limit is: Unlimited");
>>     return (jlong)-1;
>>   }
>> 
>> Maybe this will be handled in a cleanup to the container subsystem?
>
> I think we have discussed it above. In `os::free_swap_space(size_t& value)` implementation in `os_linux.cpp` the value returned by `OSContainer::memory_and_swap_limit_in_bytes()` is kept in a signed variable of `jlong` type. Then, if that value is negative, `host_free_swap_val` value will be returned, as that one is non-negative.

My comment above is for the `total_swap_space` function and not the `free_swap_space` function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243020588

From duke at openjdk.org  Wed Jul 30 15:09:43 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:09:43 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v15]
In-Reply-To: <98vbaRlubl_2yNqNI_RDK9ponEsuEnWHl6x-eldK67U=.41e1a076-5a95-45d5-bab0-d5d4c5a6901f@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
 <98vbaRlubl_2yNqNI_RDK9ponEsuEnWHl6x-eldK67U=.41e1a076-5a95-45d5-bab0-d5d4c5a6901f@github.com>
Message-ID: <HE1uAushYs7Zg33ObihCyheJrvzHpA5O6aLiJdCdCBs=.adf4a1e6-846e-44a5-95da-238be9b408b4@github.com>

On Wed, 30 Jul 2025 14:42:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357086: Addressed reviewer's comments
>
> src/hotspot/share/gc/shared/gcInitLogger.cpp line 71:
> 
>> 69:     log_info_p(gc, init)("Memory: NA");
>> 70:   }
>> 71:   julong memory = static_cast<julong>(phys_mem);
> 
> Something went wrong here. The old logging is still left. Could you get rid of size_t ?`phys_mem` and only have a `size_t memory` variable?

Yes, missed that, removed.

> src/hotspot/share/gc/z/zLargePages.cpp line 37:
> 
>> 35:     log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(phys_mem), proper_unit_for_byte_size(phys_mem));
>> 36:   }
>> 37:   else {
> 
> Suggestion:
> 
>   } else {

Fixed.

> src/hotspot/share/gc/z/zLargePages.cpp line 40:
> 
>> 38:     log_info_p(gc, init)("Memory: NA");
>> 39:   }
>> 40:   log_info_p(gc, init)("Memory: %zuM", phys_mem / M);
> 
> There's double-logging here now.

Yes, missed that, removed.

> src/hotspot/share/runtime/arguments.cpp line 1525:
> 
>> 1523:       if (!os::physical_memory(physical_mem_val)) {
>> 1524:         log_debug(os)("os::physical_memory() failed");
>> 1525:       }
> 
> Suggestion:
> 
>       // Ignore return value
>       (void)os::physical_memory(physical_mem_val);

Removed.

> src/hotspot/share/runtime/arguments.cpp line 1535:
> 
>> 1533:     if (!os::physical_memory(physical_mem_val)) {
>> 1534:       log_debug(os)("os::physical_memory() failed");
>> 1535:     }
> 
> Suggestion:
> 
>     // Ignore return value
>     (void)os::physical_memory(physical_mem_val);

Removed.

> src/hotspot/share/runtime/os.cpp line 1189:
> 
>> 1187:   if (!physical_memory(phys_mem)) {
>> 1188:     log_debug(os)("os::physical_memory() failed");
>> 1189:   }
> 
> Suggestion:
> 
>   // Ignore return value
>   (void)physical_memory(phys_mem);

Removed.

> src/hotspot/share/runtime/os.cpp line 1950:
> 
>> 1948:   if (!os::physical_memory(phys_mem)) {
>> 1949:     log_debug(os)("os::physical_memory() failed");
>> 1950:   }
> 
> Suggestion:
> 
>   // Ignore return value
>   (void)os::physical_memory(phys_mem);

Removed.

> src/hotspot/share/services/heapDumper.cpp line 2618:
> 
>> 2616:     if (!os::free_memory(free_memory)) {
>> 2617:       log_debug(heapdump)("os::free_memory() failed");
>> 2618:     }
> 
> Suggestion:
> 
>     (void)os::free_memory(free_memory);

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243015718
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243015527
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243015153
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243013502
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243013337
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243013171
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243012954
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243012593

From duke at openjdk.org  Wed Jul 30 15:12:42 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:12:42 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v17]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <bwYhXaoGNQlwxPWh2tj_AtfA1v051S8BODAy0X3Vz8g=.84364056-a0e0-4c96-ae72-e953397f2563@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Addressed reviewer's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/0ed9b2e1..bbfedaf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=15-16

  Stats: 49 lines in 7 files changed: 0 ins; 33 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From asmehra at openjdk.org  Wed Jul 30 15:17:57 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 30 Jul 2025 15:17:57 GMT
Subject: RFR: 8364128: Improve gathering of cpu feature names using
 FormatBuffer [v4]
In-Reply-To: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
References: <0OB4WdhsTe7RDAYLe8tLHVn43gaUMa-NPXPi0RKoBHU=.33fa828d-ef24-4047-8080-9d033654d9a3@github.com>
Message-ID: <c6j4xscTjbZ1q-AQLGP8yBDmgx_HKm6cXqFpkuVHk5w=.8392f9d3-559d-4031-baad-cff1604c4baa@github.com>

> This PR implements the code for cpu features names string using FormatBuffer. It also improves and extends FormatBuffer with an additional method that appends comma separated strings to the buffer. This is useful in creating the cpu features names string.
> This code will also be useful in Leyden to implement cpu feature check for AOTCodeCache [0].
> Platforms affected: x86-64 and aarch64
> Other platforms can be done if and when Leyden changes are ported to them.
> 
> [0] https://github.com/openjdk/leyden/pull/84

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  More compile failure fix
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26515/files
  - new: https://git.openjdk.org/jdk/pull/26515/files/f3c80d7f..21383a7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26515&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26515/head:pull/26515

PR: https://git.openjdk.org/jdk/pull/26515

From duke at openjdk.org  Wed Jul 30 15:22:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:22:39 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Fixed void conversion.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/bbfedaf0..c994991b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=16-17

  Stats: 25 lines in 11 files changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From duke at openjdk.org  Wed Jul 30 15:22:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:22:39 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v17]
In-Reply-To: <bwYhXaoGNQlwxPWh2tj_AtfA1v051S8BODAy0X3Vz8g=.84364056-a0e0-4c96-ae72-e953397f2563@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <bwYhXaoGNQlwxPWh2tj_AtfA1v051S8BODAy0X3Vz8g=.84364056-a0e0-4c96-ae72-e953397f2563@github.com>
Message-ID: <6mvlVv6vkMzQEIoXX-pOu9qU4CUaxJYN5HsV5IQIsxM=.0cf2e0bf-9e83-409c-a1bb-68f189425448@github.com>

On Wed, 30 Jul 2025 15:12:42 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Addressed reviewer's comments

> I proposed the usage of (void) but you instead used static_cast. We have an overwhelmingly larger set of (void) usages so I think you should stick to using the prevalent form.

I think I addressed all points. As for `(void)` vs `static_cast<void>` conversion, the only benefit I see is shortness. But okay.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3136808153

From duke at openjdk.org  Wed Jul 30 15:22:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 30 Jul 2025 15:22:40 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v15]
In-Reply-To: <98vbaRlubl_2yNqNI_RDK9ponEsuEnWHl6x-eldK67U=.41e1a076-5a95-45d5-bab0-d5d4c5a6901f@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <-SwU0gkpvExZD27arXxLWizElfKi8cWSk_vUMbOHcTQ=.bc4ba843-99c3-4ce4-bfef-871c850f5067@github.com>
 <98vbaRlubl_2yNqNI_RDK9ponEsuEnWHl6x-eldK67U=.41e1a076-5a95-45d5-bab0-d5d4c5a6901f@github.com>
Message-ID: <hVR4yQrRkQ4zfNrEbyVUR7ysMt0ta2gIrtYHCEWuiLc=.cdc46fec-f562-484c-bb38-27d152610fa5@github.com>

On Wed, 30 Jul 2025 14:46:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357086: Addressed reviewer's comments
>
> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 551:
> 
>> 549:   if (!os::total_swap_space(total_swap_space)) {
>> 550:     log_debug(jfr, system)("os::total_swap_space() failed");
>> 551:   }
> 
> Suggestion:
> 
>   // Ignore return value
>   (void)os::total_swap_space(total_swap_space);

Removed.

> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 556:
> 
>> 554:   if (!os::free_swap_space(free_swap_space)) {
>> 555:     log_debug(jfr, system)("os::free_swap_space() failed");
>> 556:   }
> 
> Suggestion:
> 
>   // Ignore return value
>   (void)os::free_swap_space(free_swap_space);

Removed.

> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1364:
> 
>> 1362:     if (!os::available_memory(avail_mem)) {
>> 1363:       log_debug(redefine, class, load)("os::available_memory() failed");
>> 1364:     }
> 
> Suggestion:
> 
>     // Ignore return value
>     (void)os::available_memory(avail_mem);

Removed.

> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4446:
> 
>> 4444:     if (!os::available_memory(avail_mem)) {
>> 4445:       log_debug(redefine, class, load)("os::available_memory() failed");
>> 4446:     }
> 
> Suggestion:
> 
>     // Ignore return value
>     (void)os::available_memory(avail_mem);

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243058838
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243059007
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243059185
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243059382

From mgronlun at openjdk.org  Wed Jul 30 16:13:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Jul 2025 16:13:12 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized
Message-ID: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>

Greetings,

The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.

It does this in two parts:

1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.

Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8364258

Changes: https://git.openjdk.org/jdk/pull/26558/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364258
  Stats: 905 lines in 11 files changed: 407 ins; 482 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/26558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558

PR: https://git.openjdk.org/jdk/pull/26558

From stefank at openjdk.org  Wed Jul 30 16:21:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Jul 2025 16:21:00 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
Message-ID: <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>

On Wed, 30 Jul 2025 15:22:39 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the output value types for functions which return memory are changed, namely:
>> 
>> 
>> static julong available_memory(); --> static bool available_memory(size_t& value);
>> static julong used_memory(); --> static bool used_memory(size_t& value);
>> static julong free_memory(); --> static bool free_memory(size_t& value); 
>> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
>> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
>> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
>> 
>> 
>> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
>> 
>> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
>> 
>> Tested in GHA and Tiers 1-5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357086: Fixed void conversion.

>From my POV I think this starts to look OK except for a few nits.

I have a more lengthy comment below in Arguments::set_heap_size where I'm wondering if we really need to be returning an error in os::pysical_memory(). The question is mostly directed to Microsoft devs who might have insight into the memory API we use to query to get amount physical memory.

We could treat that question as a follow-up question and then maybe clean out the added error handling code (and places ignoring the error). Or we could try to resolve this before this PR is pushed so that we don't temporarily add all this extra error handling/ignoring code. What do you (and other reviewers) think?

src/hotspot/share/gc/shared/gcInitLogger.cpp line 70:

> 68:   } else {
> 69:     log_info_p(gc, init)("Memory: NA");
> 70:   }

Suggestion:

  size_t memory = 0;
  if (os::physical_memory(memory)) {
    log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
  } else {
    log_info_p(gc, init)("Memory: NA");
  }

src/hotspot/share/gc/z/zLargePages.cpp line 38:

> 36:   } else {
> 37:     log_info_p(gc, init)("Memory: NA");
> 38:   }

Restore removed blank line and renamed abbreviated double-word local. I'm a bit extra picky with the code in ZGC (and GC):
Suggestion:


  size_t memory = 0;
  if (os::physical_memory(memory)) {
    log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
  } else {
    log_info_p(gc, init)("Memory: NA");
  }

src/hotspot/share/runtime/arguments.cpp line 1510:

> 1508: void Arguments::set_heap_size() {
> 1509:   julong phys_mem;
> 1510:   size_t physical_mem_val = 0;

Restore blankline:
Suggestion:

  size_t physical_mem_val = 0;

src/hotspot/share/runtime/arguments.cpp line 1523:

> 1521:   if (override_coop_limit) {
> 1522:     if (FLAG_IS_DEFAULT(MaxRAM)) {
> 1523:       (void)os::physical_memory(physical_mem_val);

This is one of the places where things seems to break down if we ever get a failure from os::physical_memory(). Before this patch I guess you would get random values and after this patch you will propagate 0 through this function. So, I guess it is not worse than before, but if we really can get a failure here then we do have an existing bug here.

With that said, when looking at this I'm wondering if there is any scenario where we can hit an error when calling the os::physical_memory? I understand that the OS APIs says that we can hit an error, but I wonder if that's only a theoretical issue? If it turns out that the APIs in effect never will fail then we can verify that they succeed during the JVM initialization and then remove the error code from os os::physical_memory() and let it only return a size_t instead. If we do this we can clean away a lot of the error handling code that is added in this PR.

The places that I see that could theoretically fail is:

1) On AIX, but there's an `assert(0` in there to show that this really doesn't happen.

2) On Windows if GlobalMemoryStatusEx(&ms) fails. The question is will this call fail for any reason on Windows? Maybe someone from Microsoft could help and tell if there ever is a reason why this code would fail:

  MEMORYSTATUSEX ms;
  ms.dwLength = sizeof(ms);
  GlobalMemoryStatusEx(&ms);

-------------

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25450#pullrequestreview-3072202390
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243105949
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243109098
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243112602
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2243184566

From jpai at openjdk.org  Wed Jul 30 16:29:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 16:29:54 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> 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.

Hello Hao,

> Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3137036826

From ogillespie at openjdk.org  Wed Jul 30 16:32:37 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 30 Jul 2025 16:32:37 GMT
Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically
Message-ID: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>

We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected.


Intel(R) Xeon(R) Platinum 8259CL
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
Before:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
After:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {ergonomic}


Even worse when it's actually false, but shows as true:


AMD EPYC 7R13
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
Before:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
After:
     bool IntelJccErratumMitigation  = false  {ARCH diagnostic} {ergonomic}

-------------

Commit messages:
 - Set IntelJccErratumMitigation ergonomically

Changes: https://git.openjdk.org/jdk/pull/26560/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364296
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26560.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26560/head:pull/26560

PR: https://git.openjdk.org/jdk/pull/26560

From coleenp at openjdk.org  Wed Jul 30 16:57:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 16:57:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
 <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>
Message-ID: <rBLPujmr3-v-Q7wsXltMiQYVvequ6HozaHYVEppXE8o=.36c1331f-2592-4c18-a33b-14e307848f91@github.com>

On Wed, 30 Jul 2025 12:21:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/hotspot/share/opto/memnode.cpp line 1986:
> 
>> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
>> 1985:     assert(Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
>> 1986:     return TypeInt::make(klass->access_flags());
> 
> I think this optimization should stay because the `_getSuperclass` intrinsic still emits a load from `Klass::access_flags_offset()` that could potentially be optimized here, see:
> https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L4081-L4088
> ->
> https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L3970-L3973
> 
> You can still remove the lines referencing `Reflection.getClassAccessFlags`.

Thank you, right, the code still references Klass::_access_flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2243330614

From jiangli at openjdk.org  Wed Jul 30 17:40:01 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 17:40:01 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <kIff57CEdzMcuxhA9vC0ysPSxRnpee5D8uKcW1sVGlU=.005bef07-6f3d-4b9a-9e16-d9ddb63d27e3@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <wrOhwK96bCUbqNUHOEyLb67vqKQUwncpIxibG2X_5c0=.1df46bbe-d244-42a7-9461-ec2cc38b5372@github.com>
 <1rVq_PPL7LUt9FNl9CZrndJ_ufDc_WAK1qlg11eAXR8=.85ce7377-81ef-4be0-8a33-f1cd706b852e@github.com>
 <kIff57CEdzMcuxhA9vC0ysPSxRnpee5D8uKcW1sVGlU=.005bef07-6f3d-4b9a-9e16-d9ddb63d27e3@github.com>
Message-ID: <_0yEXE7rFQNCASDlai2VoRvDroC173wo2F88YPFipZc=.e5f1a8d1-6447-4246-b99a-5d68250e0137@github.com>

On Tue, 29 Jul 2025 22:14:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> @vnkozlov Do you refer to the PR testing? It's https://github.com/openjdk/jdk/pull/26395/checks, thanks.
>> 
>> Yes, that. I did not realize that GitHub removes it from main PR tab after integration.
>> 
>> Good, it was tested.  I think GitHub actions use AVX512 machines.  But I remember that static build testing was excluded.
>> 
>> First, I am fine with fix you pushed. But it is strange.
>> 
>> There should be no difference in stubs sizes running with regular JDK on avx512 machine and static JDK. I don't see how we don't trigger this issue in our testing - we regularly running on AVX512 machines.
>> 
>> Do you have additional code somewhere in macro assembler for static build? Is it possible to compare assembler code?
>> I see you posted sizes in bug report. Can you compare code for `StubRoutines::forward_exception()` which has smallest size to see what is difference.
>
>> Can you compare code for StubRoutines::forward_exception() which has smallest size to see what is difference.
> 
> Please run both, regular and static JDK, on AVX512 machine.

@vnkozlov I collected some info with `forward_exception_stub` on both regular and static JDK `fastdebug` binaries. For the `forward_exception_stub`, the generated instructions are not really affected with or without AVX extensions and the instruction sizes are the same on machines with or without AVX extensions when running the same JDK binary.

`forward_exception_stub` size is different when running on regular JDK and static JDK. Looking at the generated instructions in the stub, the most differences are due to call instructions. On static JDK, the target address needs to be moved into a register first then call using register, e.g.:


9c: 48 b8 00 3b 77 6c b3    movabs rax,0x55b36c773b00
a3: 55 00 00
a6: ff d0                   call   rax


On regular JDK, the target address can be encoded within the `call` instruction, e.g:


95: e8 46 46 e1 1a          call   0x1ae146e0


I recall @rasbold had suspected that could be what was causing the differences between static and regular JDKs, when we briefly discussed about the issue last week.

Here are the disassembled `forward_exception_stub`:

**static-jdk**

0:  49 83 7f 08 00          cmp    QWORD PTR [r15+0x8],0x0
5:  0f 85 79 00 00 00       jne    0x84
b:  48 81 ec 80 00 00 00    sub    rsp,0x80
12: 48 89 44 24 78          mov    QWORD PTR [rsp+0x78],rax
17: 48 89 4c 24 70          mov    QWORD PTR [rsp+0x70],rcx
1c: 48 89 54 24 68          mov    QWORD PTR [rsp+0x68],rdx
21: 48 89 5c 24 60          mov    QWORD PTR [rsp+0x60],rbx
26: 48 89 6c 24 50          mov    QWORD PTR [rsp+0x50],rbp
2b: 48 89 74 24 48          mov    QWORD PTR [rsp+0x48],rsi
30: 48 89 7c 24 40          mov    QWORD PTR [rsp+0x40],rdi
35: 4c 89 44 24 38          mov    QWORD PTR [rsp+0x38],r8
3a: 4c 89 4c 24 30          mov    QWORD PTR [rsp+0x30],r9
3f: 4c 89 54 24 28          mov    QWORD PTR [rsp+0x28],r10
44: 4c 89 5c 24 20          mov    QWORD PTR [rsp+0x20],r11
49: 4c 89 64 24 18          mov    QWORD PTR [rsp+0x18],r12
4e: 4c 89 6c 24 10          mov    QWORD PTR [rsp+0x10],r13
53: 4c 89 74 24 08          mov    QWORD PTR [rsp+0x8],r14
58: 4c 89 3c 24             mov    QWORD PTR [rsp],r15
5c: 48 be eb 15 00 66 24    movabs rsi,0x7f24660015eb
63: 7f 00 00
66: 48 8b d4                mov    rdx,rsp
69: 48 bf 20 95 e3 e0 1a    movabs rdi,0x561ae0e39520
70: 56 00 00
73: 48 83 e4 f0             and    rsp,0xfffffffffffffff0
77: 48 b8 d0 cc 61 e2 1a    movabs rax,0x561ae261ccd0
7e: 56 00 00
81: ff d0                   call   rax
83: f4                      hlt
84: 48 8b 3c 24             mov    rdi,QWORD PTR [rsp]
88: 48 8b f7                mov    rsi,rdi
8b: 49 8b ff                mov    rdi,r15
8e: 40 f6 c4 0f             test   spl,0xf
92: 0f 84 19 00 00 00       je     0xb1
98: 48 83 ec 08             sub    rsp,0x8
9c: 48 b8 00 bb 84 e2 1a    movabs rax,0x561ae284bb00
a3: 56 00 00
a6: ff d0                   call   rax
a8: 48 83 c4 08             add    rsp,0x8
ac: e9 0c 00 00 00          jmp    0xbd
b1: 48 b8 00 bb 84 e2 1a    movabs rax,0x561ae284bb00
b8: 56 00 00
bb: ff d0                   call   rax
bd: 48 8b d8                mov    rbx,rax
c0: 5a                      pop    rdx
c1: 49 8b 47 08             mov    rax,QWORD PTR [r15+0x8]
c5: 49 c7 47 08 00 00 00    mov    QWORD PTR [r15+0x8],0x0
cc: 00
cd: 48 85 c0                test   rax,rax
d0: 0f 85 79 00 00 00       jne    0x14f
d6: 48 81 ec 80 00 00 00    sub    rsp,0x80
dd: 48 89 44 24 78          mov    QWORD PTR [rsp+0x78],rax
e2: 48 89 4c 24 70          mov    QWORD PTR [rsp+0x70],rcx
e7: 48 89 54 24 68          mov    QWORD PTR [rsp+0x68],rdx
ec: 48 89 5c 24 60          mov    QWORD PTR [rsp+0x60],rbx
f1: 48 89 6c 24 50          mov    QWORD PTR [rsp+0x50],rbp
f6: 48 89 74 24 48          mov    QWORD PTR [rsp+0x48],rsi
fb: 48 89 7c 24 40          mov    QWORD PTR [rsp+0x40],rdi
100:    4c 89 44 24 38          mov    QWORD PTR [rsp+0x38],r8
105:    4c 89 4c 24 30          mov    QWORD PTR [rsp+0x30],r9
10a:    4c 89 54 24 28          mov    QWORD PTR [rsp+0x28],r10
10f:    4c 89 5c 24 20          mov    QWORD PTR [rsp+0x20],r11
114:    4c 89 64 24 18          mov    QWORD PTR [rsp+0x18],r12
119:    4c 89 6c 24 10          mov    QWORD PTR [rsp+0x10],r13
11e:    4c 89 74 24 08          mov    QWORD PTR [rsp+0x8],r14
123:    4c 89 3c 24             mov    QWORD PTR [rsp],r15
127:    48 be b6 16 00 66 24    movabs rsi,0x7f24660016b6
12e:    7f 00 00
131:    48 8b d4                mov    rdx,rsp
134:    48 bf 21 81 ee e0 1a    movabs rdi,0x561ae0ee8121
13b:    56 00 00
13e:    48 83 e4 f0             and    rsp,0xfffffffffffffff0
142:    48 b8 d0 cc 61 e2 1a    movabs rax,0x561ae261ccd0
149:    56 00 00
14c:    ff d0                   call   rax
14e:    f4                      hlt
14f:    ff                      .byte 0xff


**regular jdk**

0:  49 83 7f 08 00          cmp    QWORD PTR [r15+0x8],0x0
5:  0f 85 72 00 00 00       jne    0x7d
b:  48 81 ec 80 00 00 00    sub    rsp,0x80
12: 48 89 44 24 78          mov    QWORD PTR [rsp+0x78],rax
17: 48 89 4c 24 70          mov    QWORD PTR [rsp+0x70],rcx
1c: 48 89 54 24 68          mov    QWORD PTR [rsp+0x68],rdx
21: 48 89 5c 24 60          mov    QWORD PTR [rsp+0x60],rbx
26: 48 89 6c 24 50          mov    QWORD PTR [rsp+0x50],rbp
2b: 48 89 74 24 48          mov    QWORD PTR [rsp+0x48],rsi
30: 48 89 7c 24 40          mov    QWORD PTR [rsp+0x40],rdi
35: 4c 89 44 24 38          mov    QWORD PTR [rsp+0x38],r8
3a: 4c 89 4c 24 30          mov    QWORD PTR [rsp+0x30],r9
3f: 4c 89 54 24 28          mov    QWORD PTR [rsp+0x28],r10
44: 4c 89 5c 24 20          mov    QWORD PTR [rsp+0x20],r11
49: 4c 89 64 24 18          mov    QWORD PTR [rsp+0x18],r12
4e: 4c 89 6c 24 10          mov    QWORD PTR [rsp+0x10],r13
53: 4c 89 74 24 08          mov    QWORD PTR [rsp+0x8],r14
58: 4c 89 3c 24             mov    QWORD PTR [rsp],r15
5c: 48 be eb 15 00 22 6c    movabs rsi,0x7f6c220015eb
63: 7f 00 00
66: 48 8b d4                mov    rdx,rsp
69: 48 bf 0e 71 3c 3c 6c    movabs rdi,0x7f6c3c3c710e
70: 7f 00 00
73: 48 83 e4 f0             and    rsp,0xfffffffffffffff0
77: e8 44 5a 90 1b          call   0x1b905ac0
7c: f4                      hlt
7d: 48 8b 3c 24             mov    rdi,QWORD PTR [rsp]
81: 48 8b f7                mov    rsi,rdi
84: 49 8b ff                mov    rdi,r15
87: 40 f6 c4 0f             test   spl,0xf
8b: 0f 84 12 00 00 00       je     0xa3
91: 48 83 ec 08             sub    rsp,0x8
95: e8 46 46 c1 1b          call   0x1bc146e0
9a: 48 83 c4 08             add    rsp,0x8
9e: e9 05 00 00 00          jmp    0xa8
a3: e8 38 46 c1 1b          call   0x1bc146e0
a8: 48 8b d8                mov    rbx,rax
ab: 5a                      pop    rdx
ac: 49 8b 47 08             mov    rax,QWORD PTR [r15+0x8]
b0: 49 c7 47 08 00 00 00    mov    QWORD PTR [r15+0x8],0x0
b7: 00
b8: 48 85 c0                test   rax,rax
bb: 0f 85 72 00 00 00       jne    0x133
c1: 48 81 ec 80 00 00 00    sub    rsp,0x80
c8: 48 89 44 24 78          mov    QWORD PTR [rsp+0x78],rax
cd: 48 89 4c 24 70          mov    QWORD PTR [rsp+0x70],rcx
d2: 48 89 54 24 68          mov    QWORD PTR [rsp+0x68],rdx
d7: 48 89 5c 24 60          mov    QWORD PTR [rsp+0x60],rbx
dc: 48 89 6c 24 50          mov    QWORD PTR [rsp+0x50],rbp
e1: 48 89 74 24 48          mov    QWORD PTR [rsp+0x48],rsi
e6: 48 89 7c 24 40          mov    QWORD PTR [rsp+0x40],rdi
eb: 4c 89 44 24 38          mov    QWORD PTR [rsp+0x38],r8
f0: 4c 89 4c 24 30          mov    QWORD PTR [rsp+0x30],r9
f5: 4c 89 54 24 28          mov    QWORD PTR [rsp+0x28],r10
fa: 4c 89 5c 24 20          mov    QWORD PTR [rsp+0x20],r11
ff: 4c 89 64 24 18          mov    QWORD PTR [rsp+0x18],r12
104:    4c 89 6c 24 10          mov    QWORD PTR [rsp+0x10],r13
109:    4c 89 74 24 08          mov    QWORD PTR [rsp+0x8],r14
10e:    4c 89 3c 24             mov    QWORD PTR [rsp],r15
112:    48 be a1 16 00 22 6c    movabs rsi,0x7f6c220016a1
119:    7f 00 00
11c:    48 8b d4                mov    rdx,rsp
11f:    48 bf 8b da 46 3c 6c    movabs rdi,0x7f6c3c46da8b
126:    7f 00 00
129:    48 83 e4 f0             and    rsp,0xfffffffffffffff0
12d:    e8 8e 59 90 1b          call   0x1b905ac0
132:    f4                      hlt
133:    ff                      .byte 0xff

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137262447

From jiangli at openjdk.org  Wed Jul 30 17:46:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 17:46:00 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
Message-ID: <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>

On Tue, 29 Jul 2025 22:11:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.

Changed to P2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137286902

From kvn at openjdk.org  Wed Jul 30 18:21:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Jul 2025 18:21:59 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
 <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
Message-ID: <ScbtWQHtpA300xn5wKTQSN62OCK8pJgL9B8tciSohpw=.4c755164-a7b4-4227-9b76-5c92b5dd2651@github.com>

On Wed, 30 Jul 2025 17:43:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
>
>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
> 
> Changed to P2.

@jianglizhou   So it is similar to issue in AOT where we force `ForceUnreachable` flag to be `true` to generate far calls (full address is used instead of relative offset) into VM's runtime methods.  But in static JDK VM runtime methods addressed far from CodeCache so it triggers far call.

Which means normal JDK is not affected and that is why we did not see it in our testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137387749

From kvn at openjdk.org  Wed Jul 30 18:27:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Jul 2025 18:27:01 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
 <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
Message-ID: <KGH6USzGg_eW-F4ah_eQ3uBzjz8m4kLkhwNREYbramc=.ba6f50ce-d7de-4af6-80d1-c953c4b0fccd@github.com>

On Wed, 30 Jul 2025 17:43:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
>
>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
> 
> Changed to P2.

@jianglizhou thank you for showing code difference.  I approved JDK 25 backport.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137401463

From shade at openjdk.org  Wed Jul 30 18:34:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 18:34:56 GMT
Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically
In-Reply-To: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
References: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
Message-ID: <8rklhoU4HU7TGBTRXefcYR0PeA4uV5Uj-rz5iPKQTtg=.55fe7040-5531-4176-954a-f23158f0ca29@github.com>

On Wed, 30 Jul 2025 16:27:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected.
> 
> 
> Intel(R) Xeon(R) Platinum 8259CL
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {ergonomic}
> 
> 
> Even worse when it's actually false, but shows as true:
> 
> 
> AMD EPYC 7R13
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = false  {ARCH diagnostic} {ergonomic}

This looks fine to me as the solution to the UX problem.

Thinking out loud:

I don't know `VM_Version::_has_intel_jcc_erratum` field bears any reasonable weight at this point. That said, I think the guidance I heard from @vnkozlov once is that checking the flag directly instead of calling into `VM_Version` is frowned upon. This would be somewhat important in Leyden.

But maybe we should go and redefine `VM_Version::has_intel_jcc_erratum` to return the `IntelJccErratumMitigation` value as well. That would require JVMCI folks to poll the JVM flag directly instead of going via VMStructs. Also somewhat busy-work-ish. 

So I am approving this as an MVP that solves the UX problem and does not prompt any additional work.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26560#pullrequestreview-3072899137

From jiangli at openjdk.org  Wed Jul 30 19:12:59 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 19:12:59 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
 <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
Message-ID: <LdLhPNKp4tdyngVLkTua2mA7JcnNkSalgKsX73FQGcs=.95061790-ae4d-4830-93f0-90b337c77f76@github.com>

On Wed, 30 Jul 2025 17:43:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
>
>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
> 
> Changed to P2.

> @jianglizhou thank you for showing code difference. I approved JDK 25 backport.

Thanks, @vnkozlov!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137525151

From jiangli at openjdk.org  Wed Jul 30 19:16:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 19:16:00 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <LdLhPNKp4tdyngVLkTua2mA7JcnNkSalgKsX73FQGcs=.95061790-ae4d-4830-93f0-90b337c77f76@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
 <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
 <LdLhPNKp4tdyngVLkTua2mA7JcnNkSalgKsX73FQGcs=.95061790-ae4d-4830-93f0-90b337c77f76@github.com>
Message-ID: <Z9_cqfh7IzYo1t571XYNYtFXH4yQl-8vvfb0NNmNLaE=.3ff726f3-02d1-42a5-86ac-d38e1d26c080@github.com>

On Wed, 30 Jul 2025 19:09:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> Also about back porting into JDK 25. You need to rise priority - only P1 and P2 are allowed in RDP2.
>> 
>> Changed to P2.
>
>> @jianglizhou thank you for showing code difference. I approved JDK 25 backport.
> 
> Thanks, @vnkozlov!

> @jianglizhou So it is similar to issue in AOT where we force `ForceUnreachable` flag to be `true` to generate far calls (full address is used instead of relative offset) into VM's runtime methods. But in static JDK VM runtime methods addressed far from CodeCache so it triggers far call.

Yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137533537

From coleenp at openjdk.org  Wed Jul 30 19:25:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 19:25:34 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Restore c2 optimization.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/45b92c5c..fb6c15e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From jiangli at openjdk.org  Wed Jul 30 19:33:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 19:33:08 GMT
Subject: [jdk25] RFR: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
Message-ID: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>

Hi all,

This pull request contains a backport of commit [c239c0ab](https://github.com/openjdk/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jiangli Zhou on 29 Jul 2025 and was reviewed by Chuck Rasbold.

Thanks!

-------------

Commit messages:
 - Backport c239c0ab00196da8c7c5f6099c8189a778874588

Changes: https://git.openjdk.org/jdk/pull/26565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362564
  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26565/head:pull/26565

PR: https://git.openjdk.org/jdk/pull/26565

From jiangli at openjdk.org  Wed Jul 30 19:33:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 19:33:08 GMT
Subject: [jdk25] RFR: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
In-Reply-To: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
References: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
Message-ID: <plnOOLs__hsflvIAWgKfLgKp3sb5Y0lFHjRwqlncSak=.17a864c2-f111-43ec-9670-c9facfcfc840@github.com>

On Wed, 30 Jul 2025 19:27:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c239c0ab](https://github.com/openjdk/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jiangli Zhou on 29 Jul 2025 and was reviewed by Chuck Rasbold.
> 
> Thanks!

> Hi all,
> 
> This pull request contains a backport of commit [c239c0ab](https://github.com/openjdk/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26565#issuecomment-3137572609

From rriggs at openjdk.org  Wed Jul 30 20:27:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 20:27:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
Message-ID: <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>

On Tue, 29 Jul 2025 19:42:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.
>
> For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.

The VM and Java use the same logic for the value of isIdentity(). 
It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2243785633

From kvn at openjdk.org  Wed Jul 30 21:53:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Jul 2025 21:53:01 GMT
Subject: RFR: 8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java
 fails on static JDK on x86_64 with AVX instruction extensions [v2]
In-Reply-To: <ScbtWQHtpA300xn5wKTQSN62OCK8pJgL9B8tciSohpw=.4c755164-a7b4-4227-9b76-5c92b5dd2651@github.com>
References: <OnnwgvXf70mYX_xDXiHiw4GBA0tl9bB-3BkTi2GXd5I=.e7b74bbc-47ab-443c-ab3c-0e5bff73576c@github.com>
 <Adr5jhplxxBiZI-vr4q5YzcCAZag1Mjc5NHwzmm-Y1Y=.01de97f0-8dd6-4ee3-aedb-acfcc9e40a63@github.com>
 <pEm-aGbf5m5L7My_1LCmAiFkWFSUbS6n0qJT5UdKfJA=.6565cfd0-d4f1-4c56-9f92-92f451648609@github.com>
 <IVutiAHXaQFQ0FOs1IHCNZVWWmb3_ZGpCxxmTWDkiBk=.8a68e234-e978-4a79-a562-09e52201f43c@github.com>
 <ScbtWQHtpA300xn5wKTQSN62OCK8pJgL9B8tciSohpw=.4c755164-a7b4-4227-9b76-5c92b5dd2651@github.com>
Message-ID: <vu4rNBZp10_OYYebj5Li7z1t7K20fCSS9fLjmCpC0t8=.7f82c308-da56-40ba-866a-0f2a8d1ddd09@github.com>

On Wed, 30 Jul 2025 18:19:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Which means normal JDK is not affected and that is why we did not see it in our testing.

I want to correct my statement. Normal JDK could be also affected as I pointed in JBS report in my approval comment.
We can't guarantee that CodeCache address space will be near VM's runtime code address space in all cases to use relative distance in calls and jumps.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26395#issuecomment-3137920990

From kvn at openjdk.org  Wed Jul 30 21:55:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Jul 2025 21:55:55 GMT
Subject: [jdk25] RFR: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
In-Reply-To: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
References: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
Message-ID: <BrdpGQmvJo02C-cp6XHt7osov_HqVBqaQD5lBOnOJYs=.f61c1a3e-0e9f-43f8-9c31-7e18c1b03de6@github.com>

On Wed, 30 Jul 2025 19:27:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c239c0ab](https://github.com/openjdk/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jiangli Zhou on 29 Jul 2025 and was reviewed by Chuck Rasbold.
> 
> Thanks!

Good.

Please wait for GHA testing finished before integration.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26565#pullrequestreview-3073433470

From egahlin at openjdk.org  Wed Jul 30 22:00:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 30 Jul 2025 22:00:00 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
Message-ID: <Y68Yi8w_oLj1i2vrOF_uns1F_3MsucfNdXi98KrzNgI=.9b45a313-c2a8-44e4-b3f8-741c1b8339de@github.com>

On Wed, 30 Jul 2025 08:37:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor TestEmergencyDumpAtOOM.java

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3073440975

From duke at openjdk.org  Wed Jul 30 22:41:12 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Jul 2025 22:41:12 GMT
Subject: Withdrawn: 8356548: Avoid using ASM to parse latest class files 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: <cXOFmEOpGxymUoRrFEcMG4A69uJoYJvNyPCj480pUh0=.d83c9127-7fde-4547-b613-144cd3325daf@github.com>

On Thu, 8 May 2025 14:57:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25124

From jiangli at openjdk.org  Wed Jul 30 23:21:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 23:21:57 GMT
Subject: [jdk25] RFR: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
In-Reply-To: <BrdpGQmvJo02C-cp6XHt7osov_HqVBqaQD5lBOnOJYs=.f61c1a3e-0e9f-43f8-9c31-7e18c1b03de6@github.com>
References: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
 <BrdpGQmvJo02C-cp6XHt7osov_HqVBqaQD5lBOnOJYs=.f61c1a3e-0e9f-43f8-9c31-7e18c1b03de6@github.com>
Message-ID: <rZuAPPbBZ2YiHffHR74avtlJiSacbGMcPUj4LU__vt4=.7ff431a9-7562-4788-8383-6db4f080deb5@github.com>

On Wed, 30 Jul 2025 21:52:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thanks!

> 
> Please wait for GHA testing finished before integration.

https://github.com/openjdk-bots/jdk/actions/runs/16631779018/job/47062825109 done.

The [linux-cross-compile / build (s390x)](https://github.com/openjdk-bots/jdk/actions/runs/16631779018/job/47062825096#logs) and [linux-cross-compile / build (ppc64le)](https://github.com/openjdk-bots/jdk/actions/runs/16631779018/job/47062825109#logs) failures look unrelated:


E: Couldn't download https://httpredir.debian.org/debian/dists/bullseye/main/binary-ppc64el/Packages


Those also failed in earlier commits, e.g. https://github.com/openjdk/jdk/pull/26543/checks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26565#issuecomment-3138086876

From jiangli at openjdk.org  Wed Jul 30 23:21:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 30 Jul 2025 23:21:57 GMT
Subject: [jdk25] Integrated: 8362564:
 hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on
 x86_64 with AVX instruction extensions
In-Reply-To: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
References: <UREU7acUMyL2c7cw-dRKAhVxTl8QlmIFM-vsCYsabHA=.96b99a24-56d9-411b-b36b-8fb43e1c66bc@github.com>
Message-ID: <XLFHbnHU06e6KzO50vaHDYNauk6MA_nPE6WmWhfA2tg=.a5eb7722-58a1-4a9c-9084-6b0fa7b62490@github.com>

On Wed, 30 Jul 2025 19:27:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c239c0ab](https://github.com/openjdk/jdk/commit/c239c0ab00196da8c7c5f6099c8189a778874588) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jiangli Zhou on 29 Jul 2025 and was reviewed by Chuck Rasbold.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 7b696791
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b6967917545d1d1b16a4927f9231d085cfbad1e
Stats:     5 lines in 2 files changed: 3 ins; 0 del; 2 mod

8362564: hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java fails on static JDK on x86_64 with AVX instruction extensions

Reviewed-by: kvn
Backport-of: c239c0ab00196da8c7c5f6099c8189a778874588

-------------

PR: https://git.openjdk.org/jdk/pull/26565

From sviswanathan at openjdk.org  Wed Jul 30 23:51:54 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 30 Jul 2025 23:51:54 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
Message-ID: <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>

On Thu, 17 Jul 2025 18:46:06 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move error bound to separate section in comment header

src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp line 325:

> 323:   __ jcc(Assembler::aboveEqual, L_2TAG_PACKET_0_0_2); // Branch only if |x| is not in [23/64, 3*2^8)
> 324:   __ movsd(xmm3, ExternalAddress(HALFMASK), r11 /*rscratch*/);
> 325:   __ movsd(xmm1, ExternalAddress(L2E), r11 /*rscratch*/);

xmm1 is used at L_2TAG_PACKET_0_0_2 -> L_2TAG_PACKET_3_0_2 line 507 below so should be loaded prior to L_2TAG_PACKET_0_0_2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26152#discussion_r2243550202

From dlong at openjdk.org  Thu Jul 31 03:34:55 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Jul 2025 03:34:55 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <_gJoTNnBpV2Y2ENO9s153NWZeq_ujs40-zoyuZstOqM=.69d1d039-5022-4beb-ae79-7fc4193f3a11@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
 <_gJoTNnBpV2Y2ENO9s153NWZeq_ujs40-zoyuZstOqM=.69d1d039-5022-4beb-ae79-7fc4193f3a11@github.com>
Message-ID: <PnwRO1fjkfcgUUVHl0LktI8eCwkIV79mC_BsAxNZCTs=.dcf7c990-9f3d-413c-b55f-64a6642d3b76@github.com>

On Mon, 28 Jul 2025 08:33:50 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   readability suggestion
>
> Thank you for addressing my comments. I have done another pass and it looks good to me.

Thank you, @mhaessig , for looking at this complicated code!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26121#issuecomment-3138444068

From jbhateja at openjdk.org  Thu Jul 31 04:52:54 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Jul 2025 04:52:54 GMT
Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically
In-Reply-To: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
References: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
Message-ID: <_7jWpDMMZR9acVRgES9Xr9WuUv4ZMQl-or-3pQV8dck=.4166180d-77c1-4ebd-88aa-d28dae11135b@github.com>

On Wed, 30 Jul 2025 16:27:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected.
> 
> 
> Intel(R) Xeon(R) Platinum 8259CL
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {ergonomic}
> 
> 
> Even worse when it's actually false, but shows as true:
> 
> 
> AMD EPYC 7R13
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = false  {ARCH diagnostic} {ergonomic}

Marked as reviewed by jbhateja (Reviewer).

Hi @olivergillespie , This change looks good to me, what about other flags in vm_version_x86.cpp
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L1198

JVM flag which is enabled through feature detection should have ERGONOMIC origin.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26560#pullrequestreview-3073968444
PR Comment: https://git.openjdk.org/jdk/pull/26560#issuecomment-3138552328

From stuefe at openjdk.org  Thu Jul 31 05:15:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 05:15:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <KnQk7cUAdVkf-DF_Esm9IIeHCCmAe5cpmRkQu7SSyfY=.59e8bfac-0d10-4dc0-8aa1-7a16103f40b5@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 

This makes sense and can also be read in conjunction with os::reserve_memory and os::commit_memory. As in 

// reserve_memory_limit() returns an upper limit beyond which os::reserve_memory
// calls are guaranteed to fail. It is not guaranteed reserving smaller sizes will succeed,
// however.

, and vice versa for commit_memory_limit.

> > to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3138583960

From stuefe at openjdk.org  Thu Jul 31 05:25:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 05:25:55 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
Message-ID: <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>

On Wed, 30 Jul 2025 09:35:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os:: unification in allocatable_memory_limit

src/hotspot/os/posix/os_posix.cpp line 716:

> 714: 
> 715: #ifndef _LP64
> 716: // Helper, on 32bit, for os::allocatable_memory_limit

Pre-existing: paying for mmap only to later pay for the same mmap again seems overly costly, seeing that there is no guarantee anyway that the later mmap will also succeed.

src/hotspot/os/posix/os_posix.cpp line 813:

> 811: 
> 812:   // No limit
> 813:   return SIZE_MAX;

This would be a very nice place to hook in the function I proposed you add, the sister function to `os::vm_min_address()`, let's call it `os::vm_max_address()`.

Looking through the ZGC sources, this is the functionality I meant: https://github.com/openjdk/jdk/blob/559795b0eb8061325127fa9fdf8b80617fe47166/src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp#L45

For platforms that don't have that implementation, you can still return SIZE_MAX as fallback.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244378549
PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244374030

From shade at openjdk.org  Thu Jul 31 06:10:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 06:10:00 GMT
Subject: RFR: 8364111: InstanceMirrorKlass iterators should handle CDS and
 hidden classes consistently [v3]
In-Reply-To: <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
 <QXLfSAIjpUj1udGmH-ZTl_CdapbGmkMmrfYFkB593OQ=.2e61a459-2ffc-46b2-ab4c-a3b788afcc48@github.com>
Message-ID: <a6DXu3Tol4XoXiqxGmC_4HroCvAYCYrCFf8Y1sXQB2w=.91e29e9a-7871-460d-aa94-a19d9baae04e@github.com>

On Mon, 28 Jul 2025 10:51:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
>> 
>> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>>  - [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:
> 
>   Better comment

Thanks! If there are no more comments, I will integrate this soon.

There we go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26477#issuecomment-3135750694
PR Comment: https://git.openjdk.org/jdk/pull/26477#issuecomment-3138667068

From shade at openjdk.org  Thu Jul 31 06:10:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 06:10:01 GMT
Subject: Integrated: 8364111: InstanceMirrorKlass iterators should handle CDS
 and hidden classes consistently
In-Reply-To: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
References: <VrAdaLLdziToAYoNZuVN6smi9blhaxX-VBuDlTPRLKw=.247ce431-952e-47cc-9b57-ac21334ec7a8@github.com>
Message-ID: <GBoHHiFKEYtkq_UWlY4BIxyjp42s8Lc6vvBFmybRCZA=.f0cbcd58-053d-485a-a03f-57b0bb388238@github.com>

On Fri, 25 Jul 2025 12:01:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more investigation. I think the root cause is already fixed in one of the `InstanceMirrorKlass` iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting `is_primitive`, which is not relevant anymore.
> 
> So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: ebb7f5d3
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ebb7f5d39be8497fc89e25d0905335102e12c063
Stats:     64 lines in 2 files changed: 32 ins; 30 del; 2 mod

8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently

Reviewed-by: stuefe, ayang, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/26477

From stuefe at openjdk.org  Thu Jul 31 07:02:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 07:02:10 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5]
In-Reply-To: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
Message-ID: <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>

> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
> 
> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
> 
> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
> 
> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
> 
> -------
> 
> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
> 
> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
> 
> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
> 
> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happens - we need to revise this design...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Fix some jtreg tests on arm
 - fix arm gtests
 - fix CompressedKlass* gtests on arm
 - Merge master
 - get rid of NEEDS_CLASS_SPACE define
 - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
 - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
 - since to because
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Remove stray include
 - Update src/hotspot/share/oops/compressedKlass.cpp
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f

-------------

Changes: https://git.openjdk.org/jdk/pull/26491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26491&range=04
  Stats: 196 lines in 17 files changed: 123 ins; 45 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/26491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26491/head:pull/26491

PR: https://git.openjdk.org/jdk/pull/26491

From stuefe at openjdk.org  Thu Jul 31 07:04:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 07:04:54 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <0yYP0GJXQUrRpJmD5R3tCdvF1IjOgDQnTFzUR-yer8g=.f005ff56-2ce8-4c2e-92f8-c707f19aef1a@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <FvX4eskxRda_aIyG_daiB8VcPzVD8zNFd7Xp8FHyRRk=.f2ee0203-3a8b-4754-a8c8-d1171746cbb4@github.com>
 <vVlqjqQwo8uNAVPSmsVzi6cn-QNhIYcVrByXnuHt2Xs=.bd8be576-98cd-47d8-a7ee-f1b44e3af22c@github.com>
 <0yYP0GJXQUrRpJmD5R3tCdvF1IjOgDQnTFzUR-yer8g=.f005ff56-2ce8-4c2e-92f8-c707f19aef1a@github.com>
Message-ID: <YayXTKoF9gLDcsKrqHyB5eYZVFQzVD4faRsSNha0Cm4=.87f5b3ea-7e33-4d9a-8e2b-521784a455bd@github.com>

On Mon, 28 Jul 2025 15:18:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Possibly; but I wanted to keep the change to a minimum. There will be a larger cleanup coming when UseCompressedClassPointers gets removed.
>
> ok

On closer inspection, this is still used in arm C1. I would like to keep the changes minimal, so I'll just keep it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2244526788

From stuefe at openjdk.org  Thu Jul 31 07:08:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 07:08:59 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v3]
In-Reply-To: <WhtQodL_eDBYb0dhN_7SXy-bQjcCVGiHgGjh2CNzxTU=.e4acb00c-ba71-4989-8c9d-1c8b0d08ba6b@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <I95Gr8jzq03KlnM8gEMSS49FDRZnh7Ars40OgwhXO_g=.4c4e4c95-5bc5-4bd8-81d9-5fc46cf9ccaf@github.com>
 <WhtQodL_eDBYb0dhN_7SXy-bQjcCVGiHgGjh2CNzxTU=.e4acb00c-ba71-4989-8c9d-1c8b0d08ba6b@github.com>
Message-ID: <BS5vK7p--NJSEh9ahS_la8Qque-TZ-iuyeQa3px2TsU=.0cd8315a-a1c7-4d69-9820-d976b3a2fe0c@github.com>

On Mon, 28 Jul 2025 20:39:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray include
>
> src/hotspot/share/oops/compressedKlass.cpp line 67:
> 
>> 65:     _max_shift = max_shift_coh;
>> 66:   } else {
>> 67: #ifdef _LP64
> 
> It's a bit confusing when we need NEEDS_CLASS_SPACE vs. LP64.  Like here.

@coleenp I modified the patch, removed the NEEDS_CLASS_SPACE macro, since most of the sections can be compiled just fine on arm. There is the basic question of whether one wants to exclude anything related to 32-bit on 64-bit from builds or not. If one does, 32-bit will bitrot even easier, if not (this seems e.g. the strategy Ioi is following in most of his CDS code) one sees errors in 32-bit more easily and reduces ifdef sections. I opted for the latter here, but it won't make much difference in practice I assume.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2244534430

From duke at openjdk.org  Thu Jul 31 07:31:41 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 07:31:41 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v19]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <uj_6NcHndxj7qjS_ejwlzQZG4SBbWcfLWImQAFDYmNs=.d3b7b6cf-c777-4ec8-ba1e-2f67f59da5ee@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Addressed reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/c994991b..fa09ae33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=17-18

  Stats: 8 lines in 3 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From duke at openjdk.org  Thu Jul 31 07:31:42 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 07:31:42 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
 <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
Message-ID: <7UUjImTCn7ngfH7K8BWX2NhHZay7ISp2pnyuxNZTAmE=.db5ba59e-1eb8-4e15-bf41-65500ef62b7b@github.com>

On Wed, 30 Jul 2025 15:35:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357086: Fixed void conversion.
>
> src/hotspot/share/gc/shared/gcInitLogger.cpp line 70:
> 
>> 68:   } else {
>> 69:     log_info_p(gc, init)("Memory: NA");
>> 70:   }
> 
> Suggestion:
> 
>   size_t memory = 0;
>   if (os::physical_memory(memory)) {
>     log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
>   } else {
>     log_info_p(gc, init)("Memory: NA");
>   }

Addressed.

> src/hotspot/share/gc/z/zLargePages.cpp line 38:
> 
>> 36:   } else {
>> 37:     log_info_p(gc, init)("Memory: NA");
>> 38:   }
> 
> Restore removed blank line and renamed abbreviated double-word local. I'm a bit extra picky with the code in ZGC (and GC):
> Suggestion:
> 
> 
>   size_t memory = 0;
>   if (os::physical_memory(memory)) {
>     log_info_p(gc, init)("Memory: %zu%s", byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
>   } else {
>     log_info_p(gc, init)("Memory: NA");
>   }

Addressed.

> src/hotspot/share/runtime/arguments.cpp line 1510:
> 
>> 1508: void Arguments::set_heap_size() {
>> 1509:   julong phys_mem;
>> 1510:   size_t physical_mem_val = 0;
> 
> Restore blankline:
> Suggestion:
> 
>   size_t physical_mem_val = 0;

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244579031
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244579242
PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244579360

From jsikstro at openjdk.org  Thu Jul 31 07:59:54 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:59:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <NPVEHV187N9m7VWN_WLel1WOkR6LG74sF80DfjB3AHo=.6f649349-5c74-47fa-971c-b6ee626a2083@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > Just want to start of by saying thank you for taking the time with this.
>>> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
>>> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
>>> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
>>> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
>>> > 
>>> > 
>>> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
>>> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
>>> 
>>> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.
>> 
>> I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.
>> 
>> I'm open to changing os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?
>
>> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 
>> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

I agree with you both, @albertnetymk and @tstuefe, that `commit_memory_limit` and `reserve_memory_limit` are good names and convey the intention of the functions better.

> ```
> // reserve_memory_limit() returns an upper limit beyond which os::reserve_memory
> // calls are guaranteed to fail. It is not guaranteed reserving smaller sizes will succeed,
> // however.
> ```
> 
> , and vice versa for commit_memory_limit.

I also like having this kind of comment above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3138930686

From jsikstro at openjdk.org  Thu Jul 31 07:59:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 07:59:56 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
 <3StjC1fow5AMsbKvz19itL9G7idYQPBZGLWUSHINxUM=.26770ae0-dfeb-42f5-b21c-aa01b8fa306d@github.com>
Message-ID: <_m8GN1u4lb2th8DjdKagQbY_ocMsB0mEZxMjtT7C_aw=.1fce584f-b3b7-410b-bda6-9230a2221451@github.com>

On Thu, 31 Jul 2025 05:19:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   os:: unification in allocatable_memory_limit
>
> src/hotspot/os/posix/os_posix.cpp line 813:
> 
>> 811: 
>> 812:   // No limit
>> 813:   return SIZE_MAX;
> 
> This would be a very nice place to hook in the function I proposed you add, the sister function to `os::vm_min_address()`, let's call it `os::vm_max_address()`.
> 
> Looking through the ZGC sources, this is the functionality I meant: https://github.com/openjdk/jdk/blob/559795b0eb8061325127fa9fdf8b80617fe47166/src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp#L45
> 
> For platforms that don't have that implementation, you can still return SIZE_MAX as fallback.

Yes, this could be nice to have in the future, and would likely be a larger re-write.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244642891

From ayang at openjdk.org  Thu Jul 31 08:05:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 08:05:55 GMT
Subject: RFR: 8364169: (NMT) Move nativeCallStack to nmt
In-Reply-To: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
References: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
Message-ID: <VXb0dbnYduiD_SvEHhNOAObEXvesHjCaQ24ZEdvGEbU=.b47ee747-2406-422a-9d35-811b932c9689@github.com>

On Mon, 28 Jul 2025 08:37:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial file move of NativeCallStack to the `nmt` sub directory.

I feel the name `NativeCallStack` is general enough so it might not be necessarily related to NMT.

Also looked a bit inside `NativeCallStack`, but it's unclear to me why the stack-depth is nmt-constant. Why can't a user of `NativeCallStack` (e.g. `CompilationFailureInfo` ) specify the desired stack-depth? Is there an invariant that stack-depth must be a global-constant?

src/hotspot/share/jfr/utilities/jfrAllocation.cpp line 30:

> 28: #include "memory/allocation.inline.hpp"
> 29: #include "nmt/memTracker.hpp"
> 30: #include "nmt/nativeCallStack.hpp"

I can't find out why this include is actually used inside this file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26498#pullrequestreview-3074358490
PR Review Comment: https://git.openjdk.org/jdk/pull/26498#discussion_r2244636520

From stuefe at openjdk.org  Thu Jul 31 08:06:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 08:06:00 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
 <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
Message-ID: <24xIFc0iPvkbR2lM-x92rIDage4gZ2_VZVu036XKc1o=.d554b735-d60a-4723-a5ac-85c431d0db5e@github.com>

On Wed, 30 Jul 2025 16:06:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> With that said, when looking at this I'm wondering if there is any scenario where we can hit an error when calling the os::physical_memory? I understand that the OS APIs says that we can hit an error, but I wonder if that's only a theoretical issue? If it turns out that the APIs in effect never will fail then we can verify that they succeed during the JVM initialization and then remove the error code from os os::physical_memory() and let it only return a size_t instead. If we do this we can clean away a lot of the error handling code that is added in this PR.

I absolutely agree. Keep it simple and stupid.

> 
> The places that I see that could theoretically fail is:
> 
>     1. On AIX, but there's an `assert(0` in there to show that this really doesn't happen.
> 
>     2. On Windows if GlobalMemoryStatusEx(&ms) fails. The question is will this call fail for any reason on Windows? Maybe someone from Microsoft could help and tell if there ever is a reason why this code would fail:
> 
> 
> ```
>   MEMORYSTATUSEX ms;
>   ms.dwLength = sizeof(ms);
>   GlobalMemoryStatusEx(&ms);
> ```

I don't think this can even have failed, we would have noticed:

- we use `GlobalMemoryStatusEx` to calculate `MaxRAM` (without error checking)
- on debug builds, this would return something like "0xcccccccc_cccccccc" on error as size, since that's the default initialization. That's a lot of RAM :-)
- we then base our default heap size on that. Reserving that much space for heap would have failed at at least some tests.

In product builds, the result would be random garbage; either 0, which would have failed, too, or some random number with a high probability of being very high, since random garbage that just looks like a small 64-bit number is not that great. So we would have seen at least some errors on Windows in release builds, too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244655963

From stuefe at openjdk.org  Thu Jul 31 08:18:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 08:18:00 GMT
Subject: Withdrawn: 8364169: (NMT) Move nativeCallStack to nmt
In-Reply-To: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
References: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
Message-ID: <p9DWSiXCadaw4hNTGNgqfxEigoh2-Q3kYvz1oS1FRcs=.0bced8fd-78e2-4e86-85ac-8784c2e26373@github.com>

On Mon, 28 Jul 2025 08:37:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial file move of NativeCallStack to the `nmt` sub directory.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26498

From stuefe at openjdk.org  Thu Jul 31 08:18:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 08:18:00 GMT
Subject: RFR: 8364169: (NMT) Move nativeCallStack to nmt
In-Reply-To: <VXb0dbnYduiD_SvEHhNOAObEXvesHjCaQ24ZEdvGEbU=.b47ee747-2406-422a-9d35-811b932c9689@github.com>
References: <5km9qM1KJNseQSWpH2sOmva5sJ0uNL2ZIiztGKRCjeg=.341320ff-e314-4100-a0ff-3e0b44edd7d8@github.com>
 <VXb0dbnYduiD_SvEHhNOAObEXvesHjCaQ24ZEdvGEbU=.b47ee747-2406-422a-9d35-811b932c9689@github.com>
Message-ID: <iwjhMTDtI0-Qc37bkLvmkIgnCq3k2pu5M6PcYqlg0O8=.bb850013-acc8-4adb-bfb8-6ca3c5857ff6@github.com>

On Thu, 31 Jul 2025 08:03:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I feel the name `NativeCallStack` is general enough so it might not be necessarily related to NMT.
> 

Okay, I will withdraw this change. It was always very tightly interwoven with NMT. Maybe decoupling that is the better option.

> Also looked a bit inside `NativeCallStack`, but it's unclear to me why the stack-depth is nmt-constant. Why can't a user of `NativeCallStack` (e.g. `CompilationFailureInfo` ) specify the desired stack-depth? Is there an invariant that stack-depth must be a global-constant?

No, apart from its just not done this way (frames are inlined). 
I plan to address this shortly (https://bugs.openjdk.org/browse/JDK-8318174) . In fact, this PR was supposed to be the preparation for that change, but I can do things differently than I had planned originally.

Closing this after reconsideration and after @albertnetymk feedback

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26498#issuecomment-3138984563
PR Comment: https://git.openjdk.org/jdk/pull/26498#issuecomment-3138986019

From jsikstro at openjdk.org  Thu Jul 31 08:48:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 08:48:58 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v5]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <YDT44eNYQpy5nlfqiBXwv7oiYngFcfm_VQ_rFODiXko=.dea3911f-a286-49b9-8ee4-3b397b28588e@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:

 - Some reordering and comments
 - Rename allocatable_memory_limit to commit_memory_limit
 - Rename address_space_limit to reserve_memory_limit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/9b9d9f7a..47150621

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=03-04

  Stats: 42 lines in 5 files changed: 21 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From jsikstro at openjdk.org  Thu Jul 31 08:48:59 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 08:48:59 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v4]
In-Reply-To: <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <AkPfB6uxS_EYRLoZFD_NOvpj0ZilTTQbDvZOecarL90=.504509fa-af95-400e-aea2-cef1fb7b93e4@github.com>
Message-ID: <yjMczd4u1-wve9YLqSiSuTRLEYCiB6r5szeLYUC1CGE=.f97063a1-2432-4499-99e0-f13213ee5111@github.com>

On Wed, 30 Jul 2025 09:35:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   os:: unification in allocatable_memory_limit

Pushed three new commits where I rename `address_space_limit` to `reserve_memory_limit`, rename `allocatable_memory_limit` to `commit_memory_limit`, and reordered the header along with adding some describing comments for both functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3139074698

From ogillespie at openjdk.org  Thu Jul 31 08:58:02 2025
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 31 Jul 2025 08:58:02 GMT
Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically
In-Reply-To: <_7jWpDMMZR9acVRgES9Xr9WuUv4ZMQl-or-3pQV8dck=.4166180d-77c1-4ebd-88aa-d28dae11135b@github.com>
References: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
 <_7jWpDMMZR9acVRgES9Xr9WuUv4ZMQl-or-3pQV8dck=.4166180d-77c1-4ebd-88aa-d28dae11135b@github.com>
Message-ID: <4c1DuAAZCbKIUE5abQBMaZLavv2DflzfnV2iiHjgIXQ=.d00a591b-3d90-4fb7-b8fc-f043801a4033@github.com>

On Thu, 31 Jul 2025 04:50:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi @olivergillespie , This change looks good to me, what about other flags in vm_version_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L1198
> 
> JVM flag which is enabled through feature detection should have ERGONOMIC origin.

Thanks, good point, there are many more cases there. Looks like this is the only one where the actual value is out of sync with the flag, though, which is the most egregious part. The others all use FLAG_SET_DEFAULT or equivalent, so it's just the source of the updated value which is wrong. It actually seems like that's a pattern across the codebase - [this one](https://github.com/openjdk/jdk/blob/b9f7caed775e86e71f7d37789cb196fb1444ef12/src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp#L38-L39) literally points out that it's an ergonomic setting while using FLAG_SET_DEFAULT.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26560#issuecomment-3139106672

From duke at openjdk.org  Thu Jul 31 08:59:58 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 08:59:58 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <cuR4GXKpL45Akw2pFcIHxGEikHBXZvwAKWOhN2E49II=.773f3f92-0eb9-4386-9947-059c49a80bb5@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>
 <cuR4GXKpL45Akw2pFcIHxGEikHBXZvwAKWOhN2E49II=.773f3f92-0eb9-4386-9947-059c49a80bb5@github.com>
Message-ID: <PVZiZsWMZIl6h6n9bRAZ64aajlWPN6y4B_d-BGJQlMc=.665123e0-c2a8-4688-be8b-790ac69c0982@github.com>

On Wed, 30 Jul 2025 15:03:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I think we have discussed it above. In `os::free_swap_space(size_t& value)` implementation in `os_linux.cpp` the value returned by `OSContainer::memory_and_swap_limit_in_bytes()` is kept in a signed variable of `jlong` type. Then, if that value is negative, `host_free_swap_val` value will be returned, as that one is non-negative.
>
> My comment above is for the `total_swap_space` function and not the `free_swap_space` function.

Right, I looked at another place, sorry.

In `total_swap_space` one wants to compute the total swap space out of two values, memory_limit and swap_limit, by the following formula: 

total_swap_space = (memory_limit  + swap_limit) - memory_limit

the 1st summand (in braces) is returned by  `OSContainer::memory_and_swap_limit_in_bytes()`, the 2nd by `OSContainer::memory_limit_in_bytes()`. The problem is that `swap_limit` can be unbounded (represented by -1 in the container code). So we end up in returning `static_cast<size_t>(-1)`, which would be 2^64-1 on 64bit platform and is the same as `std::numeric_limits<size_t>::max()`.

In my opinion, it is a good representation of the _unbounded_ value.

There are only 2 places where `os::total_swap_space()` is used, both in JFR-related code. In both cases, the `size_t` values obtained from `os::total_swap_space()` is converted to a signed 64bit value (either jlong or s8, which is the same) with `static_cast`. If `size_t` has the same bitness as `jlong`, then one will get back -1 after conversion, so nothing is changed from the JFR perspective. However, if `size_t` is 32bit, then such conversion will not return -1, but instead a positive value of 2^32-1. It has to be addressed separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244782230

From stefank at openjdk.org  Thu Jul 31 09:46:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 31 Jul 2025 09:46:02 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <PVZiZsWMZIl6h6n9bRAZ64aajlWPN6y4B_d-BGJQlMc=.665123e0-c2a8-4688-be8b-790ac69c0982@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>
 <cuR4GXKpL45Akw2pFcIHxGEikHBXZvwAKWOhN2E49II=.773f3f92-0eb9-4386-9947-059c49a80bb5@github.com>
 <PVZiZsWMZIl6h6n9bRAZ64aajlWPN6y4B_d-BGJQlMc=.665123e0-c2a8-4688-be8b-790ac69c0982@github.com>
Message-ID: <3ZUAaIkIDWUZ_vPtsvyJ7Yi0R9slhRVjIBALgRdE9DU=.79b82f4d-7537-4f2b-9311-af4f23914a87@github.com>

On Thu, 31 Jul 2025 08:56:48 GMT, Anton Artemov <duke at openjdk.org> wrote:

> the 1st summand (in braces) is returned by `OSContainer::memory_and_swap_limit_in_bytes()`, the 2nd by `OSContainer::memory_limit_in_bytes()`. The problem is that `swap_limit` can be unbounded (represented by -1 in the container code). So we end up in returning `static_cast<size_t>(-1)`, which would be 2^64-1 on 64bit platform and is the same as `std::numeric_limits<size_t>::max()`.
> 
> In my opinion, it is a good representation of the _unbounded_ value.

The error code -1 happens to be interpretable as a large number if it is converted to a unsigned value, and one can argue that this large number is an OK value to represent an unbound value. Personally, I think that is more accidental than the intended behavior of this code. This is an obscure detail in the code, and given that it isn't immediately obvious for the reader it also makes it a risk that people will not understand this if they make future changes to the code.

And even we accept that -1 can be used as the unbound value, then I think it is wrong to use the unbound value in this code. If the container says that the swap space is unbound can't the underlying host still return a sensible value in si.totalswap? If this is the case, then an error in the container code will cause os::total_swap_space to return a way higher swap value than what the host is configured to have. 

With all this said, I think the above code should check if memory_and_swap_limit_in_bytes returns -1, just like we do in os::free_swap_space().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2244885615

From stuefe at openjdk.org  Thu Jul 31 10:15:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 10:15:57 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5]
In-Reply-To: <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>
Message-ID: <YKKNKmASOmogpcXu6X2zom8byre5YjGj8gPcL_tFsJY=.08912c7b-a3df-43bf-870f-ad78b8a9cab0@github.com>

On Thu, 31 Jul 2025 07:02:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Fix some jtreg tests on arm
>  - fix arm gtests
>  - fix CompressedKlass* gtests on arm
>  - Merge master
>  - get rid of NEEDS_CLASS_SPACE define
>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>  - since to because
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Remove stray include
>  - Update src/hotspot/share/oops/compressedKlass.cpp
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f

I simplified some things (got rid of the NEEDS_CLASSSPACE define), removed some build fixes that were unnecessary after the fix for https://bugs.openjdk.org/browse/JDK-8364202, and did some minor tests on arm fixes.

I believe this is now in a good state. @coleenp @rkennke if you have time, could you approve a final time?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26491#issuecomment-3139342144

From jsikstro at openjdk.org  Thu Jul 31 10:20:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 10:20:52 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
Message-ID: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>

> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
> 
> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
> 
> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
> 
> Testing:
> * Oracle's tier1-2
> * Manual testing on Linux by limiting the virtual address space:
> 
> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  commit_memory_limit return size_t instead of bool + out-parameter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26530/files
  - new: https://git.openjdk.org/jdk/pull/26530/files/47150621..35d9b9d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26530&range=04-05

  Stats: 42 lines in 4 files changed: 0 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/26530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26530/head:pull/26530

PR: https://git.openjdk.org/jdk/pull/26530

From jsikstro at openjdk.org  Thu Jul 31 10:20:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 31 Jul 2025 10:20:53 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v3]
In-Reply-To: <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <NvlxoPI_X57Sr0SEzFELjTxdlAQcZm8Fyl5EbAjNumI=.6049ed3c-810e-4532-915d-b47248dc54a2@github.com>
 <uV4cUJbksqYdgxxfl0wF4UYGmbPq7GNSkBvFvQyB8bQ=.2fe81e1d-d14e-4c56-9bca-912c1ccdebbc@github.com>
 <nb0XKmouMn9YntNgpyH1YWgowNANG2uCs-kFMVrzdJ8=.22721875-45fe-4c77-b1a2-e06ca1125bb8@github.com>
 <lv8WZhX6icxqETkoJrc-lf28YRrfNAxNCBVfGsUIW_o=.4f26cdc6-d732-4a30-a18e-3814ba15793a@github.com>
 <QwSXEBhtLXbnMvwX5uOWVsMl8TvXtxPm1AV1jnvj0h8=.7c602f6a-c0f3-49fd-9b41-31c969938bce@github.com>
Message-ID: <5Pj1nLLArLZFC2-CPyegguoX_vyM-GgQapvxBU5ACds=.7110da98-3a29-44df-b8fe-b9962ef1307c@github.com>

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > Just want to start of by saying thank you for taking the time with this.
>>> > > I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
>>> > > "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
>>> > > For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
>>> > > I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.
>>> > 
>>> > 
>>> > I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.
>>> > On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.
>>> 
>>> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.
>> 
>> I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.
>> 
>> I'm open to changing os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?
>
>> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 
>> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

With some suggestions from @albertnetymk, I've changed `commit_memory_limit` to return size_t, just as `reserve_memory_limit`. I think this is reasonable since `commit_memory_limit` should always be bounded by what `reserve_memory_limit` returns anyway, so having both return size_t is good.

I also refactored some of code so that it fits better with the fact that `commit_memory_limit` always returns a value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3139357029

From ayang at openjdk.org  Thu Jul 31 10:26:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 10:26:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
Message-ID: <BfBoVKnSO78UVeDZ9MamLJtn0fklxjydB5wD_aPJWbs=.be939505-8ff6-4068-9a03-92c6658369ad@github.com>

On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   commit_memory_limit return size_t instead of bool + out-parameter

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3074816051

From stuefe at openjdk.org  Thu Jul 31 10:26:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 10:26:54 GMT
Subject: RFR: 8364248: Separate memory limit detection from determining its
 size [v6]
In-Reply-To: <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
References: <Pr9_To2YdrnyTj-1MFgYgY6p0f8D76oAehw71iEtl2o=.e1c32ad0-0978-4a06-be35-fec001ef67ad@github.com>
 <Fs7xcv6lIsTgl0ny6XtxQOro1NirwowBpAxfQMHJ808=.5796ec5d-ede5-4027-8649-4b9358d389df@github.com>
Message-ID: <EIjadBWUBn0wNauG7_2xHdYXRWACiXtqS2FnuW08MdU=.d511d076-c38d-46a9-a1dd-4aa59ecf9427@github.com>

On Thu, 31 Jul 2025 10:20:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>> 
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>> 
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>> 
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   commit_memory_limit return size_t instead of bool + out-parameter

Good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26530#pullrequestreview-3074822741

From shade at openjdk.org  Thu Jul 31 10:39:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 10:39:54 GMT
Subject: RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically
In-Reply-To: <4c1DuAAZCbKIUE5abQBMaZLavv2DflzfnV2iiHjgIXQ=.d00a591b-3d90-4fb7-b8fc-f043801a4033@github.com>
References: <NjL0pHXDnXDhTMZc42HwQ0-4ncyD1d_WVF-yLfEv_e8=.393fdb43-d5d6-4c83-8abb-100837bd46b0@github.com>
 <_7jWpDMMZR9acVRgES9Xr9WuUv4ZMQl-or-3pQV8dck=.4166180d-77c1-4ebd-88aa-d28dae11135b@github.com>
 <4c1DuAAZCbKIUE5abQBMaZLavv2DflzfnV2iiHjgIXQ=.d00a591b-3d90-4fb7-b8fc-f043801a4033@github.com>
Message-ID: <NsvVTfN8uNNkwX1uHakXKqKyItPfEmpmfRre0_6pbXM=.4fcc5cd2-5d20-4af1-8fdc-d01f5b9be7cb@github.com>

On Thu, 31 Jul 2025 08:55:10 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> It actually seems like that's a pattern across the codebase

Yeah, we have not been consistent about this. I believe it would be busy work to change `FLAG_SET_DEFAULT` -> `FLAG_SET_ERGO` everywhere. But the new code should go `FLAG_SET_ERGO`, see for example just a few lines below:


  assert(supports_clflush(), "Always present");
  if (X86ICacheSync == -1) {
    // Auto-detect, choosing the best performant one that still flushes
    // the cache. We could switch to CPUID/SERIALIZE ("4"/"5") going forward.
    if (supports_clwb()) {
      FLAG_SET_ERGO(X86ICacheSync, 3);
    } else if (supports_clflushopt()) {
      FLAG_SET_ERGO(X86ICacheSync, 2);
    } else {
      FLAG_SET_ERGO(X86ICacheSync, 1);
    }


Plus, we have this macro that does the similar thing:


#define FLAG_SET_ERGO_IF_DEFAULT(name, value) \
  do {                                        \
    if (FLAG_IS_DEFAULT(name)) {              \
      FLAG_SET_ERGO(name, value);             \
    }                                         \
  } while (0)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26560#issuecomment-3139412386

From duke at openjdk.org  Thu Jul 31 11:07:30 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 11:07:30 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include
Message-ID: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>

The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 

Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.

-------------

Commit messages:
 - amend comment

Changes: https://git.openjdk.org/jdk/pull/26573/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364087
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26573/head:pull/26573

PR: https://git.openjdk.org/jdk/pull/26573

From stefank at openjdk.org  Thu Jul 31 11:32:53 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 31 Jul 2025 11:32:53 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include
In-Reply-To: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
Message-ID: <K69cQqW_m0J9FcPqGFwaEePWpb5LtORn_qg-pI9f1zo=.8fca1bf5-1ced-4961-ba4d-57f22202021c@github.com>

On Thu, 31 Jul 2025 11:00:07 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
> 
> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.

I propose that we remove this comment entirely.

Comments that only state why we include a specific file tends to become stale and incorrect when we evolve the code base.

-------------

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26573#pullrequestreview-3075026801

From shade at openjdk.org  Thu Jul 31 11:37:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 11:37:00 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v9]
In-Reply-To: <fcGZ6B4joQElEweYiCycmzHaUeroWe6HyYqwvlSZR90=.43221900-b8ef-44b8-8550-e20b021aa80e@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
 <fcGZ6B4joQElEweYiCycmzHaUeroWe6HyYqwvlSZR90=.43221900-b8ef-44b8-8550-e20b021aa80e@github.com>
Message-ID: <tyQrNUjiWZjBmC6mDfgbqO1p09NEPOToFfq4IQyOvwU=.7fba6437-11ab-4fe5-add1-9a7112d4caa2@github.com>

On Tue, 22 Jul 2025 22:37:37 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
>> 
>> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
>> 
>> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
>> 
>> For the test, I have manually tested different GCs with Flight Recording enabled and verified the events:
>> G1:
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:09:34.124 (2025-05-22)
>>   duration = 0.0108 ms
>>   gcId = 0
>>   gcWorkerId = 8
>>   name = "Termination"
>>   eventThread = "GC Thread#4" (osThreadId = 20483)
>> }
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:09:34.124 (2025-05-22)
>>   duration = 0.0467 ms
>>   gcId = 0
>>   gcWorkerId = 2
>>   name = "Termination"
>>   eventThread = "GC Thread#2" (osThreadId = 21251)
>> }
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:09:34.124 (2025-05-22)
>>   duration = 0.0474 ms
>>   gcId = 0
>>   gcWorkerId = 1
>>   name = "Termination"
>>   eventThread = "GC Thread#8" (osThreadId = 36359)
>> }
>> jdk.GCPhaseParallel {
>>   startTime = 23:09:41.925 (2025-05-22)
>>   duration = 0.000834 ms
>>   gcId = 14
>>   gcWorkerId = 7
>>   name = "Termination: Parallel Marking"
>>   eventThread = "GC Thread#1" (osThreadId = 21507)
>> }
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:09:41.925 (2025-05-22)
>>   duration = 0.000166 ms
>>   gcId = 14
>>   gcWorkerId = 7
>>   name = "Termination: Parallel Marking"
>>   eventThread = "GC Thread#1" (osThreadId = 21507)
>> }
>> 
>> 
>> Shenandoah: 
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:39:58.890 (2025-05-22)
>>   duration = 0.0202 ms
>>   gcId = 0
>>   gcWorkerId = 0
>>   name = "Termination: Concurrent Mark"
>>   eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827)
>> }
>> 
>> jdk.GCPhaseParallel {
>>   startTime = 23:39:58.890 (2025-05-22)
>>   duration = 0.0205 ms
>>   gcId = 0
>>   gcWorkerId = 1
>>   name = "Termination: Concurrent Mark"
>>   eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339)
>> }
>> 
>> jdk.GCPhaseParallel {
>>   s...
>
> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8354555
>  - Merge branch 'openjdk:master' into JDK-8354555
>  - Merge branch 'openjdk:master' into JDK-8354555
>  - Merge branch 'openjdk:master' into JDK-8354555
>  - Merge branch 'openjdk:master' into JDK-8354555
>  - Fix jft test failure
>  - Merge branch 'master' into JDK-8354555
>  - Patch to fix the PR concerns
>  - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
>  - Add include "workerThread.hpp"
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/016694bf...4d60e2e6

@tschatzl, @egahlin, can you take a look at this? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24676#issuecomment-3139603714

From coleenp at openjdk.org  Thu Jul 31 11:47:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Jul 2025 11:47:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
 <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
Message-ID: <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>

On Wed, 30 Jul 2025 20:25:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.
>
> The VM and Java use the same logic for the value of isIdentity(). 
> It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
> It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.

Roger, can you file another RFE for this for repo-valhalla and I can try to figure out how to best to do this?  Or I can.  I didn't think the valhalla isIdentityClass() code was expensive to call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2245151689

From ysuenaga at openjdk.org  Thu Jul 31 12:15:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 31 Jul 2025 12:15:04 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
Message-ID: <9dokJoeOWAcNlek3IhCDR9X74wo4o6Q_uKbPaCNAWqc=.6354d8af-ea6d-4670-9f69-30d61537b3b5@github.com>

On Wed, 30 Jul 2025 08:37:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor TestEmergencyDumpAtOOM.java

Thanks Erik and Thomas for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3139710043

From ysuenaga at openjdk.org  Thu Jul 31 12:15:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 31 Jul 2025 12:15:06 GMT
Subject: Integrated: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <l3AbBZZnIhD8-lXLWMGaA1hT0duTsXhSwn-h-oFVAts=.4fc42111-82aa-4bc1-86b9-46533be0d147@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

This pull request has now been integrated.

Changeset: 8ed214f3
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ed214f3b1864ea0095d05497f782ce4131836d4
Stats:     138 lines in 7 files changed: 123 ins; 3 del; 12 mod

8364090: Dump JFR recording on CrashOnOutOfMemoryError

Reviewed-by: egahlin, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/26468

From duke at openjdk.org  Thu Jul 31 12:30:46 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 12:30:46 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include [v2]
In-Reply-To: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
Message-ID: <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>

> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
> 
> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  remove comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26573/files
  - new: https://git.openjdk.org/jdk/pull/26573/files/8a551a1e..29231a33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26573&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26573&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26573/head:pull/26573

PR: https://git.openjdk.org/jdk/pull/26573

From duke at openjdk.org  Thu Jul 31 12:30:46 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 12:30:46 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include [v2]
In-Reply-To: <K69cQqW_m0J9FcPqGFwaEePWpb5LtORn_qg-pI9f1zo=.8fca1bf5-1ced-4961-ba4d-57f22202021c@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
 <K69cQqW_m0J9FcPqGFwaEePWpb5LtORn_qg-pI9f1zo=.8fca1bf5-1ced-4961-ba4d-57f22202021c@github.com>
Message-ID: <V3DtgRTxCGTuC59MuD399emSYjavyPnNGu4nTwJ9QIE=.0fa82cda-950a-4d82-aee1-9a7f42663dd1@github.com>

On Thu, 31 Jul 2025 11:30:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I propose that we remove this comment entirely.
> 
> Comments that only state why we include a specific file tends to become stale and incorrect when we evolve the code base.

Sure: 29231a33f7eda128088c2d0e8235868fc3c3b226

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26573#issuecomment-3139763989

From stefank at openjdk.org  Thu Jul 31 12:44:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 31 Jul 2025 12:44:55 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include [v2]
In-Reply-To: <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
 <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
Message-ID: <U-o-Op8C94ImIl2veZKCWMJwG6ARBTYSZHq_YDsXwrw=.58e3291c-93c1-4fb5-805e-80613e553ab9@github.com>

On Thu, 31 Jul 2025 12:30:46 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
>> 
>> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

Looks good. Thanks for fixing.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26573#pullrequestreview-3075235252

From ayang at openjdk.org  Thu Jul 31 12:44:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 31 Jul 2025 12:44:55 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include [v2]
In-Reply-To: <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
 <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
Message-ID: <RjYad7BjfpZzWaMz2P08vZI-ULGsYJq9jXArBu99468=.a459ded4-49b3-4d0e-99ce-a24b7c3ddafd@github.com>

On Thu, 31 Jul 2025 12:30:46 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
>> 
>> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26573#pullrequestreview-3075246048

From thartmann at openjdk.org  Thu Jul 31 12:49:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Jul 2025 12:49:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <XjFvCf3zhleAiFz_vuSgthTOsc6Kq3h-nOoaw3R-7O4=.06c7bfdf-3297-4f63-9822-ee4559f2c0cc@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Compiler changes look good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3075269461

From duke at openjdk.org  Thu Jul 31 12:55:58 2025
From: duke at openjdk.org (duke)
Date: Thu, 31 Jul 2025 12:55:58 GMT
Subject: RFR: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include [v2]
In-Reply-To: <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
 <WF4AYDvQGzbxKfFiUbDFMkeL-_TYd9S3qSzR7v-d0c4=.5e8f81df-286c-498b-bbde-b535eb391499@github.com>
Message-ID: <8kgk6zGW8PHdT3xRap20DwWoZnM79mUddqmb8uUW7ao=.831fd9cf-6e6c-4886-9699-a70591653635@github.com>

On Thu, 31 Jul 2025 12:30:46 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
>> 
>> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment

@fandreuz 
Your change (at version 29231a33f7eda128088c2d0e8235868fc3c3b226) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26573#issuecomment-3139861080

From duke at openjdk.org  Thu Jul 31 14:35:03 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 31 Jul 2025 14:35:03 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5]
In-Reply-To: <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>
Message-ID: <s8ysJscVbt10qzg7Q1icZBUf4E4dqDJVIzKbavT6uxM=.f2dd90a5-8e02-4041-9749-f97a9d4f8621@github.com>

On Thu, 31 Jul 2025 07:02:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> We plan to remove the uncompressed Klass pointer mode (`-UseCompressedClassPointers`) soon. Uncompressed Klass pointers are deprecated for JDK 25, and are planned to be removed for JDK 26. For background and motivation, please refer to this discussion [1] and the description and comments in this deprecation CSR [2].
>> 
>> A significant roadblock for removing `-UseCompressedClassPointers` had been the ongoing existence of 32-bit. 32-bit relies on uncompressed Klass pointers. 
>> 
>> Now, some of us think that 32-bit ports are on their way out [3]. We already removed support for x86 with JEP 503 in JDK 25, but we still have arm32 and zero 32-bit. The usefulness of the latter is arguable, seeing that the build is broken more often than not. However, even if we do rid ourselves of 32-bit eventually, that won't happen quickly: further discussions are needed, and then we will need a proper JEP with a deprecation phase for at least one release, probably more. That is too slow - we'd like to get rid of `-UseCompressedClassPointers` a lot sooner than that.
>> 
>> So we need to find a way to support `+UseCompressedClassPointers` on 32-bit.
>> 
>> -------
>> 
>> This patch adds support for `+UseCompressedClassPointers` on 32-bit in a minimally invasive way that keeps technical debt low. The code is small, clearly marked, and can be removed cleanly once we completely remove 32-bit support in two or three releases.
>> 
>> How to do this? Most is straightforward: pointers are 32-bit, so they are already "compressed". We set up narrow Klass encoding such that `base = NULL` and `shift = 0`; the entire 32-bit address space is therefore our encoding range. We now behave exactly as we would behave on 64-bit in "unscaled" encoding mode, with encoding and decoding being no-ops.
>> 
>> We also don't change the object layout; header stays the same - Klass is stored in the second word of the header as before, regardless of whether you interpret the word as `narrowKlass` or `Klass*`.
>> 
>> We also don't need to make many changes in terms of storage. Today, on 32-bit systems, Klass structures live inside the non-Klass metaspace regions, which are scattered arbitrarily throughout the address space. On 64-bit, we need a class space to confine Klass structures to the encoding range; here, where the encoding range encompasses the entire address space, we don't need a class space. Note that should we ever consider supporting some form of compact object headers on 32-bit - god forbid that ever happe...
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Fix some jtreg tests on arm
>  - fix arm gtests
>  - fix CompressedKlass* gtests on arm
>  - Merge master
>  - get rid of NEEDS_CLASS_SPACE define
>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>  - since to because
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Remove stray include
>  - Update src/hotspot/share/oops/compressedKlass.cpp
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f

test/hotspot/gtest/metaspace/test_metaspaceUtils.cpp line 105:

> 103:   check_metaspace_stats_are_consistent(combined_stats.non_class_space_stats());
> 104: 
> 105:   if (CompressedKlassPointers::needs_class_space() && UseCompressedClassPointers) {

For?consistency:
Suggestion:

  if (UseCompressedClassPointers && CompressedKlassPointers::needs_class_space()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2245575930

From duke at openjdk.org  Thu Jul 31 14:40:14 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 14:40:14 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v20]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <CUpE8s1DuiovMXjKu41c90aJZoUT2Bz9xybAmiTai_c=.26e60677-4222-432d-bd86-3f965567bdf5@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8357086: Made physical_memory() return void
 - 8357086: Fixed behavior of total_swap_space on Linux

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/fa09ae33..79f2faf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=18-19

  Stats: 67 lines in 13 files changed: 0 ins; 39 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From duke at openjdk.org  Thu Jul 31 14:40:15 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 14:40:15 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <24xIFc0iPvkbR2lM-x92rIDage4gZ2_VZVu036XKc1o=.d554b735-d60a-4723-a5ac-85c431d0db5e@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
 <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
 <24xIFc0iPvkbR2lM-x92rIDage4gZ2_VZVu036XKc1o=.d554b735-d60a-4723-a5ac-85c431d0db5e@github.com>
Message-ID: <ARic1Qn4KgDaOzGjok_iiJCLT3loZf4XYUHL28k8VNE=.9add2c4d-daf0-481a-b3b4-349884e4e8fe@github.com>

On Thu, 31 Jul 2025 08:02:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1523:
>> 
>>> 1521:   if (override_coop_limit) {
>>> 1522:     if (FLAG_IS_DEFAULT(MaxRAM)) {
>>> 1523:       (void)os::physical_memory(physical_mem_val);
>> 
>> This is one of the places where things seems to break down if we ever get a failure from os::physical_memory(). Before this patch I guess you would get random values and after this patch you will propagate 0 through this function. So, I guess it is not worse than before, but if we really can get a failure here then we do have an existing bug here.
>> 
>> With that said, when looking at this I'm wondering if there is any scenario where we can hit an error when calling the os::physical_memory? I understand that the OS APIs says that we can hit an error, but I wonder if that's only a theoretical issue? If it turns out that the APIs in effect never will fail then we can verify that they succeed during the JVM initialization and then remove the error code from os os::physical_memory() and let it only return a size_t instead. If we do this we can clean away a lot of the error handling code that is added in this PR.
>> 
>> The places that I see that could theoretically fail is:
>> 
>> 1) On AIX, but there's an `assert(0` in there to show that this really doesn't happen.
>> 
>> 2) On Windows if GlobalMemoryStatusEx(&ms) fails. The question is will this call fail for any reason on Windows? Maybe someone from Microsoft could help and tell if there ever is a reason why this code would fail:
>> 
>>   MEMORYSTATUSEX ms;
>>   ms.dwLength = sizeof(ms);
>>   GlobalMemoryStatusEx(&ms);
>
>> With that said, when looking at this I'm wondering if there is any scenario where we can hit an error when calling the os::physical_memory? I understand that the OS APIs says that we can hit an error, but I wonder if that's only a theoretical issue? If it turns out that the APIs in effect never will fail then we can verify that they succeed during the JVM initialization and then remove the error code from os os::physical_memory() and let it only return a size_t instead. If we do this we can clean away a lot of the error handling code that is added in this PR.
> 
> I absolutely agree. Keep it simple and stupid.
> 
>> 
>> The places that I see that could theoretically fail is:
>> 
>>     1. On AIX, but there's an `assert(0` in there to show that this really doesn't happen.
>> 
>>     2. On Windows if GlobalMemoryStatusEx(&ms) fails. The question is will this call fail for any reason on Windows? Maybe someone from Microsoft could help and tell if there ever is a reason why this code would fail:
>> 
>> 
>> ```
>>   MEMORYSTATUSEX ms;
>>   ms.dwLength = sizeof(ms);
>>   GlobalMemoryStatusEx(&ms);
>> ```
> 
> I don't think this can even have failed, we would have noticed:
> 
> - we use `GlobalMemoryStatusEx` to calculate `MaxRAM` (without error checking)
> - on debug builds, this would return something like "0xcccccccc_cccccccc" on error as size, since that's the default initialization by VisualC++. That's a lot of RAM :-)
> - we then base our default heap size on that. Reserving that much space for heap would have failed at at least some tests.
> 
> In product builds, the result would be random garbage; either 0, which would have failed, too, or some random number with a high probability of being very high, since the probability of random garbage that just happens to look like a small 64-bit number with zeros in the upper word is not that great. So we would have seen at least some errors on Windows in release builds, too.

Okay, makes sense, it looks like a failure of `os::physical_memory()` is something very unlikely to happen. So I made this function `void`, but, to be consistent with the rest, it provides the value by writing to the input parameter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2245590899

From stuefe at openjdk.org  Thu Jul 31 14:41:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Jul 2025 14:41:06 GMT
Subject: RFR: 8363998: Implement Compressed Class Pointers for 32-bit [v5]
In-Reply-To: <s8ysJscVbt10qzg7Q1icZBUf4E4dqDJVIzKbavT6uxM=.f2dd90a5-8e02-4041-9749-f97a9d4f8621@github.com>
References: <a-59JwU1dnL5Nojxizjf-T9kM1W3Aw-2iLwJjnxnvec=.3a5912c1-04a3-4c5a-b820-ab7eb66b0ad0@github.com>
 <WfMQB1JoER4c-z3jWIUGHYs7NWNduIvdlnZJ6AlowkI=.aa75429a-00f9-4352-9365-2b7deb6d87d8@github.com>
 <s8ysJscVbt10qzg7Q1icZBUf4E4dqDJVIzKbavT6uxM=.f2dd90a5-8e02-4041-9749-f97a9d4f8621@github.com>
Message-ID: <OCpwPNTOGkj74dlx5_gokLWbutH1FZegfqBSs8D8qgc=.0c3ff9bc-a5ae-4671-b1eb-fb66c687c962@github.com>

On Thu, 31 Jul 2025 14:31:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Fix some jtreg tests on arm
>>  - fix arm gtests
>>  - fix CompressedKlass* gtests on arm
>>  - Merge master
>>  - get rid of NEEDS_CLASS_SPACE define
>>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>>  - Merge branch 'master' into JDK-8363998-Implement-compressed-class-pointers-for-32-bit-platforms
>>  - since to because
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Remove stray include
>>  - Update src/hotspot/share/oops/compressedKlass.cpp
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/559795b0...e4a0f42f
>
> test/hotspot/gtest/metaspace/test_metaspaceUtils.cpp line 105:
> 
>> 103:   check_metaspace_stats_are_consistent(combined_stats.non_class_space_stats());
>> 104: 
>> 105:   if (CompressedKlassPointers::needs_class_space() && UseCompressedClassPointers) {
> 
> For?consistency:
> Suggestion:
> 
>   if (UseCompressedClassPointers && CompressedKlassPointers::needs_class_space()) {

Why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26491#discussion_r2245592312

From duke at openjdk.org  Thu Jul 31 14:46:11 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 14:46:11 GMT
Subject: Integrated: 8364087: Amend comment in globalDefinitions.hpp on
 "classfile_constants.h" include
In-Reply-To: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
References: <TYPhR8mMj5rVK2ssJ_bL-z2v2J7DmypjtpWYnnLq4bM=.82b4b2b8-3fee-4f3b-83af-5e88b9e603ca@github.com>
Message-ID: <MwA1sXXGG93Yxuhf5FbH0qvEzGEDFKlFPZEd7ZkJmmc=.198cf59c-384d-42c0-bfb3-10f3249738dc@github.com>

On Thu, 31 Jul 2025 11:00:07 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> The comment was introduced in [8231844](https://github.com/fandreuz/jdk/commit/fce43203699336e9513d06cd54b66735e93234a4). I looked around, and `<jvm.h>` is not included in any of the headers included by `globalDefinitions.hpp`, neither now nor in the original commit. Thus, I propose to amend the comment, as it [turned out to be confusing](https://github.com/openjdk/jdk/pull/26428/files#r2229575525) during an header clean up. 
> 
> Including `classfile_constants.h` is needed for e.g. `JVM_T_CHAR`, as stated by the comment, thus I'm going to leave that part intact.

This pull request has now been integrated.

Changeset: 53d152e7
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53d152e7dbccae9682e461e51ca75d63f88893cf
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8364087: Amend comment in globalDefinitions.hpp on "classfile_constants.h" include

Reviewed-by: stefank, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/26573

From duke at openjdk.org  Thu Jul 31 14:49:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 14:49:23 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v21]
In-Reply-To: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
Message-ID: <2OaqEEA9c9Rh36ojMSu6k-hq9IYhQam-VbJUlDRusmM=.6de736be-8e25-490f-bc79-19814afd0954@github.com>

> Hi,
> 
> in this PR the output value types for functions which return memory are changed, namely:
> 
> 
> static julong available_memory(); --> static bool available_memory(size_t& value);
> static julong used_memory(); --> static bool used_memory(size_t& value);
> static julong free_memory(); --> static bool free_memory(size_t& value); 
> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value);
> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); 
> static julong physical_memory(); --> static bool physical_memory(size_t& value); 
> 
> 
> The return boolean value indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, and unsuccessful call is logged. 
> 
> Later, the return value can be attributed with `[[nodiscard]]` to enforce the pattern.
> 
> Tested in GHA and Tiers 1-5.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8357086: Small fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25450/files
  - new: https://git.openjdk.org/jdk/pull/25450/files/79f2faf0..22c752c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25450&range=19-20

  Stats: 4 lines in 2 files changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25450.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25450/head:pull/25450

PR: https://git.openjdk.org/jdk/pull/25450

From duke at openjdk.org  Thu Jul 31 14:49:24 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 31 Jul 2025 14:49:24 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v13]
In-Reply-To: <3ZUAaIkIDWUZ_vPtsvyJ7Yi0R9slhRVjIBALgRdE9DU=.79b82f4d-7537-4f2b-9311-af4f23914a87@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <S67EsrGCGVdcuqCfDBVG6Jsd7qx9wwu3sBg-p6yocdA=.87bc1173-2944-4985-81db-9a6190450083@github.com>
 <AC33L_et1LxW50bwYMRJRpSMFbKRrMkeIuJs38d0c58=.e8b4555d-de5c-45b4-9dee-e521b66cef30@github.com>
 <H2_aZZNX-iN-uSL0FhnfUbH-KODwVzZXwCaF3ooeIi4=.b0475397-581c-46d1-86e1-2994a6cb867e@github.com>
 <cuR4GXKpL45Akw2pFcIHxGEikHBXZvwAKWOhN2E49II=.773f3f92-0eb9-4386-9947-059c49a80bb5@github.com>
 <PVZiZsWMZIl6h6n9bRAZ64aajlWPN6y4B_d-BGJQlMc=.665123e0-c2a8-4688-be8b-790ac69c0982@github.com>
 <3ZUAaIkIDWUZ_vPtsvyJ7Yi0R9slhRVjIBALgRdE9DU=.79b82f4d-7537-4f2b-9311-af4f23914a87@github.com>
Message-ID: <ESKwjAhm3a9rGDfRrvqi7Q34ccKkrzyK9vCY3mJccNI=.b007556e-5e74-40df-a01b-d2428df6ac50@github.com>

On Thu, 31 Jul 2025 09:43:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Right, I looked at another place, sorry.
>> 
>> In `total_swap_space` one wants to compute the total swap space out of two values, memory_limit and swap_limit, by the following formula: 
>> 
>> total_swap_space = (memory_limit  + swap_limit) - memory_limit
>> 
>> the 1st summand (in braces) is returned by  `OSContainer::memory_and_swap_limit_in_bytes()`, the 2nd by `OSContainer::memory_limit_in_bytes()`. The problem is that `swap_limit` can be unbounded (represented by -1 in the container code). So we end up in returning `static_cast<size_t>(-1)`, which would be 2^64-1 on 64bit platform and is the same as `std::numeric_limits<size_t>::max()`.
>> 
>> In my opinion, it is a good representation of the _unbounded_ value.
>> 
>> There are only 2 places where `os::total_swap_space()` is used, both in JFR-related code. In both cases, the `size_t` values obtained from `os::total_swap_space()` is converted to a signed 64bit value (either jlong or s8, which is the same) with `static_cast`. If `size_t` has the same bitness as `jlong`, then one will get back -1 after conversion, so nothing is changed from the JFR perspective. However, if `size_t` is 32bit, then such conversion will not return -1, but instead a positive value of 2^32-1. It has to be addressed separately.
>
>> the 1st summand (in braces) is returned by `OSContainer::memory_and_swap_limit_in_bytes()`, the 2nd by `OSContainer::memory_limit_in_bytes()`. The problem is that `swap_limit` can be unbounded (represented by -1 in the container code). So we end up in returning `static_cast<size_t>(-1)`, which would be 2^64-1 on 64bit platform and is the same as `std::numeric_limits<size_t>::max()`.
>> 
>> In my opinion, it is a good representation of the _unbounded_ value.
> 
> The error code -1 happens to be interpretable as a large number if it is converted to a unsigned value, and one can argue that this large number is an OK value to represent an unbound value. Personally, I think that is more accidental than the intended behavior of this code. This is an obscure detail in the code, and given that it isn't immediately obvious for the reader it also makes it a risk that people will not understand this if they make future changes to the code.
> 
> And even we accept that -1 can be used as the unbound value, then I think it is wrong to use the unbound value in this code. If the container says that the swap space is unbound can't the underlying host still return a sensible value in si.totalswap? If this is the case, then an error in the container code will cause os::total_swap_space to return a way higher swap value than what the host is configured to have. 
> 
> With all this said, I think the above code should check if memory_and_swap_limit_in_bytes returns -1, just like we do in os::free_swap_space().

I modified the behavior of that method as suggested, it now reports the host total swap if the container returned -1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2245599200

From rriggs at openjdk.org  Thu Jul 31 15:20:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Jul 2025 15:20:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <J4_n5YAZDvWgk118g06cLxZ4Cv-fQaIwdwgJznOlosg=.65adcafe-4595-4ca2-b400-8ee9400d21c7@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Looks good, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3075875144

From rriggs at openjdk.org  Thu Jul 31 15:21:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Jul 2025 15:21:00 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
 <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
 <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>
Message-ID: <LF1Zpw4ZBjW7WqKhol_OOCweJHs1aTL2527DVLDbGx4=.75c9d2a1-d5ea-46e3-8ca4-c4b3b888d322@github.com>

On Thu, 31 Jul 2025 11:45:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The VM and Java use the same logic for the value of isIdentity(). 
>> It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
>> It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.
>
> Roger, can you file another RFE for this for repo-valhalla and I can try to figure out how to best to do this?  Or I can.  I didn't think the valhalla isIdentityClass() code was expensive to call.

Created [JDK-8364447](https://bugs.openjdk.org/browse/JDK-8364447)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2245695722

From stefank at openjdk.org  Thu Jul 31 15:27:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 31 Jul 2025 15:27:01 GMT
Subject: RFR: 8357086: os::xxx functions returning memory size should
 return size_t [v18]
In-Reply-To: <ARic1Qn4KgDaOzGjok_iiJCLT3loZf4XYUHL28k8VNE=.9add2c4d-daf0-481a-b3b4-349884e4e8fe@github.com>
References: <Ba6vpdR0GzfNUF9rn864IKFq2byx44jNWFWGU5a0D3w=.ed2dc719-f747-4c4a-87ce-a5fd5f24fe91@github.com>
 <_JFKdc6j9FxrcIvMknk5I3aYHKU_FzJtxiCWrgM1IQc=.38cdd378-f156-43d0-a4ee-e81afdc16f90@github.com>
 <SJ069POriCitDvcKVjr29uvibAMiSQP32jdxSVG0tWM=.282153ee-81e8-4597-a5f6-b88ec1ca6972@github.com>
 <24xIFc0iPvkbR2lM-x92rIDage4gZ2_VZVu036XKc1o=.d554b735-d60a-4723-a5ac-85c431d0db5e@github.com>
 <ARic1Qn4KgDaOzGjok_iiJCLT3loZf4XYUHL28k8VNE=.9add2c4d-daf0-481a-b3b4-349884e4e8fe@github.com>
Message-ID: <IeZs6ZlNOHWnAHKLWgcRrYqP8FZh8jhvrLBXYaKTQWI=.f6186817-4375-4f56-a92a-56118eb086c6@github.com>

On Thu, 31 Jul 2025 14:37:45 GMT, Anton Artemov <duke at openjdk.org> wrote:

>>> With that said, when looking at this I'm wondering if there is any scenario where we can hit an error when calling the os::physical_memory? I understand that the OS APIs says that we can hit an error, but I wonder if that's only a theoretical issue? If it turns out that the APIs in effect never will fail then we can verify that they succeed during the JVM initialization and then remove the error code from os os::physical_memory() and let it only return a size_t instead. If we do this we can clean away a lot of the error handling code that is added in this PR.
>> 
>> I absolutely agree. Keep it simple and stupid.
>> 
>>> 
>>> The places that I see that could theoretically fail is:
>>> 
>>>     1. On AIX, but there's an `assert(0` in there to show that this really doesn't happen.
>>> 
>>>     2. On Windows if GlobalMemoryStatusEx(&ms) fails. The question is will this call fail for any reason on Windows? Maybe someone from Microsoft could help and tell if there ever is a reason why this code would fail:
>>> 
>>> 
>>> ```
>>>   MEMORYSTATUSEX ms;
>>>   ms.dwLength = sizeof(ms);
>>>   GlobalMemoryStatusEx(&ms);
>>> ```
>> 
>> I don't think this can even have failed, we would have noticed:
>> 
>> - we use `GlobalMemoryStatusEx` to calculate `MaxRAM` (without error checking)
>> - on debug builds, this would return something like "0xcccccccc_cccccccc" on error as size, since that's the default initialization by VisualC++. That's a lot of RAM :-)
>> - we then base our default heap size on that. Reserving that much space for heap would have failed at at least some tests.
>> 
>> In product builds, the result would be random garbage; either 0, which would have failed, too, or some random number with a high probability of being very high, since the probability of random garbage that just happens to look like a small 64-bit number with zeros in the upper word is not that great. So we would have seen at least some errors on Windows in release builds, too.
>
> Okay, makes sense, it looks like a failure of `os::physical_memory()` is something very unlikely to happen. So I made this function `void`, but, to be consistent with the rest, it provides the value by writing to the input parameter.

1) I had hoped for some kind of sanity check in the initialization code that sets up _physical_memory. We can handle that as a separate RFE.

2) I really would prefer if os::physical_memory() returned size_t via the normal means and only use output parameters for the functions that require more than one return value. And on that note ...

3) Do the other functions (free_memory and available_memory) ever fail or could we fix those as well? Windows and AIX are using the same APIs that are used for os::physical_memory. Linux uses sysinfo, which only seems to fail if we pass in an incorrect value. BSD has an assert that would trigger if this fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25450#discussion_r2245708983

From tschatzl at openjdk.org  Thu Jul 31 15:27:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Jul 2025 15:27:56 GMT
Subject: RFR: 8364254: Serial: Remove soft ref policy update in WhiteBox
 FullGC
In-Reply-To: <MQ31Ok-NNG66SPysEMeFjYBm3CoK49RWqGjWL1_CPyc=.395d2819-ffb2-4635-8ec2-51cc78a63a7e@github.com>
References: <MQ31Ok-NNG66SPysEMeFjYBm3CoK49RWqGjWL1_CPyc=.395d2819-ffb2-4635-8ec2-51cc78a63a7e@github.com>
Message-ID: <FSLT8KG5XaydwxLbsw7tWkAcjOGcv0PoCEyB8Eebc9s=.63a5c4d5-63e0-46b7-bcce-674df79897da@github.com>

On Tue, 29 Jul 2025 09:37:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing Serial specific logic in `WB_FullGC`, because Serial full-gc handles white-box full-gc already.
> 
> Test: tier1-3

Seems good.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26528#pullrequestreview-3075898221

From coleenp at openjdk.org  Thu Jul 31 20:19:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Jul 2025 20:19:06 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
Message-ID: <JI7C1LMFgPoAZZUdM5YBzm-CXmRFPvSG_p2mSNfleCU=.93318dce-18ee-4784-8c6c-ead83d1c7264@github.com>

This change introduces a diagnostic flag to disable the change to allocate interface and abstract Klass metadata in the non-class metaspace.  Testing for JDK 25 has completed with this feature in place, but there may be cases where we should disable this.  A future change will be to remove this code.
Tested with tier1-4 with the flag off, and 1-4 with the flag on.

-------------

Commit messages:
 - 8343218: Disable allocating interface and abstract classes in non-class metaspace

Changes: https://git.openjdk.org/jdk/pull/26579/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26579&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343218
  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26579.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26579/head:pull/26579

PR: https://git.openjdk.org/jdk/pull/26579

From never at openjdk.org  Thu Jul 31 20:51:59 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 31 Jul 2025 20:51:59 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
Message-ID: <2hi_TI_U0T4NwVPEG7LIMjDD3xvEYx-q-BBJGIGQikA=.82f2b333-7084-4e53-937f-2c014b37635d@github.com>

On Thu, 24 Jul 2025 20:03:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readability suggestion

src/hotspot/share/runtime/deoptimization.cpp line 940:

> 938:     int callee_size_of_parameters = 0;
> 939:     for (int frame_idx = 0; frame_idx < cur_array->frames(); frame_idx++) {
> 940:       assert(is_top_frame == (frame_idx == 0), "must be");

Why not replace this with direct computation of the value:

bool is_top_frame = (frame_idx == 0);

then you don't even need the final reset of the value either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2246351521

From never at openjdk.org  Thu Jul 31 21:04:56 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 31 Jul 2025 21:04:56 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
Message-ID: <Eov181G-UVyTEesxVNnPDY8OEGQeWgBCy7tHzfZh4Ow=.57076a5d-bdf7-4c4b-b521-20c13a0d2cdc@github.com>

On Thu, 24 Jul 2025 20:03:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readability suggestion

src/hotspot/share/runtime/deoptimization.cpp line 971:

> 969: 
> 970:         cur_code = str.next();
> 971:         reexecute = true;

This seems a little unsavory, particularly since there's a later step which will print that value as if it was the original one.  Since there's only one later logic use of the variable maybe there's should be a new flag to mark special case?  Like `rolled_forward`?  It might be fine as is with comments explaining this and fixing the printing to reflect what occurred here.

src/hotspot/share/runtime/deoptimization.cpp line 995:

> 993:       int map_expr_invoke_ssize = mask.expression_stack_size() + cur_invoke_parameter_size;
> 994:       int expr_ssize_before = iframe_expr_ssize + (is_top_frame ? top_frame_expression_stack_adjustment : 0);
> 995:       int map_expr_callee_ssize = mask.expression_stack_size() + callee_size_of_parameters;

`map` in these names might be more clearly `oopmap`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2246372241
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2246372513

From missa at openjdk.org  Thu Jul 31 21:27:55 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 31 Jul 2025 21:27:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
 <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>
Message-ID: <bl5aVGE9cFkrH8gvKBj4g7FppqDY7Vbb2EeInE0aCFM=.a530da0d-af87-42dd-aaf4-f74c33506306@github.com>

On Wed, 30 Jul 2025 18:26:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move error bound to separate section in comment header
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp line 325:
> 
>> 323:   __ jcc(Assembler::aboveEqual, L_2TAG_PACKET_0_0_2); // Branch only if |x| is not in [23/64, 3*2^8)
>> 324:   __ movsd(xmm3, ExternalAddress(HALFMASK), r11 /*rscratch*/);
>> 325:   __ movsd(xmm1, ExternalAddress(L2E), r11 /*rscratch*/);
> 
> xmm1 is used at L_2TAG_PACKET_0_0_2 -> L_2TAG_PACKET_3_0_2 line 507 below so should be loaded prior to L_2TAG_PACKET_0_0_2.

At the end of L_2TAG_PACKET_3_0_2, the goal is to generate +/- Infinity and set the overflow flag, so the L2E load into xmm1 actually doesn't matter in this case. I'll move the load to ensure xmm1 is initialized with a known value before it's used though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26152#discussion_r2246405871

From missa at openjdk.org  Thu Jul 31 21:32:16 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 31 Jul 2025 21:32:16 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
> 
> The command to run all range specific micro-benchmarks is posted below.
> 
> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
> 
> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
> 
> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
> 
> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.

Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:

  Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26152/files
  - new: https://git.openjdk.org/jdk/pull/26152/files/c0adc8b3..3ab7ab3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26152/head:pull/26152

PR: https://git.openjdk.org/jdk/pull/26152

From dlong at openjdk.org  Thu Jul 31 22:33:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Jul 2025 22:33:29 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v7]
In-Reply-To: <Eov181G-UVyTEesxVNnPDY8OEGQeWgBCy7tHzfZh4Ow=.57076a5d-bdf7-4c4b-b521-20c13a0d2cdc@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
 <GZLfH9glINKbkf9Uj1ZotKIw4mO1-XxZlrM0h1iaqzs=.4063b8e3-62c2-452e-bae2-bccda5997002@github.com>
 <Eov181G-UVyTEesxVNnPDY8OEGQeWgBCy7tHzfZh4Ow=.57076a5d-bdf7-4c4b-b521-20c13a0d2cdc@github.com>
Message-ID: <vnRxrTl4xJBCgBtv8TtdHFYlbBByXFoUHCsRlYO6njk=.7a2fe648-536a-4e71-99dc-244935e8674e@github.com>

On Thu, 31 Jul 2025 21:02:01 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   readability suggestion
>
> src/hotspot/share/runtime/deoptimization.cpp line 971:
> 
>> 969: 
>> 970:         cur_code = str.next();
>> 971:         reexecute = true;
> 
> This seems a little unsavory, particularly since there's a later step which will print that value as if it was the original one.  Since there's only one later logic use of the variable maybe there's should be a new flag to mark special case?  Like `rolled_forward`?  It might be fine as is with comments explaining this and fixing the printing to reflect what occurred here.

OK, I cleaned this up a bit.  I think this code could be cleaned up further and use fewer variables, but I'd like to save that for another day.

> src/hotspot/share/runtime/deoptimization.cpp line 995:
> 
>> 993:       int map_expr_invoke_ssize = mask.expression_stack_size() + cur_invoke_parameter_size;
>> 994:       int expr_ssize_before = iframe_expr_ssize + (is_top_frame ? top_frame_expression_stack_adjustment : 0);
>> 995:       int map_expr_callee_ssize = mask.expression_stack_size() + callee_size_of_parameters;
> 
> `map` in these names might be more clearly `oopmap`.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2246507655
PR Review Comment: https://git.openjdk.org/jdk/pull/26121#discussion_r2246507871

From dlong at openjdk.org  Thu Jul 31 22:33:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Jul 2025 22:33:29 GMT
Subject: RFR: 8278874: tighten VerifyStack constraints [v8]
In-Reply-To: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
References: <SzmkITQD9TcpLijxE-OBIEgroeuApBRoxpZil0UPa4c=.ca523fde-414c-46f9-89a8-1e430c77698c@github.com>
Message-ID: <y-E5hu226JqYVd-VJDdPk9Ikq19e0Cx2jwbwCs9vhdM=.60812369-60fc-4bad-8927-892df236f204@github.com>

> The VerifyStack logic in Deoptimization::unpack_frames() attempts to check the expression stack size of the interpreter frame against what GenerateOopMap computes.  To do this, it needs to know if the state at the current bci represents the "before" state, meaning the bytecode will be reexecuted, or the "after" state, meaning we will advance to the next bytecode.  The old code didn't know how to determine exactly what state we were in, so it checked both.  This PR cleans that up, so we only have to compute the oopmap once.  It also removes old SPARC support.

Dean Long has updated the pull request incrementally with two additional commits since the last revision:

 - more cleanup
 - simplify is_top_frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26121/files
  - new: https://git.openjdk.org/jdk/pull/26121/files/535fbb05..6257de6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26121&range=06-07

  Stats: 15 lines in 1 file changed: 6 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26121/head:pull/26121

PR: https://git.openjdk.org/jdk/pull/26121

From sviswanathan at openjdk.org  Thu Jul 31 23:03:55 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 31 Jul 2025 23:03:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
Message-ID: <u1ilI1NjO_n5aSZvJErmPO3pvUr0tXFpg4722xlEPvo=.a962fa71-d6d8-4bbb-bbb0-3649058933ce@github.com>

On Thu, 31 Jul 2025 21:32:16 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future.
>> 
>> The command to run all range specific micro-benchmarks is posted below.
>> 
>> `make test TEST="micro:SinhPerf.SinhPerfRanges"`
>> 
>> The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version.
>> 
>> For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively.
>> 
>> | Input range(s)                                 | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup |
>> | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: |
>> | [-2^(-28), 2^(-28)]                          | 844160                                    | 216029                                     | 0.26x       |
>> | [-22, -2^(-28)], [2^(-28), 22]           | 81662                                      | 157351                                    | 1.93x       |
>> | [-709.78, -22], [22, 709.78]              | 119075                                    | 167635                                    | 1.41x       |
>> | [-710.48, -709.78], [709.78, 710.48] | 111636                                   | 177125                                     | 1.59x       |
>> | (-INF, -710.48], [710.48, INF)           | 959296                                    | 313839                                    | 0.33x       |
>> 
>> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26152#pullrequestreview-3077118616

From liach at openjdk.org  Thu Jul 31 23:34:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 23:34:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <-4Y7tMRv4npz0NHmvNpe4WCP1DSfZwQDMD2uxE36QNE=.8a72f648-6901-4556-9265-ae665992865b@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

These changes look reasonable.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3077160252