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 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 amenkov at openjdk.org  Tue Jul  1 01:02:01 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Jul 2025 01:02:01 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
Message-ID: <mpYSpokuhGXdJONiRoNn1dDFIyLb7hQJALN9BBWO_94=.f820f1d3-cc1c-4b9c-b2a1-fa16d10125cc@github.com>

On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
>> 
>> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
>> 
>> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   startLocalDebugee renamed to startDebugee

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25887#pullrequestreview-2973161889

From coleenp at openjdk.org  Tue Jul  1 01:55:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 01:55:48 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/791f2146..9b704274

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

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

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

From coleenp at openjdk.org  Tue Jul  1 01:55:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 01:55:50 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v11]
In-Reply-To: <h2U4wRTcEbLKV7Mve5iO6KOEee5t47ald41NEZxvfug=.abffc9dc-9e2d-4f4b-82e1-177654a56ced@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <mIHdl4_tc3bd4M13BlvV2CPjgZafZ7Yn5c7ohmCA7W4=.89aada01-a41a-47ed-a1ab-0c593cd45187@github.com>
 <h2U4wRTcEbLKV7Mve5iO6KOEee5t47ald41NEZxvfug=.abffc9dc-9e2d-4f4b-82e1-177654a56ced@github.com>
Message-ID: <Cxv_fFTrSmcEW1VjG-SsnTvsOb-Q3XZynHGJgAV-BZ8=.0d81cc8e-f2b1-4be8-a85e-d5caa8d4ddf1@github.com>

On Mon, 30 Jun 2025 23:26:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update test/lib/RedefineClassHelper.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 45:
> 
>> 43:         ClassVersionAfterRedefine cvar = new ClassVersionAfterRedefine();
>> 44: 
>> 45:         // Poor man's renaming of class "TestClassOld" to "TestClassXXX"
> 
> It is not "poor man's" renaming anymore and RedefineClassHelper.replaceClassName() is self-explanable. So this comment could be just removed.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2176243389

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 02:33:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Jul 2025 02:33:42 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <kyFAicDYK1jfNdAsl2EDcdpARdZ6lhixLq47NoalRoY=.b18fe183-9728-4431-8908-0acb1f7db6ea@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

LGTM!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2973299545

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: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 dfuchs at openjdk.org  Tue Jul  1 07:35:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Jul 2025 07:35:40 GMT
Subject: RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <vNNZnSq-ruFJlo34wwSVX03EzhaGd4p0h0XA2fpgsZ4=.8a4d40cc-7043-460c-8576-d9dabdcdb4b4@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

The changes look reasonable. Please get a Reviewer from serviceability too before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2973919189

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 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 kevinw at openjdk.org  Tue Jul  1 08:52:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 08:52:56 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object [v5]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

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

 - Further doc update
 - Test udpate (listIterator)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/8b36d3e5..a2a28dde

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

  Stats: 17 lines in 4 files changed: 14 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

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

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 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 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 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 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 sspitsyn at openjdk.org  Tue Jul  1 10:15:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 10:15:42 GMT
Subject: RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <5KWnC8pnEXr4Vo_kL09Zn6fvR5AeszMX2APiogVLwmQ=.3902890e-16aa-4430-b252-3a2978fcfe42@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

This looks okay.
The CSR's "Compatibility Risk Description" should not be empty.
Also reviewed the RN and added a minor suggestion.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2974681915

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 kevinw at openjdk.org  Tue Jul  1 10:37:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Jul 2025 10:37:38 GMT
Subject: RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>
Message-ID: <fg_eY5yPM8Z0irGghVrhs6LBniJ-jDuCQ7e2aliO4kg=.94a46470-9f72-4bf4-a787-1ff18c1c4ac9@github.com>

On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Removal of an obscure historical feature, following on from its deprecation for removal in:
> 
> 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

Thanks Daniel!  Thanks Serguei, have addressed those points.

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

PR Comment: https://git.openjdk.org/jdk/pull/25697#issuecomment-3023296826

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 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 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 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 lmesnik at openjdk.org  Tue Jul  1 17:07:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Jul 2025 17:07:41 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <ZNfxJu-PG7RipEfrcHHCp_BWQqe_iCQkaYikwk1d1D8=.b4ea874c-6daf-404a-84df-23a1e24b6a29@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2976286692

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 coleenp at openjdk.org  Tue Jul  1 17:17:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 17:17:50 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v12]
In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com>
Message-ID: <HqyfexQq8yOiiAqYHTr-oeYPzcbvPTsQyAXaN_K9wsI=.0341c181-8a93-452d-a68f-b624dc791d10@github.com>

On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

Thanks for the reviews Leonid, Serguei and David, and thanks for the help with ClassFile API Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3024888621

From coleenp at openjdk.org  Tue Jul  1 17:17:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 17:17:51 GMT
Subject: Integrated: 8359707: Add classfile modification code to
 RedefineClassHelper
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <XoBo3W-O-cah9xL1v1KkDsC20iSTVxyDIdn_damW36s=.b079f981-22de-45f8-8dae-919f40111efd@github.com>

On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

This pull request has now been integrated.

Changeset: e7a45003
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7a450038a47a76d2e616ebce2a7fa8a51e36ea4
Stats:     91 lines in 2 files changed: 44 ins; 43 del; 4 mod

8359707: Add classfile modification code to RedefineClassHelper

Reviewed-by: lmesnik, dholmes, sspitsyn

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

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

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 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 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 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 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 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 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 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 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 rrich at openjdk.org  Wed Jul  2 09:36:15 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 2 Jul 2025 09:36:15 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
Message-ID: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>

This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.

Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.

Testing: x86_64, ppc64

Failed inlining on x86_64 with TieredCompilation disabled:


make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1

[...]

STDOUT:
CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
                            @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
                            @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
                              @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
                                @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
                            @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
              s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
              s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
              s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
                              @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
                            @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
2025-07-02T09:25:53.396634900Z Attempt 1, found: false
2025-07-02T09:25:53.415673072Z Attempt 2, found: false
2025-07-02T09:25:53.418876867Z Attempt 3, found: false

[...]

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

Commit messages:
 - Force inlining of String*.* methods
 - Force inlining of StringBuffer methods

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

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

From rrich at openjdk.org  Wed Jul  2 09:36:15 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 2 Jul 2025 09:36:15 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <owf286wT2T5xGJQ1QoqEACi9Q209c9Xpv2SJZSqs3jo=.1193694c-58ca-4e9d-a842-29b76778a30a@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Jit compiler folks might want to have a look at this pr. Maybe there's a better for having the StringBuilder locks eliminated deterministically.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3027054192

From mdoerr at openjdk.org  Wed Jul  2 09:54:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 09:54:41 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <TJiYFA8CQv-efB9QVsjMu-Ehn7t6uup4LFjlFgXqpCQ=.012942f6-8e5a-4ed2-9f29-f44ad1291780@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2978510981

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 kevinw at openjdk.org  Wed Jul  2 11:59:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 11:59:20 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency
Message-ID: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>

There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
Tests should retry some small number of times, rerunning the jstat tool to recapture data.

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

Commit messages:
 - (C)
 - Common base class for Jstat tests
 - GCPerfTests retry

Changes: https://git.openjdk.org/jdk/pull/26094/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26094&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305567
  Stats: 98 lines in 9 files changed: 60 ins; 12 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26094/head:pull/26094

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

From kevinw at openjdk.org  Wed Jul  2 11:59:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Jul 2025 11:59:20 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency
In-Reply-To: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
Message-ID: <qUdNeoXl6foz1UiJjrC40UCMzxeHXSJ9SbDcN61FQqU=.b4040a50-d663-4932-8ef5-b03f6d779f38@github.com>

On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
> Tests should retry some small number of times, rerunning the jstat tool to recapture data.

jstat reads PerfData counters, at random times (as designed), 
and tests assert that they are always consistent.
But PerfData counters are written individually and may not always be consistent.

e.g.

296 void G1MonitoringSupport::update_sizes() {
...
303     _to_space_counters->update_capacity(_survivor_space_committed);
304     _to_space_counters->update_used(_survivor_space_used);

If a space shrinks, we write a new capacity which might be lower than the previous-and-still-visible used value (for a very small time).
There has to be a small window where the assertions do not hold, and we seem to hit these occasionally over a period of years, e.g.

java.lang.RuntimeException: S1U > S1C (utilization > capacity)
at utils.JstatResults.assertThat(JstatResults.java:172)
at utils.JstatGcResults.assertConsistency(JstatGcResults.java:89)
at GcTest01.main(GcTest01.java:52)


The other known failure is:

java.lang.RuntimeException: GCT != (YGCT + CGCT + FGCT) (GCT = 0.051, YGCT = 0.008, CGCT = 0.026, FGCT = 0.0, (YCGT + CGCT + FGCT) = 0.034)
at utils.JstatResults.assertThat(JstatResults.java:172)
at utils.JstatGcResults.assertConsistency(JstatGcResults.java:123)
at GcTest01.main(GcTest01.java:52)

...where again there must be small windows for a problem when stats are updated.

The assertion of consistency should retry some limited number of times on inconsistent data.
If jstat data fetching is truly broken, or the data is truly incorrect, the test will hit the small retry limit and fail.

serviceability/tmtools/jstat/GcTest01.java 
and 
serviceability/tmtools/jstat/GcTest02.java are known to fail occasionally.

The known failures have commonly been with -Xcomp which can mean a slow test, but this does not reproduce on demand.

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

PR Comment: https://git.openjdk.org/jdk/pull/26094#issuecomment-3027592580

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 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 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 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 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 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 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 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 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 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 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 alanb at openjdk.org  Thu Jul  3 08:39:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 08:39:40 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Thanks for improving this, this test was intended unstable. 

It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2982264097

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 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 rrich at openjdk.org  Thu Jul  3 14:38:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 3 Jul 2025 14:38:40 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
Message-ID: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>

On Thu, 3 Jul 2025 08:36:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out.

I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3032511575

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 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 lmesnik at openjdk.org  Thu Jul  3 16:54:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 3 Jul 2025 16:54:43 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency
In-Reply-To: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
Message-ID: <XFLoME_VcmlS-rZXSnTZMTsPjFIRWHawajqtODchbbI=.12f35f13-3d85-459c-be02-d60975fbc503@github.com>

On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
> Tests should retry some small number of times, rerunning the jstat tool to recapture data.

Marked as reviewed by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatTool.java line 46:

> 44:         for (int i = 1; i <= TRIES; i++) {
> 45:             try {
> 46:                 results = measure();

Might be the 'measure' and 'assertConsistency' might be changed to from 'public' to 'package-local` if they are not needed to be used by tests directly.

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

PR Review: https://git.openjdk.org/jdk/pull/26094#pullrequestreview-2983899660
PR Review Comment: https://git.openjdk.org/jdk/pull/26094#discussion_r2183255118

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 lmesnik at openjdk.org  Thu Jul  3 16:59:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 3 Jul 2025 16:59:40 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <DCsthNw-6hib-dyg2Tz_TzLP-Iz-MQBbit_7fCC6fMs=.dfe8fb45-04d7-4ecf-9b30-15a1f4e4b424@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2983913131

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 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 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 alanb at openjdk.org  Thu Jul  3 17:59:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 17:59:44 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining
In-Reply-To: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
Message-ID: <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>

On Thu, 3 Jul 2025 14:36:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.

I think that would be useful, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3033099720

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 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 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 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 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 rrich at openjdk.org  Fri Jul  4 08:14:19 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 4 Jul 2025 08:14:19 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Allow vm.debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26033/files
  - new: https://git.openjdk.org/jdk/pull/26033/files/8561d522..a43e54db

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

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

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

From rrich at openjdk.org  Fri Jul  4 08:14:20 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 4 Jul 2025 08:14:20 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
 <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
Message-ID: <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>

On Thu, 3 Jul 2025 17:57:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work.
> 
> I think that would be useful, thank you.

I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3034923279

From alanb at openjdk.org  Fri Jul  4 10:27:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Jul 2025 10:27:39 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <Hqr-Ryjr-xHnn_pnhTmRhhbvvq59jibwJ3bVAbQE26w=.d7560c4e-ac9f-495a-80cc-cc19aeb29197@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2986518539

From kevinw at openjdk.org  Fri Jul  4 12:18:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 4 Jul 2025 12:18:42 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <K35liKJ1R-7bN63VnQjPbKOGjJbmAkXzAVIteXjNv10=.bbae3a6a-2610-4082-b88d-13973b43b5e7@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

About the test and debug mode, we had that kind of conversation in https://github.com/openjdk/jdk/pull/25958
Windows and Macosx were likely to timeout in debug builds, Linux was OK for me.  Not sure if the inlining requests here affect that much, will be interesting to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3035981114

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 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 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 rrich at openjdk.org  Mon Jul  7 07:44:39 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 07:44:39 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <aBNFHmMzCn1WfT1rlxSCLBegorJV-tSCFvJsjnorB34=.5fd6a0e7-52c5-4c0c-bd0f-e5d07ae865fb@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

> About the test and debug mode, we had that kind of conversation in #25958 Windows and Macosx were likely to timeout in debug builds, Linux was OK for me. Not sure if the inlining requests here affect that much, will be interesting to see.

You got timeouts likely because the test searched for eliminated locking in the thread dumps in an endless loop but lock elimination has failed (very early) due to unfavorable inlining.

Inlining depends on timing because jit compilation runs asynchronously in the background. It affects inlining if a call target is already compiled into a big nmethod (see `failed to inline: already compiled into a big method` above). Calls critical for lock elimination will still be inlined because of the `CompileCommand` inlining requests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043813314

From rrich at openjdk.org  Mon Jul  7 07:44:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 07:44:40 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <afue0AhqPG1d2N4F1-5JcGHyLYT9vS1f3LfNRaIWof0=.29656611-45f1-44e7-be8a-319f06e379a1@github.com>
 <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com>
 <S-VKP4aK-iWohcwGJyOsHaF69CQrVcyoJkjC_1X8jaE=.f0085919-2c75-4f49-978d-80eaa5a63c5f@github.com>
 <SkmOLa3SlOLJMntyaNg-3Pn5RCbJDpuvgojL1_gklhE=.449a9a69-5da7-4c69-8a6a-613f1d702f9b@github.com>
Message-ID: <tjJT49xXHwBZsmm1yq83Q2JUrkgCXQZ25hB_k9kDeFU=.ed3db8bc-8d64-42bd-bfd4-3956b83ba6b6@github.com>

On Fri, 4 Jul 2025 08:11:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms.

Local testing was good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043828120

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 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 kevinw at openjdk.org  Mon Jul  7 09:09:31 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Jul 2025 09:09:31 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency [v2]
In-Reply-To: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
Message-ID: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com>

> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
> Tests should retry some small number of times, rerunning the jstat tool to recapture data.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  modifier order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26094/files
  - new: https://git.openjdk.org/jdk/pull/26094/files/219e93ce..274b7c62

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

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

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

From kevinw at openjdk.org  Mon Jul  7 09:09:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Jul 2025 09:09:32 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency [v2]
In-Reply-To: <XFLoME_VcmlS-rZXSnTZMTsPjFIRWHawajqtODchbbI=.12f35f13-3d85-459c-be02-d60975fbc503@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
 <XFLoME_VcmlS-rZXSnTZMTsPjFIRWHawajqtODchbbI=.12f35f13-3d85-459c-be02-d60975fbc503@github.com>
Message-ID: <VJUig4q5g-hxktD4_esEcXnLqZWwt-wLSPrfjSzBGOA=.b5cd11ff-c853-48f1-b6ac-a7da6a7f419c@github.com>

On Thu, 3 Jul 2025 16:51:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modifier order
>
> test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatTool.java line 46:
> 
>> 44:         for (int i = 1; i <= TRIES; i++) {
>> 45:             try {
>> 46:                 results = measure();
> 
> Might be the 'measure' and 'assertConsistency' might be changed to from 'public' to 'package-local` if they are not needed to be used by tests directly.

Thanks -

I left GarbageProducerTest with individual calls to measure() and assertConsistency().
This could be a small window for the same problem again.  It's not one where I think we have ever seen the problem before.
But it looks like that test's run() method tries to avoid a problem already, it tests if a collection has NOT happened during gathering, and only calls assertConsistency() if that's the case.

But I will update additionally to put a couple of modifiers in the traditional blessed order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26094#discussion_r2189438383

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 mbaesken at openjdk.org  Mon Jul  7 12:26:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 7 Jul 2025 12:26:49 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is
 not a valid value
Message-ID: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>

When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).


jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 

/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
    #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
    #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
    #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
    #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
    #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
    #5 0x1096f6094 in Thread::call_run() thread.cpp:231
    #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
    #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)

vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java

/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
    #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
    #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
    #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
    #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
    #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
    #5 0x1054f6094 in Thread::call_run() thread.cpp:231
    #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
    #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)


So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  test test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .

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

Commit messages:
 - JDK-8351487

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

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

From rrich at openjdk.org  Mon Jul  7 13:23:46 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 13:23:46 GMT
Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails
 because of unstable inlining [v2]
In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
 <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com>
Message-ID: <HWGh_N895W3yaN58d5RuY2Faam-y1PFlcjJ0_2GhefE=.fe327f62-07cc-452b-8369-63f13db6aae7@github.com>

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

Thanks for the reviews and feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3045085386

From rrich at openjdk.org  Mon Jul  7 13:23:47 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 7 Jul 2025 13:23:47 GMT
Subject: Integrated: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java
 fails because of unstable inlining
In-Reply-To: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
References: <Zceb9446-NHWJrPNcEuAFqLVLZTKGZkK78xfEUMMK_o=.cd41af25-37cf-451b-bfaa-1f44f032b9e0@github.com>
Message-ID: <KL2hCcdf0PhXI4_hqW8DO3K3H8YGPqlohzFV7theWMQ=.9d0a5ffb-6198-4eee-8e49-19854b773d57@github.com>

On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
> 
> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
> 
> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
> 
> Failed inlining on x86_64 with TieredCompilation disabled:
> 
> 
> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
> 
> [...]
> 
> STDOUT:
> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
> 
> [...]

This pull request has now been integrated.

Changeset: fea73c1d
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining

Reviewed-by: alanb, mdoerr, lmesnik

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

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

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 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 cjplummer at openjdk.org  Mon Jul  7 18:52:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 18:52:45 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
Message-ID: <oOhEgXPgSlv9M2z59qwWlqzPUQcvrx0XZgrIZIJwXBo=.8554e8f2-3bb8-4f82-abe9-d4db5b7d4a22@github.com>

On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
>> 
>> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
>> 
>> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   startLocalDebugee renamed to startDebugee

Thanks for the reviews Leonid, Serguei, and Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/25887#issuecomment-3046201976

From cjplummer at openjdk.org  Mon Jul  7 18:52:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 18:52:45 GMT
Subject: Integrated: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees
In-Reply-To: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
Message-ID: <_RJ2DRZKPcSOvEVK520Ii5mKzHyyL1KSKlD1qAYXfiM=.2e813b33-f6d0-409b-860f-1924b42aa3f5@github.com>

On Wed, 18 Jun 2025 22:13:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
> 
> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
> 
> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.

This pull request has now been integrated.

Changeset: 39c9de2a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39c9de2acea0537335230b1d1db606d90348bdb6
Stats:     105 lines in 19 files changed: 0 ins; 15 del; 90 mod

8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees

Reviewed-by: lmesnik, sspitsyn, amenkov

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

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

From cjplummer at openjdk.org  Mon Jul  7 19:30:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 19:30:40 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which
 is not a valid value
In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
Message-ID: <6TWqCbcc92wo7tD39KGy4o5m4dxNBIS8gX73HCssQ6E=.f777306b-8469-4864-b5ac-64ccc011a29c@github.com>

On Mon, 7 Jul 2025 12:21:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).
> 
> 
> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
>     #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
>     #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
>     #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1096f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
>     #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
>     #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
>     #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1054f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .
> Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan  is probab...

This is somewhat of an odd situation. SetVerboseFlag() says the argument type is an enum, but it treats it like an int and does error checking to make sure it one of the enum values. If ubsan dug a little deeper to see how the argument is handled, it would see that and not complain.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 38:

> 36:  * COMMENTS
> 37:  *
> 38:  * @requires !vm.ubsan

Needs an @comment

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java line 37:

> 35:  * COMMENTS
> 36:  *
> 37:  * @requires !vm.ubsan

Needs an @comment

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26159#pullrequestreview-2995047256
PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2190865703
PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2190866138

From cjplummer at openjdk.org  Mon Jul  7 20:30:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Jul 2025 20:30:39 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency [v2]
In-Reply-To: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
 <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com>
Message-ID: <iJ_TzsmMjjeUwnr4flWuRletkwQkDK4LgsnY6Eb1qPQ=.9d682062-40e4-4325-9e4d-9df6d3df8600@github.com>

On Mon, 7 Jul 2025 09:09:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
>> Tests should retry some small number of times, rerunning the jstat tool to recapture data.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modifier order

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26094#pullrequestreview-2995185649

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 amenkov at openjdk.org  Tue Jul  8 00:09:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 00:09:13 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
Message-ID: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>

The fix updates several tests ASAN complains about.
Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN.
Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here.

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

Commit messages:
 - fix

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

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

From jwaters at openjdk.org  Tue Jul  8 01:30:08 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 01:30:08 GMT
Subject: Integrated: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <-TK5ziYVLfu1MOHf70wFHbnT7bhXhOq0mXLI4HOphJE=.37fea4b0-0383-4e9d-baf6-60f437ac92d1@github.com>

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

This pull request has now been integrated.

Changeset: 563a3358
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/563a3358f6f1ecff816318cbb32376487365c1fa
Stats:     8 lines in 4 files changed: 2 ins; 3 del; 3 mod

8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage

Reviewed-by: cjplummer, asemenyuk, almatvee

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

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

From cjplummer at openjdk.org  Tue Jul  8 05:01:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Jul 2025 05:01:47 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
In-Reply-To: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
References: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
Message-ID: <KH_dajHyZcFzK9qWjiJnvrim1yFC9ayOuiX7G6zgNOg=.95dc4423-1635-44e9-9686-e943074fb3bb@github.com>

On Tue, 8 Jul 2025 00:01:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates several tests ASAN complains about.
> Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN.
> Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java line 41:

> 39:  *
> 40:  * @comment the test intentionally passes bad argument to the function to verify the functionality,
> 41:             it causes false positive from ASAN lib

Suggestion:

 * @comment The test intentionally passes a bad argument to the function to verify error checking,
            which causes a false positive from the ASAN lib


Same comment for the other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26176#discussion_r2191478686

From kevinw at openjdk.org  Tue Jul  8 06:40:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Jul 2025 06:40:46 GMT
Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency [v2]
In-Reply-To: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
 <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com>
Message-ID: <hhIX03EUtNsAjaXb8yZr6tD6DtdMfJ2KL6vJUZa3tDM=.ad2ec8ca-4019-4a87-a274-a82304e9a293@github.com>

On Mon, 7 Jul 2025 09:09:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
>> Tests should retry some small number of times, rerunning the jstat tool to recapture data.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modifier order

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26094#issuecomment-3047558159

From kevinw at openjdk.org  Tue Jul  8 06:40:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Jul 2025 06:40:48 GMT
Subject: Integrated: 8305567: serviceability/tmtools/jstat/GcTest01.java failed
 utils.JstatGcResults.assertConsistency
In-Reply-To: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
References: <rx4p-kbzS7QJ868GDuFPNcnREPLaYzAJ3Z0-vlS6gp0=.8d6679b8-2e13-43a3-92fd-9434d748af46@github.com>
Message-ID: <jG2LB1NAfKql-wyUXaOd8hovjukCD9Kh8uBc3DUS8m0=.d0889cfb-d549-4751-bb6a-c2d926dd998b@github.com>

On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
> Tests should retry some small number of times, rerunning the jstat tool to recapture data.

This pull request has now been integrated.

Changeset: 310ef856
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/310ef85667bdba3f984cb6327aee71cfaf91458b
Stats:     101 lines in 10 files changed: 60 ins; 12 del; 29 mod

8305567: serviceability/tmtools/jstat/GcTest01.java failed  utils.JstatGcResults.assertConsistency

Reviewed-by: cjplummer, lmesnik

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

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

From mbaesken at openjdk.org  Tue Jul  8 08:27:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Jul 2025 08:27:21 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which
 is not a valid value [v2]
In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
Message-ID: <FsR9MJ6dM9gCh6QaumaYErTBFKHbnl1ikcMYnq0k7Gk=.36a4541f-73b8-4fcd-b1b4-537e5246a699@github.com>

> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).
> 
> 
> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
>     #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
>     #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
>     #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1096f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
>     #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
>     #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
>     #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1054f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .
> Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan  is probab...

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26159/files
  - new: https://git.openjdk.org/jdk/pull/26159/files/a346557b..a0ca0ddc

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

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

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

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 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 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 amenkov at openjdk.org  Tue Jul  8 19:37:25 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 19:37:25 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
 [v2]
In-Reply-To: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
References: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
Message-ID: <RegeqLJhcqQT_i-vKt7r-Fty87Rs-des5vvN5eotEwk=.7fe3643b-ffe1-4547-9f44-c722f750ada5@github.com>

> The fix updates several tests ASAN complains about.
> Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN.
> Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java
  
  Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26176/files
  - new: https://git.openjdk.org/jdk/pull/26176/files/270e1db4..a6480938

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

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

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

From amenkov at openjdk.org  Tue Jul  8 19:41:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 19:41:26 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
 [v3]
In-Reply-To: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
References: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
Message-ID: <AOmlFc09n37vfSeqkiDBG0iZ14ZmsDX3VGknt8vnnsQ=.76c883fe-ccc9-450f-8b4c-ab30155a58dc@github.com>

> The fix updates several tests ASAN complains about.
> Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN.
> Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26176/files
  - new: https://git.openjdk.org/jdk/pull/26176/files/a6480938..337fef05

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

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

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

From amenkov at openjdk.org  Tue Jul  8 19:41:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 19:41:26 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
 [v3]
In-Reply-To: <KH_dajHyZcFzK9qWjiJnvrim1yFC9ayOuiX7G6zgNOg=.95dc4423-1635-44e9-9686-e943074fb3bb@github.com>
References: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
 <KH_dajHyZcFzK9qWjiJnvrim1yFC9ayOuiX7G6zgNOg=.95dc4423-1635-44e9-9686-e943074fb3bb@github.com>
Message-ID: <tDOTH0gUvmJAb91YM6SiLtJ5_Oe8QVvsR4FXuMdGV1k=.47cbdb87-8d9d-4113-9997-79d49a863948@github.com>

On Tue, 8 Jul 2025 04:59:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java line 41:
> 
>> 39:  *
>> 40:  * @comment the test intentionally passes bad argument to the function to verify the functionality,
>> 41:             it causes false positive from ASAN lib
> 
> Suggestion:
> 
>  * @comment The test intentionally passes a bad argument to the function to verify error checking,
>             which causes a false positive from the ASAN lib
> 
> 
> Same comment for the other tests.

Updated as suggested

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26176#discussion_r2193308770

From amenkov at openjdk.org  Tue Jul  8 19:49:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 8 Jul 2025 19:49:40 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which
 is not a valid value [v2]
In-Reply-To: <FsR9MJ6dM9gCh6QaumaYErTBFKHbnl1ikcMYnq0k7Gk=.36a4541f-73b8-4fcd-b1b4-537e5246a699@github.com>
References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
 <FsR9MJ6dM9gCh6QaumaYErTBFKHbnl1ikcMYnq0k7Gk=.36a4541f-73b8-4fcd-b1b4-537e5246a699@github.com>
Message-ID: <FkWV7nnetReZRNJwMi_ZFi5ts7eJd_NEaJU321wquIs=.208e3b72-8687-4543-87ee-ba3d1bddb029@github.com>

On Tue, 8 Jul 2025 08:27:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).
>> 
>> 
>> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 
>> 
>> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
>>     #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
>>     #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
>>     #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>>     #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>>     #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>>     #5 0x1096f6094 in Thread::call_run() thread.cpp:231
>>     #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java
>> 
>> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
>>     #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
>>     #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
>>     #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>>     #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>>     #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>>     #5 0x1054f6094 in Thread::call_run() thread.cpp:231
>>     #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .
>> Please note that jvmti.h is shipped so adding...
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 39:

> 37:  *
> 38:  * @requires !vm.ubsan
> 39:  * @comment We test with arguments out of scope of the jvmti enums, this causes

Could you please place the comments before `@requires` tags

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193321360

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 cjplummer at openjdk.org  Tue Jul  8 22:14:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Jul 2025 22:14:39 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which
 is not a valid value [v2]
In-Reply-To: <FsR9MJ6dM9gCh6QaumaYErTBFKHbnl1ikcMYnq0k7Gk=.36a4541f-73b8-4fcd-b1b4-537e5246a699@github.com>
References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
 <FsR9MJ6dM9gCh6QaumaYErTBFKHbnl1ikcMYnq0k7Gk=.36a4541f-73b8-4fcd-b1b4-537e5246a699@github.com>
Message-ID: <jZrGdGSvfnsiyCHhmHOL4iZ-xFJ8lP1t5FtcogNxsEI=.57a85636-cef0-4f68-8855-1a02aec8eb21@github.com>

On Tue, 8 Jul 2025 08:27:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).
>> 
>> 
>> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 
>> 
>> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
>>     #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
>>     #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
>>     #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>>     #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>>     #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>>     #5 0x1096f6094 in Thread::call_run() thread.cpp:231
>>     #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java
>> 
>> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
>>     #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
>>     #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
>>     #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>>     #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>>     #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>>     #5 0x1054f6094 in Thread::call_run() thread.cpp:231
>>     #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
>> 
>> 
>> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .
>> Please note that jvmti.h is shipped so adding...
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 40:

> 38:  * @requires !vm.ubsan
> 39:  * @comment We test with arguments out of scope of the jvmti enums, this causes
> 40:  *          ubsan issues.

Suggestion:

 * @comment We test with arguments out of scope of the jvmti enums, which causes
 *          ubsan issues.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java line 39:

> 37:  * @requires !vm.ubsan
> 38:  * @comment We test with arguments out of scope of the jvmti enums, this causes
> 39:  *          ubsan issues.

Suggestion:

 * @comment We test with arguments out of scope of the jvmti enums, which causes
 *          ubsan issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193521845
PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193522041

From cjplummer at openjdk.org  Tue Jul  8 22:29:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Jul 2025 22:29:39 GMT
Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
 [v3]
In-Reply-To: <AOmlFc09n37vfSeqkiDBG0iZ14ZmsDX3VGknt8vnnsQ=.76c883fe-ccc9-450f-8b4c-ab30155a58dc@github.com>
References: <Lfiqm-cmFjupDb6P78LW3kPsOeISMjmsAxQTqLT6o3c=.ade93dd6-65dc-4fc9-86af-f889e4212e8d@github.com>
 <AOmlFc09n37vfSeqkiDBG0iZ14ZmsDX3VGknt8vnnsQ=.76c883fe-ccc9-450f-8b4c-ab30155a58dc@github.com>
Message-ID: <DuUB_7j6ukLTsrVqrb4Q8uzvDZv1GIuWJOb12bwc1So=.4bfbc6dc-d04e-4fc7-862f-864fcf075fb6@github.com>

On Tue, 8 Jul 2025 19:41:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates several tests ASAN complains about.
>> Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN.
>> Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26176#pullrequestreview-2999240093

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 mbaesken at openjdk.org  Wed Jul  9 07:05:28 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Jul 2025 07:05:28 GMT
Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which
 is not a valid value [v3]
In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com>
Message-ID: <CfRW3_t4LcOntjaFm0GMUkkmg8cESRzaXxM8OHDtcKk=.595b8f1b-c588-459b-b924-07c11b0cb56b@github.com>

> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64).
> 
> 
> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java 
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag'
>     #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645
>     #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49
>     #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1096f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java
> 
> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError'
>     #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640
>     #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50
>     #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151
>     #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89
>     #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776
>     #5 0x1054f6094 in Thread::call_run() thread.cpp:231
>     #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601
>     #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ;  but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ;  so better exclude those tests from ubsan checking .
> Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan  is probab...

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust and move comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26159/files
  - new: https://git.openjdk.org/jdk/pull/26159/files/a0ca0ddc..33b057c5

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

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

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

From rrich at openjdk.org  Wed Jul  9 07:50:49 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 9 Jul 2025 07:50:49 GMT
Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java
 fails because of unstable inlining
Message-ID: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>

This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.

Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

Thanks, Richard.

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

Commit messages:
 - Backport fea73c1d40441561a246f2a09a739367cfc197ea

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

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

From mdoerr at openjdk.org  Wed Jul  9 07:50:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Jul 2025 07:50:50 GMT
Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java
 fails because of unstable inlining
In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
Message-ID: <e5XosXeJhgAYcWIowegj7r_Shnl3jsSnOMtHrTGxtW8=.696c7e24-0ba6-43cc-be77-fc5cec131810@github.com>

On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.
> 
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
> 
> Thanks, Richard.

This testfix backport makes sense.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-2996597109

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 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 kevinw at openjdk.org  Wed Jul  9 08:15:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Jul 2025 08:15:38 GMT
Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java
 fails because of unstable inlining
In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com>
Message-ID: <bzR8VjJoBQzoaQ6K6EVwYcTWN07omjPFQHupqV5q7Bo=.a39c5aa6-9f2b-4108-999e-1853539f8af2@github.com>

On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik.
> 
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
> 
> Thanks, Richard.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-3000513381

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 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 kevinw at openjdk.org  Wed Jul  9 13:00:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Jul 2025 13:00:48 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object [v5]
In-Reply-To: <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <hBgzWQ4YcQzYOOfqsBedTn8z7JSjQLj8vrpXR0INt94=.3ee823fb-f5d2-4d74-bff9-81af15a8b16d@github.com>
Message-ID: <xcOems_zSPNX_cDaxqmj371JdxzDznAkdM7qjXhJ7BY=.e89737ef-056c-44d1-8d92-0f0a21700337@github.com>

On Tue, 1 Jul 2025 08:52:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further doc update
>  - Test udpate (listIterator)

CSR is approved, will need to get re-review or additional review 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3052582311