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