From syan at openjdk.org  Sat Nov  1 02:08:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 1 Nov 2025 02:08:19 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
Message-ID: <JxgEtO9ZrWSQ7aC_QkoSZnYrre5ABfsqzE-HUb6PblE=.aaf0cda0-0411-40f2-99c7-f34730f893a0@github.com>

On Fri, 31 Oct 2025 03:04:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add log.display("Provoking GC");

Thanks for the suggestions and reviews @https://github.com/lmesnik @https://github.com/plummercj @https://github.com/sspitsyn

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

PR Comment: https://git.openjdk.org/jdk/pull/28011#issuecomment-3475438561

From syan at openjdk.org  Sat Nov  1 02:08:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 1 Nov 2025 02:08:20 GMT
Subject: Integrated: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking
 gc for nsk/jvmti tests
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <o8VpeBn2N-rPEYHomZXsHepv062pu9UDvEjE-bNRKW8=.643017ed-dc0c-417c-a5b4-e449e93785d8@github.com>

On Tue, 28 Oct 2025 06:22:14 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

This pull request has now been integrated.

Changeset: 54fe5021
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54fe50210efe9ae6fad225b815cfdeb16c868115
Stats:     299 lines in 27 files changed: 33 ins; 234 del; 32 mod

8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc for nsk/jvmti tests

Reviewed-by: cjplummer, lmesnik, sspitsyn

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

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

From ysuenaga at openjdk.org  Sat Nov  1 02:36:22 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 02:36:22 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol in
 function ending in call [v3]
In-Reply-To: <L5Pi30D5_FYvTfRqMvz_8WOLRkbWI2rqlFaYyMqinp4=.db448e4a-ff93-4e17-970c-168d3c347f58@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
 <L5Pi30D5_FYvTfRqMvz_8WOLRkbWI2rqlFaYyMqinp4=.db448e4a-ff93-4e17-970c-168d3c347f58@github.com>
Message-ID: <Oit4CHCFUZnOLdWU6nZEVnn6basC3Fkj5wLvU4PM1pA=.c37c3440-f258-483c-9435-3316ad6d2f03@github.com>

On Thu, 30 Oct 2025 13:32:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735 __GI_abort + 0x8b
>> 0x00007f50e1e01f33 ????????
>> 
>> 
>> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
>> 
>> 
>> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
>> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
>> => 0x00007f50e1e01f33: nop
>> End of assembler dump.
>> 
>> 
>> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
>> 
>> After this PR, you can see the right symbol as following:
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735      __GI_abort + 0x8b
>> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comment about RIP-1 fallback handling

Thank you both for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3475467698

From ysuenaga at openjdk.org  Sat Nov  1 02:36:23 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 02:36:23 GMT
Subject: Integrated: 8369994: Mixed mode jhsdb jstack cannot resolve symbol in
 function ending in call
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <75W6AM4vr_GlY8SLlZ_f85u_lWbkpf2d5ZkB2zWHpgM=.cceb0531-a01f-4eca-b2b0-3a5a6513457b@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

This pull request has now been integrated.

Changeset: d2260236
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d226023643f90027a8980d161ec6d423887ae3ce
Stats:     40 lines in 1 file changed: 26 ins; 4 del; 10 mod

8369994: Mixed mode jhsdb jstack cannot resolve symbol in function ending in call

Reviewed-by: kevinw, cjplummer

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

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

From ysuenaga at openjdk.org  Sat Nov  1 02:39:52 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 02:39:52 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v11]
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <TD7PBn5CaNaNuk0UhRMgqC5mFRcJNe5N4xFHh-qB12g=.1e9664a6-587f-4041-a115-b1770dd06d3a@github.com>

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments in isValidFrame method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27885/files
  - new: https://git.openjdk.org/jdk/pull/27885/files/3e0bfd09..ec5d0e2c

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

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

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

From ysuenaga at openjdk.org  Sat Nov  1 02:39:56 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 02:39:56 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v10]
In-Reply-To: <jEz8UNPammejHXllXcv0k20rRJWgeNDtBqxqo7R20SE=.39b6b0fb-b30e-4259-b575-86cf6956ced8@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <PllNRAtOZqTVelqL4w8XQePKbWAakkv1mCHtSYuP7M8=.00605fc9-1981-444e-8492-dec0c2014fda@github.com>
 <jEz8UNPammejHXllXcv0k20rRJWgeNDtBqxqo7R20SE=.39b6b0fb-b30e-4259-b575-86cf6956ced8@github.com>
Message-ID: <riNU_LoIObi5r0IeEsfHPEtHUYZF5dfbFxeh110NyxY=.e6453188-a39e-41ee-96aa-7f3de726c0a1@github.com>

On Fri, 31 Oct 2025 17:33:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stderrShouldBeEmptyIgnoreVMWarnings
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java line 97:
> 
>> 95: 
>> 96:    private boolean isValidFrame(Address nextCFA, boolean isNative) {
>> 97:      // CFA should not be null even if it is Java frame.
> 
> This comment means a Java interpreter frame need not have a different CFA/frame pointer?
> 
> "native" means we found DWARF.  Non-native means Java interpreted or Java compiled.
> Java frames just need a non-null CFA.
> 
> // CFA should never be null.
> // nextCFA must be greater than current CFA, if frame is native.
> // Java interpreter frames can share the CFA (frame pointer).

Exactly. I updated the comment. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2483054834

From ysuenaga at openjdk.org  Sat Nov  1 03:20:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 03:20:49 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v11]
In-Reply-To: <TD7PBn5CaNaNuk0UhRMgqC5mFRcJNe5N4xFHh-qB12g=.1e9664a6-587f-4041-a115-b1770dd06d3a@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <TD7PBn5CaNaNuk0UhRMgqC5mFRcJNe5N4xFHh-qB12g=.1e9664a6-587f-4041-a115-b1770dd06d3a@github.com>
Message-ID: <srRJNqKEMLWJeiearEyRQNWOixTcDwB9ViQqqRZxf-o=.a6499ee6-9976-4294-a7eb-619156a663f8@github.com>

On Sat, 1 Nov 2025 02:39:52 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments in isValidFrame method

I resolved merge confliction, and it passed all of serviceability/sa tests on Linux AMD64.

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3475560622

From ysuenaga at openjdk.org  Sat Nov  1 03:20:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 1 Nov 2025 03:20:49 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v12]
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into jhsdb-jstack-bp
 - Improve comments in isValidFrame method
 - Use stderrShouldBeEmptyIgnoreVMWarnings
 - TestJhsdbJstackMixedWithXComp.java should be run on Linux AMD64 only
 - Respect RSP to parse DWARF
 - Revert testcase changes
 - Fix imports
 - Update testcase
 - Update testcase
 - Add glibc version check to TestJhsdbJstackMixedWithXComp.java
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d2260236...eb2f0ab0

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

Changes: https://git.openjdk.org/jdk/pull/27885/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27885&range=11
  Stats: 248 lines in 6 files changed: 182 ins; 10 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/27885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27885/head:pull/27885

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

From kbarrett at openjdk.org  Sat Nov  1 07:34:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 1 Nov 2025 07:34:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <4Yh4KeUItjdDYihe9d1u66tBROofb0pRLDKIdhw-XZo=.cf383363-c963-4871-941d-5e358f74c048@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
 <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
 <6u0Ia6A2xQnv51Ti0Jchg6rnncfRRvtK5oGS963CeIA=.bc9c1481-60ad-443d-923b-dc86277dbb14@github.com>
 <4Yh4KeUItjdDYihe9d1u66tBROofb0pRLDKIdhw-XZo=.cf383363-c963-4871-941d-5e358f74c048@github.com>
Message-ID: <lys0bB9p3seBZOSTmK56Jn2ci_KLhN0OmXM0kPm1pbI=.1de770da-c33a-4077-8ca2-a70f5100623e@github.com>

On Mon, 27 Oct 2025 08:24:41 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> We (you and me, @fweimer-rh) discussed this a couple of years ago:
>> https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/082324.html
>> 
>> Quoting from here:
>> https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/083142.html
>> 
>> "
>> Empirically, a recursive initialization attempt doesn't make any attempt to
>> throw. Rather, it blocks forever waiting for a futex signal from a thread that
>> succeeds in the initialization. Which of course will never come.
>> 
>> And that makes sense, now that I've looked at the code.
>> 
>> In __cxa_guard_acquire, with _GLIBCXX_USE_FUTEX, if the guard indicates
>> initialization hasn't yet been completed, then it goes into a while loop.
>> This while loop tries to claim initialization.  Failing that, it checks
>> whether initialization is complete.  Failing that, it does a SYS_futex
>> syscall, waiting for some other thread to perform the initialization.  There's
>> nothing there to check for recursion.
>> 
>> throw_recursive_init_exception is only called if single-threaded (either by
>> configuration or at runtime).
>> "
>> 
>> It doesn't look like there have been any relevant changes in that area since
>> then. So I think there is still not a problem here.
>
> @kimbarrett Sorry, I forgot about the old thread. You can get the exception in a single-threaded scenario, something like this:
> 
> 
> struct S {
>   S() {
>     static S s;
>     *this = s;
>   }
> } global;
> 
> 
> Maybe the actual rule is more like this?
> 
>> Functions that may throw exceptions must not be used, unless individual calls ensure that these particular invocations cannot throw exceptions.

Recursively entering a block-scoped static is undefined behavior. That some
configurations of glibc might throw an exception in that situation (even
despite the caller being compiled with exceptions disabled) seems like a
mistake in glibc, and not really our concern. Our code should avoid such a
situation because it's UB, regardless of whether the actual behavior involves
exceptions or nasal demons.

The exception only gets thrown when the application is single-threaded. But at
least the common way to start java (via the launcher) is already
multi-threaded on entry to Threads::create_vm(). So that case doesn't normally
apply to us anyway.

Also, I really don't think we want people trying to figure out whether a
particular call might or might not throw (neither when writing nor when
reading code).

So no, I don't think the proposed rule should be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2483178071

From aph at openjdk.org  Sat Nov  1 09:02:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 1 Nov 2025 09:02:11 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
Message-ID: <XUdnUlDYEfLJi6qzGosHzp_9tKno0o4RX4E92Q-N4CY=.ad2727a6-0beb-4565-8b07-dca0c532d82e@github.com>

On Tue, 28 Oct 2025 23:18:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a

Marked as reviewed by aph (Reviewer).

But I'm not going to push `SafeFetch` any further. I've said my piece.

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

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3407023975
PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3476011689

From aph at openjdk.org  Sat Nov  1 09:05:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 1 Nov 2025 09:05:08 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
 <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
Message-ID: <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>

On Thu, 30 Oct 2025 21:10:18 GMT, Dean Long <dlong at openjdk.org> wrote:

> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable. Adding a SafeFetch here might cause a regression.

Sure, but 2 things:
Loom doesn't meed post-call NOPs as much as it used to.
We could fairly easily make SafeFetch much faster than it is, if needs be.
But anyway, I approved this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3476017720

From kevinw at openjdk.org  Sat Nov  1 09:59:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 1 Nov 2025 09:59:03 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v12]
In-Reply-To: <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
Message-ID: <ZCoe-atAY3OmAGTqTKcw2y0UNKbgTITRV5xxnCDp2Aw=.b9c2a367-31da-4b4e-999c-cb4778307a35@github.com>

On Sat, 1 Nov 2025 03:20:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into jhsdb-jstack-bp
>  - Improve comments in isValidFrame method
>  - Use stderrShouldBeEmptyIgnoreVMWarnings
>  - TestJhsdbJstackMixedWithXComp.java should be run on Linux AMD64 only
>  - Respect RSP to parse DWARF
>  - Revert testcase changes
>  - Fix imports
>  - Update testcase
>  - Update testcase
>  - Add glibc version check to TestJhsdbJstackMixedWithXComp.java
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d2260236...eb2f0ab0

Thanks, spent quite a while going over this yesterday and think it's good.
Yes was waiting for the conflict with 8369994, that looks like it merged in OK. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27885#pullrequestreview-3407206806

From kvn at openjdk.org  Sat Nov  1 15:06:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 1 Nov 2025 15:06:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <HQCNu464FkSX8tHp5jE9WYXh0Fl7KLXONAbQIE7hOWg=.f047cff1-b02c-44dd-ac9d-c25d3ce4a6c7@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Approved

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3407565447

From duke at openjdk.org  Sat Nov  1 16:00:22 2025
From: duke at openjdk.org (duke)
Date: Sat, 1 Nov 2025 16:00:22 GMT
Subject: Withdrawn: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <toUHWUnh99ZDRi1tVoWl0dHx_A4yLh8BGTQ6_kbGVKc=.75d986e6-febb-44b5-8ed5-272da5a82fb5@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

This pull request has been closed without being integrated.

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

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

From ysuenaga at openjdk.org  Sun Nov  2 06:32:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 2 Nov 2025 06:32:02 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <O2aK1E_HNMxwpp_DxG1cKOn1sdEvfvnmNOCS-e6_4hs=.341df00c-1f5d-4be8-88cc-458c312cdc25@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <O2aK1E_HNMxwpp_DxG1cKOn1sdEvfvnmNOCS-e6_4hs=.341df00c-1f5d-4be8-88cc-458c312cdc25@github.com>
Message-ID: <UmioS0yvQFFDBnm2zjogmjh-CraUa50ZVxNf4DePsjw=.3b2e32bd-1c4f-4e8b-8ace-39e978fcd33e@github.com>

On Wed, 22 Oct 2025 21:00:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> Changes look good. Thanks for fixing this.

@plummercj Can you approve again this PR? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3477496462

From kbarrett at openjdk.org  Sun Nov  2 07:05:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 2 Nov 2025 07:05:24 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ZOCT202NaByvSrndotd5xVCJT-GrL7Ngo3JhAp-4Y6s=.e8a98f16-d6a4-47eb-971c-f817a32ae361@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Thanks for reviews and comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3477511265

From kbarrett at openjdk.org  Sun Nov  2 07:05:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 2 Nov 2025 07:05:26 GMT
Subject: Integrated: 8369186: HotSpot Style Guide should permit some uses of
 the C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <xgFGfVomszjUfS2ZUHNO841ejlAsV12Vcc0ezo8ZwGA=.0211f02f-1b7a-44a9-a54c-0fdfab8667a3@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

This pull request has now been integrated.

Changeset: e8a1a870
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8a1a8707ee6192c85ac62a2a51c815e07613c38
Stats:     670 lines in 68 files changed: 430 ins; 134 del; 106 mod

8369186: HotSpot Style Guide should permit some uses of the C++ Standard Library

Reviewed-by: jrose, lkorinth, iwalulya, kvn, stefank

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

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

From stooke at openjdk.org  Mon Nov  3 02:23:31 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 3 Nov 2025 02:23:31 GMT
Subject: Integrated: 8370578: SystemMapTest.java#normal fails intermittendly on
 macOS aarch64
In-Reply-To: <BbFx0HCE0Ep3nGhIfVeD4JurEyjjfR__-oxfxj00dbg=.7b07c8aa-f319-451e-b2f0-7993a6c8ce90@github.com>
References: <BbFx0HCE0Ep3nGhIfVeD4JurEyjjfR__-oxfxj00dbg=.7b07c8aa-f319-451e-b2f0-7993a6c8ce90@github.com>
Message-ID: <GRxfrFDtrBPkxU8bhNkP5pHUvEUZt4a50o2cZVQ-zn4=.299a771b-15c6-49a0-980a-8a3355d6f5a3@github.com>

On Tue, 28 Oct 2025 20:28:10 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This PR addresses [JDK-8370578](https://bugs.openjdk.org/browse/JDK-8370578)  
> 
> Under certain circumstances, OpenJDK on macOS maps the hsperf segment private instead of shared; one of those cases is hit during the tier1 tests, which test for that.  
> 
> This PR allows for shared or private mapping; the purpose of the intermittently failing test is to test System.map implementation, not JDK internals.

This pull request has now been integrated.

Changeset: 05efc1fa
Author:    Simon Tooke <stooke at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05efc1fa991c3fd895bf2f7c7d9e7916692b98e6
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8370578: SystemMapTest.java#normal fails intermittendly on macOS aarch64

Reviewed-by: cjplummer, sspitsyn, stuefe

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

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

From duke at openjdk.org  Mon Nov  3 02:25:17 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Mon, 3 Nov 2025 02:25:17 GMT
Subject: Integrated: 8370974: Command-line Hotspot debugger tests fail on
 Windows AArch64
In-Reply-To: <xGQDf2yuE3STv_1kegmaTS1ixrIzANIf1bN1z-vs9qU=.10092575-76d9-4b5e-8aa8-0637dabda7a9@github.com>
References: <xGQDf2yuE3STv_1kegmaTS1ixrIzANIf1bN1z-vs9qU=.10092575-76d9-4b5e-8aa8-0637dabda7a9@github.com>
Message-ID: <UC96XyjrTVU09ZTydkbiWOEds4U2SRoBYSX9aVEjgfU=.24079719-ada1-4750-8264-d8c24df29db0@github.com>

On Fri, 31 Oct 2025 01:03:09 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> The registers are all shown to have the value 0. The addThreads method needs to fill the array of registers with values from the native OS CONTEXT. The clhsdb* tests now pass with this change.

This pull request has now been integrated.

Changeset: 4cfabd60
Author:    Saint Wesonga <saint.wesonga at microsoft.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cfabd605c42494db4ca4078344d32abc951a9ae
Stats:     44 lines in 1 file changed: 44 ins; 0 del; 0 mod

8370974: Command-line Hotspot debugger tests fail on Windows AArch64

Reviewed-by: dholmes, cjplummer

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

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

From cjplummer at openjdk.org  Mon Nov  3 06:09:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 3 Nov 2025 06:09:06 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v12]
In-Reply-To: <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
Message-ID: <zxdEUESLmfihrdtOp2lqdW3ZFpgWl199e2PGLwtqzKw=.38215f80-7578-4bbc-82cb-386e4145054e@github.com>

On Sat, 1 Nov 2025 03:20:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into jhsdb-jstack-bp
>  - Improve comments in isValidFrame method
>  - Use stderrShouldBeEmptyIgnoreVMWarnings
>  - TestJhsdbJstackMixedWithXComp.java should be run on Linux AMD64 only
>  - Respect RSP to parse DWARF
>  - Revert testcase changes
>  - Fix imports
>  - Update testcase
>  - Update testcase
>  - Add glibc version check to TestJhsdbJstackMixedWithXComp.java
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d2260236...eb2f0ab0

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27885#pullrequestreview-3409513824

From duke at openjdk.org  Mon Nov  3 09:41:26 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 3 Nov 2025 09:41:26 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
 <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
 <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>
Message-ID: <iwLh8k8YhYwZJjJMHkSRdMe9GNwuVzUlCgKAVYDiku8=.e19b2dfb-8970-4d69-b9a8-908ac250ea92@github.com>

On Sat, 1 Nov 2025 09:01:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable.  Adding a SafeFetch here might cause a regression.
>
>> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable. Adding a SafeFetch here might cause a regression.
> 
> Sure, but 2 things:
> Loom doesn't meed post-call NOPs as much as it used to.
> We could fairly easily make SafeFetch much faster than it is, if needs be.
> But anyway, I approved this patch.

Thank you for the detailed advice, @theRealAph,

I now see how `SafeFetch` can be valuable independently of whether false-positive matches with the post-call NOP pattern can happen during normal execution. I hadn't considered the stack corruption use case before.

Reviewing the `SafeFetch` implementation, I believe in general case it relies on `sigsetjmp` on POSIX systems and exceptions on Windows.
However, for AArch64, the `SafeFetch32` has an optimized implementation - avoiding `setjmp` or exceptions overhead.
On the fast path, it performs just one load, so any extra performance cost would be due to that path cannot currently be inlined.

There indeed seems to be a way to have it inlined, at least on Linux - via creating an extra ELF section containing addresses of all inlined `SafeFetch` loads and corresponding continuation points, which the signal handler can iterate through. I've not prototyped this, but if feasible, it could make the performance impact of using `SafeFetch` negligible.

Since there isn't necessarily a consensus at this stage on whether `SafeFetch` should be added in this PR, I'd propose opening a separate JBS ticket for it to avoid blocking merge of the exception handler stub code cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3479653271

From fbredberg at openjdk.org  Mon Nov  3 10:05:35 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 3 Nov 2025 10:05:35 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Update two, after the review
 - Update after review
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

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

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=03
  Stats: 2972 lines in 80 files changed: 1259 ins; 1425 del; 288 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

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

From alanb at openjdk.org  Mon Nov  3 11:05:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Nov 2025 11:05:05 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:

> 102:        * </pre></blockquote>
> 103:        *
> 104:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.

Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486085650

From alanb at openjdk.org  Mon Nov  3 11:05:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Nov 2025 11:05:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
 <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
 <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>
 <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>
Message-ID: <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com>

On Wed, 29 Oct 2025 18:47:13 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> I see that now - fixing ....
>
> I also removed the nested {@code ..} from within the <pre\></pre\> as that also caused an issue

Good. You can move the example to a snippet too and that will  allow the `<pre>` tags to go away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486086959

From egahlin at openjdk.org  Mon Nov  3 11:46:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 11:46:04 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3480099956

From ysuenaga at openjdk.org  Mon Nov  3 14:29:32 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 3 Nov 2025 14:29:32 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v12]
In-Reply-To: <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <RNugF0Qs5SoIYT0ku0VcglpsEZUuIHwMYypyhBd0Gpw=.dc942e3d-2f8f-4d6f-be53-d5370fac2fa8@github.com>
Message-ID: <LXbRrrqi3PHi7xD6yjbYRUSsriAwqU8KqsJQ_LkHzBo=.3e56bfd2-a97d-48e7-ae05-ece456457fd0@github.com>

On Sat, 1 Nov 2025 03:20:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into jhsdb-jstack-bp
>  - Improve comments in isValidFrame method
>  - Use stderrShouldBeEmptyIgnoreVMWarnings
>  - TestJhsdbJstackMixedWithXComp.java should be run on Linux AMD64 only
>  - Respect RSP to parse DWARF
>  - Revert testcase changes
>  - Fix imports
>  - Update testcase
>  - Update testcase
>  - Add glibc version check to TestJhsdbJstackMixedWithXComp.java
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d2260236...eb2f0ab0

Thanks a lot everyone involved in this PR!

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3480834201

From ysuenaga at openjdk.org  Mon Nov  3 14:29:34 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 3 Nov 2025 14:29:34 GMT
Subject: Integrated: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <15gRRGiyO6BZ8vd6txMvb1j9-ukBDYTv5NXY-zRmzAw=.976e347b-2ce6-4f31-9dfc-1a245d08dc3e@github.com>

On Sun, 19 Oct 2025 06:16:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

This pull request has now been integrated.

Changeset: 045018d5
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/045018d5f39751af9f673974ff876c47596cdbd0
Stats:     248 lines in 6 files changed: 182 ins; 10 del; 56 mod

8370176: Mixed mode jhsdb jstack cannot unwind call stack with -Xcomp

Co-authored-by: Fei Yang <fyang at openjdk.org>
Reviewed-by: cjplummer, kevinw

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

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

From macarte at openjdk.org  Mon Nov  3 20:08:22 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 3 Nov 2025 20:08:22 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
 <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
Message-ID: <ul3465RuqLeBGnl4bn0RPmrvhrFY0k1uCV_hT3tWgSk=.1708b2a8-62d5-43bd-a813-a4b568156273@github.com>

On Mon, 3 Nov 2025 11:42:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

Thank you for the suggestion

To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and it's PR is here: https://github.com/openjdk/jdk/pull/27965

The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain

Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review

So technically we could delay this PR and still have the required functionality in mainline, I'd like to hear from the other reviewers on this matter

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3482353337

From lmesnik at openjdk.org  Mon Nov  3 20:09:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 3 Nov 2025 20:09:33 GMT
Subject: RFR: 8371114: Problemlist
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
Message-ID: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>

Problemlist failing test until main bug is fixed.

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

Commit messages:
 - 8371114: Problemlist vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java

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

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

From amenkov at openjdk.org  Mon Nov  3 20:25:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 3 Nov 2025 20:25:04 GMT
Subject: RFR: 8371114: Problemlist
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
In-Reply-To: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
References: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
Message-ID: <3tb-vBUSZ6OAzo138zVGlXSZSb9yjXiW0rt24Y_JIg0=.35a3fc99-db2d-4c8f-9325-7d503c81b416@github.com>

On Mon, 3 Nov 2025 18:32:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Problemlist failing test until main bug is fixed.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28115#pullrequestreview-3412793863

From eosterlund at openjdk.org  Mon Nov  3 21:10:00 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 3 Nov 2025 21:10:00 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
 <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
Message-ID: <dVfOLhSkfBz7zhE4EEqyX3Q7kAkKJ4Os4D-Enyqqsdg=.a37cc396-4514-4642-9510-7b8be901fddc@github.com>

On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
>> 
>> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
>
>> > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
>> 
>> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
> 
> We have 
> 
> 
> #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
> #define INCLUDE_CDS_JAVA_HEAP 1
> 
> 
> So we need to make sure it works for 32 bit as well.

@iklam does this look okay now?

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3482604226

From heidinga at openjdk.org  Mon Nov  3 21:35:01 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Nov 2025 21:35:01 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
 <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>
Message-ID: <6LpN0Ae8kfDApFOPUYrbdqz2fRh8HVvvbCa8kiEEFS0=.31761484-c4c1-428c-9974-d2bdec3b587d@github.com>

On Mon, 3 Nov 2025 11:01:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:
> 
>> 102:        * </pre></blockquote>
>> 103:        *
>> 104:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.
> 
> Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future.

I see a couple of cases for when `endRecording` is called:
1) Within the same process to generate a cache - given the api will only return `true` to one caller, that caller is the only one who can be responsible for taking further action (copying the cache somewhere, etc).  Already ended or failed makes no difference operationally.

2) From a monitoring process - again only the successful case matters.  All failures (already ended or failed) are indistinguishable.  No further action can be taken by the observer.  It's only the success case that matters

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2487912197

From iklam at openjdk.org  Tue Nov  4 00:09:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 00:09:15 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v14]
In-Reply-To: <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
Message-ID: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>

On Thu, 30 Oct 2025 08:43:45 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update

The updated version looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3413414459

From syan at openjdk.org  Tue Nov  4 02:28:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Nov 2025 02:28:01 GMT
Subject: RFR: 8371114: Problemlist
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
In-Reply-To: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
References: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
Message-ID: <lKzu6Nbd0kXUEdlXpHAaY0DYwsLQWOnAurTpsIIW8Lo=.c30a45b8-6e99-41c5-a174-2c325111a9c6@github.com>

On Mon, 3 Nov 2025 18:32:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Problemlist failing test until main bug is fixed.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28115#pullrequestreview-3413704789

From eosterlund at openjdk.org  Tue Nov  4 05:14:05 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 4 Nov 2025 05:14:05 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v14]
In-Reply-To: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
 <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
Message-ID: <Mk5bbH-TwIBNoJ05BedvJPgBJNXMZ_9XH9knqJbdMew=.77f2c317-0f4c-4e37-8724-dcb7f6ddfa2d@github.com>

On Tue, 4 Nov 2025 00:05:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The updated version looks good to me.

Thank you for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3483893308

From sspitsyn at openjdk.org  Tue Nov  4 07:06:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 07:06:30 GMT
Subject: RFR: 8371114: Problemlist
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
In-Reply-To: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
References: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
Message-ID: <frVOfnSuYhUhwjsee8GbPH9uxVB1VfwmRtWM1DuDBJ0=.9a229c2d-c30e-47c8-892d-bb0a2c576be5@github.com>

On Mon, 3 Nov 2025 18:32:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Problemlist failing test until main bug is fixed.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28115#pullrequestreview-3414218652

From duke at openjdk.org  Tue Nov  4 09:47:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 4 Nov 2025 09:47:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v2]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <TdzU81Zpb9mxUTlvym_vleBjePgQ_YAL-FU0ZLUGk3g=.f221dbb3-01ad-49a8-86ab-1de081c0ca44@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - 8366659: Fixed whitespace.
 - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ef464d69...ba667e37

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=01
  Stats: 374 lines in 3 files changed: 310 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From duke at openjdk.org  Tue Nov  4 09:48:20 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 09:48:20 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

 - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
 - Merge from the main branch
 - Address review comments and fix a mistype
 - Check for NOP and MOVK separately in NativePostCallNop
 - Test for deoptimization in virtual threads
   
   Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
 - Merge from the main branch
 - Address review comments
 - Address review comments
 - Address review comments
 - The patch is contributed by @TheRealMDoerr
 - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

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

Changes: https://git.openjdk.org/jdk/pull/26678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=09
  Stats: 569 lines in 41 files changed: 268 ins; 216 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/26678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678

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

From duke at openjdk.org  Tue Nov  4 09:50:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 4 Nov 2025 09:50:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v3]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <2o8megr_K4HfeERT_OCCD4zQz0OLjtd9sQafi5btuSw=.2d1281cf-8965-41ba-97b6-e89466386664@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Added a comment to a boolean arg for enter()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/ba667e37..e84dca9d

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

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

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

From mdoerr at openjdk.org  Tue Nov  4 09:58:54 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Nov 2025 09:58:54 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <cIK9mFn8sPtndcHItgUfNgF0prPHnG7wfcZoyd8VfWA=.6ea41aea-73f4-46a7-9cd1-187d29ad556e@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3415283652

From shade at openjdk.org  Tue Nov  4 10:57:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Nov 2025 10:57:03 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v8]
In-Reply-To: <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
Message-ID: <KXHAb89yGeMzG0RjhpTR29eo9uHw0Yc9KNaSwkeOdFQ=.5c8ab14b-2a30-4492-b68e-02e70504f58c@github.com>

On Thu, 30 Oct 2025 11:43:26 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Erase obsolete comments

I believe all reviewers are in agreement, and you need just another (re-)review to pass the automated checks. I skimmed through the change, and it looks reasonable to me. Thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27844#pullrequestreview-3415701693

From jsjolen at openjdk.org  Tue Nov  4 10:57:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:44 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v14]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <fDfZM9Sgvsb4dJjWGJG7DV3vJVBa66APA2gFeKMb03I=.00e3f6d4-a487-4d07-ab95-0b5c6ce459e0@github.com>

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

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

 - Serguei comments
 - Revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/5e72da4e..e3419823

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

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

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

From jsjolen at openjdk.org  Tue Nov  4 10:57:48 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:48 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
 <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
 <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>
Message-ID: <QnsgxlHRJAdPmvnB_PluIUz12nAD_yefeN91pSNoLiA=.e35761f9-d8fd-497f-8a98-6f9410094536@github.com>

On Wed, 15 Oct 2025 17:58:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I believe that the style is to have an empty line between the code and the endif, so this is a style fix.
>
> The issue is this is the only fix in this file. Should we go and fix all style issues around?
> In fact, I'm okay with this tweak. :)

Ah, you're right. I responded to this in the 'Conversation' view and didn't see that this is the only change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489892804

From jsjolen at openjdk.org  Tue Nov  4 10:57:50 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:50 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
Message-ID: <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>

On Tue, 23 Sep 2025 04:22:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>>  - Fix BSM naming
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482:
> 
>> 480:     int basePos = offs.at(bsmIndex);
>> 481:     int argv = basePos + INDY_ARGV_OFFSET;
>> 482:     int argc = getBootstrapMethodArgsCount(bsmIndex);
> 
> Nit: Consider to make it shorter:
>   `getBootstrapMethods` => `getBSMs`
>   `getBootstrapMethodArgsCount` => `getBSMArgsCount`

I'm keeping it verbose, as that's the general style of this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489941288

From jsjolen at openjdk.org  Tue Nov  4 10:57:47 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:47 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <gaDkJcdQTKgBJeFtj604SkP0vjZdYq3VZU7phQv1hxQ=.35dd5839-54bb-4829-994c-94675dba651b@github.com>

On Wed, 8 Oct 2025 20:35:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/classfile/classFileParser.cpp line 3342:
> 
>> 3340: 
>> 3341:     BSMAttributeEntry* entry = iter.reserve_new_entry(bootstrap_method_ref, num_bootstrap_arguments);
>> 3342:     guarantee_property(entry != nullptr, "Invalid BootstrapMethods num_bootstrap_methods. The total amount of space reserved for the BootstrapMethod attribute was not sufficient", CHECK);
> 
> Nit: This line is too big. It is a good idea to split the message. Also, would it better to move this guaranty for `nullptr` into the `reserve_new_entry()`?

I think it's best to keep this null check here so that we can have a specialized error message. In this case, we are reading a classfile, so we're parsing untrusted input. That's when we might get a null result when attempting to reserve a new entry.


In the other cases, we're working from trusted data and a presumed-to-be-correct algorithm. I've added assertions in these cases, as it shouldn't break.

> src/hotspot/share/oops/bsmAttribute.hpp line 97:
> 
>> 95:     int _cur_offset;
>> 96:     // Current unused offset into BSMAEs bsm-data array
>> 97:     int _cur_array;
> 
> Nit: The declarations at lines 95, 97 will be more readable if comments above declarations trail declarations. The comment should not start with capital.

Do you mean that you want this?

```c++
    int _cur_offset; // current unused offset into BSMAEs offset array

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489955815
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489948444

From krk at openjdk.org  Tue Nov  4 11:04:43 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 4 Nov 2025 11:04:43 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v8]
In-Reply-To: <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
Message-ID: <85W6i3Gd5Jv9yKHc-YZryoacJjhLLb4jUSSMx1FlTlU=.fd3acd85-20f0-40b7-81a6-30c2a3370b8c@github.com>

On Thu, 30 Oct 2025 11:43:26 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Erase obsolete comments

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27844#issuecomment-3485335611

From duke at openjdk.org  Tue Nov  4 11:04:43 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 11:04:43 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v8]
In-Reply-To: <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <ODLhe5VytkGzOShIMT3onqahh-Dpw_QupeeerpmVxZE=.9c4cd08a-4dbf-4ff7-b278-e12d2359cee8@github.com>
Message-ID: <Ju2F9OB9J9atOuCoX79I38o3PFOx_TUzkoaPXsWJcaE=.6e2bac4b-33f4-4d48-803e-a946292b647e@github.com>

On Thu, 30 Oct 2025 11:43:26 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Erase obsolete comments

@krk 
Your change (at version 898568d516739531de6bf3563090175e7e9d2cce) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27844#issuecomment-3485343726

From duke at openjdk.org  Tue Nov  4 11:35:04 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 11:35:04 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <JohQnNOwaUXT_m459WOhFfXutn-U4SMQ6VFOjacecIU=.e427b201-abc7-44fc-938a-4c3d0d506406@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Thank you all for reviewing the PR and helping with testing.

A separate JBS issue has been opened for `SafeFetch`: https://bugs.openjdk.org/browse/JDK-8371204.

I plan to wait until tomorrow before issuing the `/integrate` request. Please let me know if you think this should wait longer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3485520456

From egahlin at openjdk.org  Tue Nov  4 13:29:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 4 Nov 2025 13:29:59 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <SkZ1al6sgQVHfhN1vOTFUoLCbgxtKNnDQs5VduhJdRU=.2ce59627-8bfe-443a-a4ef-88d91bd5b1aa@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

> To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and its PR is here: #27965

Ah, I didn't know that. 

(I don?t have a strong opinion on this, but for consistency you might want the jcmd commands for AOT recording to use the same naming convention for starting, stopping, and checking the status of a recording as JFR: JFR.start, JFR.stop, JFR.check, JFR.dump and JFR.configure, where applicable. Initially, we had start_recording, but we later shortened it to start to avoid unnecessary typing)

> The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain
> 
> Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review

Ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3486004039

From coleenp at openjdk.org  Tue Nov  4 13:44:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Nov 2025 13:44:54 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
Message-ID: <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>

On Tue, 4 Nov 2025 10:49:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482:
>> 
>>> 480:     int basePos = offs.at(bsmIndex);
>>> 481:     int argv = basePos + INDY_ARGV_OFFSET;
>>> 482:     int argc = getBootstrapMethodArgsCount(bsmIndex);
>> 
>> Nit: Consider to make it shorter:
>>   `getBootstrapMethods` => `getBSMs`
>>   `getBootstrapMethodArgsCount` => `getBSMArgsCount`
>
> I'm keeping it verbose, as that's the general style of this file.

Yes please I like the full names if possible rather than abbreviations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2490567923

From fbredberg at openjdk.org  Tue Nov  4 13:49:23 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 4 Nov 2025 13:49:23 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
Message-ID: <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>

On Mon, 27 Oct 2025 00:04:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/abstract_vm_version.hpp line 195:
> 
>> 193: 
>> 194:   // Is recursive fast locking implemented for this platform?
>> 195:   constexpr static bool supports_recursive_fast_locking() { return false; }
> 
> Next cleanup: this is supported on all platforms now, so we can get rid of this migration aid.

Not sure we can do that, since I don't find any implementation of recursive fast locking on ARM32.
@bulasevich Any comment on this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2490583182

From jsjolen at openjdk.org  Tue Nov  4 14:27:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 14:27:57 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>

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

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

 - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
 - Fix naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/e3419823..219ef346

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

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

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

From cjplummer at openjdk.org  Tue Nov  4 15:42:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Nov 2025 15:42:25 GMT
Subject: RFR: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <jXfCV1a6KPvibxPvEQXlGoI2tdQ4YTKWXeffhcFIuJk=.65296cb8-99e8-4cf7-b47d-9176d51d073d@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

Ping! I'd like to get this pushed as it is causing CI failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/28091#issuecomment-3486638761

From pchilanomate at openjdk.org  Tue Nov  4 15:48:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:48:00 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
Message-ID: <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>

On Mon, 3 Nov 2025 19:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested fix in macroAssembler_ppc.cpp

I pushed a small fix to `JvmtiHideSingleStepping` for an issue found during pre-integration testing where we hit this assert: https://github.com/openjdk/jdk/blob/50bb92a33b32778a96b1823ff995889892bef890/src/hotspot/share/prims/jvmtiThreadState.hpp#L337
The problem is that for a preempting vthread, the `JvmtiThreadState` of the current `JavaThread` has already been rebinded to the state of the carrier when executing `~JvmtiHideSingleStepping`. The fix is to remember the `JvmtiThreadState` used originally in the `JvmtiHideSingleStepping` constructor. The commit includes a new test that reproduces the issue. @sspitsyn maybe you could take a look at this please?

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3486666711

From kevinw at openjdk.org  Tue Nov  4 16:03:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 4 Nov 2025 16:03:23 GMT
Subject: RFR: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <GSeAAHOKVMJ7fVibQ2oEyQoGh8b6rM7AhaYzJ5AHR0k=.2d47d9b3-ba07-4c96-b4a4-2dba9de0b7cb@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

Looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28091#pullrequestreview-3417285143

From lmesnik at openjdk.org  Tue Nov  4 16:01:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 4 Nov 2025 16:01:09 GMT
Subject: Integrated: 8371114: Problemlist
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
In-Reply-To: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
References: <0YcGS9LzOn5nWJx7rDA861iuKAvrkDmLzV6DRPNisp0=.3e826cc6-662d-47c6-bdde-660f7b6529e2@github.com>
Message-ID: <9Jx9v3mJaqf2pw4yZXKaSLe0Drx6WgwZRFS_iEfrWj0=.f9e800fa-7535-4851-a2d1-271b41ca61d1@github.com>

On Mon, 3 Nov 2025 18:32:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Problemlist failing test until main bug is fixed.

This pull request has now been integrated.

Changeset: 7d3c66f3
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d3c66f379fcb24d4505c2c12e20b24dce313e56
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8371114: Problemlist vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java

Reviewed-by: amenkov, syan, sspitsyn

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

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

From amenkov at openjdk.org  Tue Nov  4 19:22:59 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 4 Nov 2025 19:22:59 GMT
Subject: RFR: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <OgYWOH5XSzb7VHvqHLT5DTuTXJEJ5Tvm-WqUq50g6PU=.7932c185-e9f1-40cd-b984-ac9f5efca673@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28091#pullrequestreview-3418309880

From sspitsyn at openjdk.org  Tue Nov  4 20:45:37 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 20:45:37 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
 <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>
Message-ID: <0Z0x2IAQ1TayXTP7kAm9U3Yyx6A4rw88m7Kjgen6bAY=.15663b42-96db-444f-9e2d-2efcbe4dd94d@github.com>

On Tue, 4 Nov 2025 15:45:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> @sspitsyn maybe you could take a look at this please?

It looks good in general. I'm still looking at it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3487943741

From sspitsyn at openjdk.org  Tue Nov  4 20:49:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 20:49:19 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <wPQlWFIZCeBMq589X81beQ-LNEwEBI0UHFATEarQXFI=.4bcd8d39-252c-4222-836e-5f7ec7d07fd3@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:

> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
> 37:            jmethodID method, jlocation location) {
> 38: }

Q: Would it make sense to verify that `SingleStep` events are posted or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2491981248

From sspitsyn at openjdk.org  Tue Nov  4 21:12:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:12:51 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418644332

From sspitsyn at openjdk.org  Tue Nov  4 21:16:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:16:15 GMT
Subject: RFR: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <-YvDCJxFuLX2qQ-ON1SuXdY3rTOetAIJx1Dr6RbEWZk=.1453d481-1849-4e73-a8f1-ffdaea2ac73c@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

Good fix.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28091#pullrequestreview-3418654649

From pchilanomate at openjdk.org  Tue Nov  4 21:28:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
Message-ID: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>

On Tue, 4 Nov 2025 21:10:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!
>
Great, thanks for the review Serguei!

> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
> 
>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>> 37:            jmethodID method, jlocation location) {
>> 38: }
> 
> Q: Would it make sense to verify that `SingleStep` events are posted or not?

Good idea, I added a check for it. Let me know if that works.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488063416
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492084640

From pchilanomate at openjdk.org  Tue Nov  4 21:28:14 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:14 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Add check for SingleStep events
 - Merge branch 'master' into JDK-8369238
 - fix to JvmtiHideSingleStepping
 - Suggested fix in macroAssembler_ppc.cpp
 - Improve comment and assert msg
 - More fixes from David's comments
 - Merge branch 'master' into JDK-8369238
 - add const to references
 - Improve comment in anchor_mark_set_pd
 - More comments from Coleen
 - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

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

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=14
  Stats: 2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From sspitsyn at openjdk.org  Tue Nov  4 21:54:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:54:54 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
 <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
Message-ID: <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>

On Tue, 4 Nov 2025 13:42:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'm keeping it verbose, as that's the general style of this file.
>
> Yes please I like the full names if possible rather than abbreviations.

> I'm keeping it verbose, as that's the general style of this file.

Okay. Local naming consistency is important too.

> Yes please I like the full names if possible rather than abbreviations.

Here the problem is not about full names vs abbreviations. It is about naming inconsistency with all these `BSM` related code. There are already many places with the `BSM` abbreviation. But I agree it is better to maintain the local style here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2492144260

From sspitsyn at openjdk.org  Tue Nov  4 22:02:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:02:52 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
Message-ID: <lJEW78VnaoodBYu5e6lSWHwaWmrKB0Xi1ggv2vxauHs=.e48d0c18-d48d-45ee-9c2e-c299af2e9494@github.com>

On Tue, 4 Nov 2025 14:27:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

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

Thank you for the updates. This review became too long. I'm okay with the current state. The refactoring itself is nice to have.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.org  Tue Nov  4 22:36:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:36:41 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
Message-ID: <zGX18FsmvE9eyD7hw9Wmo944uX-z3bhZujuZrsanIkA=.a5ff48a4-160e-4638-915a-28a4dbf0b715@github.com>

On Tue, 4 Nov 2025 14:27:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

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

I'd recommend to additionally run mach5 tier-6.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3488242701

From sspitsyn at openjdk.org  Tue Nov  4 22:41:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:18 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <vR7s_qA4KIDxPjqxYFoDKmIAqenU_LILmD4Tr2pgwU8=.5716e1a8-1900-42d2-907c-d7f57e0708e2@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418852425

From sspitsyn at openjdk.org  Tue Nov  4 22:41:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:20 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
 <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
Message-ID: <CyU-vZ-DK4lL1hzptQL8ISdjoNLqPGAozPFVgFNTRv4=.a6296035-c3b4-403c-a488-db6a63dca16a@github.com>

On Tue, 4 Nov 2025 21:23:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
>> 
>>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>>> 37:            jmethodID method, jlocation location) {
>>> 38: }
>> 
>> Q: Would it make sense to verify that `SingleStep` events are posted or not?
>
> Good idea, I added a check for it. Let me know if that works.

Thanks! It is good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492228658

From pchilanomate at openjdk.org  Tue Nov  4 23:35:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:55 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <lfcJgXrHP0jBeObaX7-9Aex071uKMQ6IIibSiBtcndg=.ba41e77c-9443-4baf-913f-ff9dbd6d28d0@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Thanks everyone for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488372018

From pchilanomate at openjdk.org  Tue Nov  4 23:35:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:58 GMT
Subject: Integrated: 8369238: Allow virtual thread preemption on some common
 class initialization paths
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <uBoqZEVMoW7Qe0xjtksGNookxMDWSiNTxf0iIYJ7Ygo=.bc63a4b1-97df-4386-8610-617103f46ed2@github.com>

On Tue, 14 Oct 2025 13:42:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

This pull request has now been integrated.

Changeset: c6a88155
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6a88155b519a5d0b22f6009e75a0e6388601756
Stats:     2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod

8369238: Allow virtual thread preemption on some common class initialization paths

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: sspitsyn, dholmes, coleenp, fbredberg

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

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

From jsjolen at openjdk.org  Wed Nov  5 08:37:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 08:37:22 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v16]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>

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

Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into operands-again
 - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
 - Fix naming
 - Serguei comments
 - Revert change
 - Some nits
 - Fix copyright
 - Move BSMAttribute BSMAttributeEntries to own header file
 - Merge remote-tracking branch 'origin/operands-again' into operands-again
 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - ... and 21 more: https://git.openjdk.org/jdk/compare/1e0cd337...57f0093e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/219ef346..57f0093e

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

  Stats: 278590 lines in 3431 files changed: 200223 ins; 55822 del; 22545 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From duke at openjdk.org  Wed Nov  5 10:57:18 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 10:57:18 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <j7lqJEM_ZYzvt4DXkF1gPlV1tHCaPwN_KQAMsueuHxk=.1ab0ac81-b18a-4eff-bb26-9262c2426858@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

@ruben-arm 
Your change (at version 359c2f185c7add1cac98523f4325a7896e8bd3e0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3490519353

From duke at openjdk.org  Wed Nov  5 11:58:32 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 5 Nov 2025 11:58:32 GMT
Subject: Integrated: 8365047: Remove exception handler stub code in C2
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <NlWZi6MCksCD41c16o6QfIm9vGv29jWy6zWj-inNkPE=.9bf73f8c-3b8d-4fc6-b537-ef2fced46d89@github.com>

On Thu, 7 Aug 2025 15:49:20 GMT, Ruben <duke at openjdk.org> wrote:

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

This pull request has now been integrated.

Changeset: 3e3822ad
Author:    Ruben Ayrapetyan <ruben.ayrapetyan at arm.com>
Committer: Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e3822ad7eadbb3d86a3b94a6bd858f8c8ef9364
Stats:     569 lines in 41 files changed: 268 ins; 216 del; 85 mod

8365047: Remove exception handler stub code in C2

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, dlong, dfenacci, adinn, fyang, aph

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

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

From coleenp at openjdk.org  Wed Nov  5 12:50:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:26 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v16]
In-Reply-To: <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>
Message-ID: <N4u6yCmwx4e1kR7RDL9PBPku50w4urxw73iGk_bY7uo=.ad4721d3-7ea1-43c2-b5d8-000ec2c7c794@github.com>

On Wed, 5 Nov 2025 08:37:22 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into operands-again
>  - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
>  - Fix naming
>  - Serguei comments
>  - Revert change
>  - Some nits
>  - Fix copyright
>  - Move BSMAttribute BSMAttributeEntries to own header file
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/edfdae41...57f0093e

This is excellent work!  I had a couple of small suggested changes, but am happy to approve it.

src/hotspot/share/oops/bsmAttribute.hpp line 28:

> 26: #define SHARE_OOPS_BSMATTRIBUTE_HPP
> 27: 
> 28: #include "classfile/classLoaderData.hpp"

I think you can forward declare ClassLoaderData rather than include the whole file here.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3421758555
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494308893

From coleenp at openjdk.org  Wed Nov  5 12:50:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:30 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <8WVVrT5cKKUY1wGnTvxzj-8FFM-dZnYtuActIQRXZUQ=.0f11587c-e06f-47ee-93e4-bd7a5e7fc16f@github.com>

On Wed, 8 Oct 2025 21:09:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/oops/bsmAttribute.inline.hpp line 34:
> 
>> 32:       _cur_array + BSMAttributeEntry::u2s_required(argc) > insert_into->bootstrap_methods()->length()) {
>> 33:     return nullptr;
>> 34:   }
> 
> Nit: This check needs a comment. Also, I'd suggest to add a guarantee here instead of returning `nullptr`.

I agree with this comment - is returning null going to crash somewhere down the line?  Is this an overflow?

> src/hotspot/share/oops/constantPool.hpp line 94:
> 
>> 92:   InstanceKlass*       _pool_holder; // the corresponding class
>> 93: 
>> 94:   BSMAttributeEntries _bsmaentries;
> 
> Nit: Suggestion to rename: `_bsmaentries` => `_bsm_entries`.

This is a good suggestion for a minor change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494322202
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494323677

From coleenp at openjdk.org  Wed Nov  5 12:50:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
 <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
 <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>
Message-ID: <9KAeG5WWY5hMK4Yjl0i3G9tCWreCYe-b8y-BeHnXSdY=.6c742a39-87f8-40e9-8725-be05bb5f36f4@github.com>

On Tue, 4 Nov 2025 21:52:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yes please I like the full names if possible rather than abbreviations.
>
>> I'm keeping it verbose, as that's the general style of this file.
> 
> Okay. Local naming consistency is important too.
> 
>> Yes please I like the full names if possible rather than abbreviations.
> 
> Here the problem is not about full names vs abbreviations. It is about naming inconsistency with all these `BSM` related code. There are already many places with the `BSM` abbreviation. But I agree it is better to maintain the local style here.

The abbreviation in the middle of the word makes me find it hard to say in English in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494315140

From coleenp at openjdk.org  Wed Nov  5 14:32:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 14:32:01 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>
Message-ID: <D0Ib2OwtClhWamHTNxArRD4ED-yImdvNvuVsKHtvLKM=.c74643cd-f891-4b31-9e0b-256fe4f40759@github.com>

On Mon, 3 Nov 2025 10:05:35 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

I believe you've addressed all of David's comments and mine, and we can have a new PR for moving and additional work we're going to do with the ObjectMonitorTable.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3422419032

From fbredberg at openjdk.org  Wed Nov  5 14:39:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 14:39:22 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <_96H3JAsfT8uJ5oY7PEtsiX4tNZPy0VRgDRW6YjfBCo=.aa04fd8b-9520-463a-9677-a73a52244ef3@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
 <_96H3JAsfT8uJ5oY7PEtsiX4tNZPy0VRgDRW6YjfBCo=.aa04fd8b-9520-463a-9677-a73a52244ef3@github.com>
Message-ID: <UN2hCH8ujb0ODGR4lBLzVGC9J6k6PeHFCTenEYvBg34=.8fcf5861-75ee-433b-8e94-1e632865d7ac@github.com>

On Fri, 31 Oct 2025 13:52:53 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 287:
>> 
>>> 285:   _last_async_deflation_time_ns = os::javaTimeNanos();
>>> 286: 
>>> 287:   ObjectSynchronizer::create_om_table();
>> 
>> The original code should effectively be inlined here:
>> 
>> if (UseObjectMonitorTable) {
>>   ObjectMonitorTable::create();
>> }
>
> Tried to do a quick fix for this, but `ObjectMonitorTable` is not known at this point, and forward declaring it turned out to be a mess. So, since we agreed to move out `ObjectMonitorTable` to a separate file, I think this can be postponed until that file has been created.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

>> src/hotspot/share/runtime/synchronizer.cpp line 1838:
>> 
>>> 1836:   if (!UseObjectMonitorTable) {
>>> 1837:     return;
>>> 1838:   }
>> 
>> This should move to the caller and be replaced with an assertion at this level. Though you don't need to introduce this method at all as the caller can call `OMT::create` directly.
>
> Same as last answer, this is easily done once we have moved `ObjectMonitorTable` to a separate file, but not until then.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494806413
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494808134

From fbredberg at openjdk.org  Wed Nov  5 14:39:24 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 14:39:24 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <WwyMZzIHAxiUCer6euFB5OzJk6iiFO4ysBAT4csfTlA=.97b29ebf-87ad-4cea-9896-495dd8140056@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
 <00xzxB3fxjSbmCZCQCu_ZEClnyxq2yfPfF-9SKJXoIc=.b45bec0f-164d-4604-87e2-d69ce072533b@github.com>
 <WbEr0-F2ZKolF2az6-MfdcG03WqKZ18kvk4axRvmjtk=.7ee9eb10-1b41-448d-a6b6-265a72eb0417@github.com>
 <WwyMZzIHAxiUCer6euFB5OzJk6iiFO4ysBAT4csfTlA=.97b29ebf-87ad-4cea-9896-495dd8140056@github.com>
Message-ID: <7ZEE720IklvXdhfxVI_Bxz2IwcY_CoOwPJHtk9PZ1bw=.deca3dd9-c7d6-4fbc-865d-470cd2cf96b9@github.com>

On Mon, 27 Oct 2025 12:47:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I agree on both counts: move it to a new file in a new PR.
>
> Follow-on cleanup would be fine for moving this.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494797881

From cjplummer at openjdk.org  Wed Nov  5 15:56:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Nov 2025 15:56:23 GMT
Subject: RFR: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <oyvEMdQAyF384xC5RHQ0OpWLXieEKxMcj4cFzALoelw=.2eec7c24-dfd9-41c5-8ab8-06dff9cf42e0@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

Thank you for the reviews Alex, Kevin, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28091#issuecomment-3492016792

From cjplummer at openjdk.org  Wed Nov  5 15:59:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Nov 2025 15:59:33 GMT
Subject: Integrated: 8370201: Test
 serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM
 warnings
In-Reply-To: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
References: <Ia2ysYI2BhbiGpZV7nUF86iOi-527otszhJ0wmXbQnU=.ec3e553f-16aa-4bcc-820b-be60b7e786a4@github.com>
Message-ID: <15zG3f-LkjwuxrUDQhIPE3DuBVY46Ejvi3NM807QPdw=.49919643-6d83-484b-b1b7-2d1bb31559f7@github.com>

On Fri, 31 Oct 2025 19:25:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are a number of tests that check that stderr has no output other than deprecation warnings. This is bit overdone and unnecessary. There are command line options such as -XX:+UseLargePages that can result in a warning that has nothing to do with the test. The test should not fail for this reason.
> 
> For the SA tests, the main reason for the stderr check is to catch exceptions, warnings, or errors generated by SA tools on stderr. There is no need to fail if there is a VM warning, so switching to stderrShouldBeEmptyIgnoreVMWarnings() should be fine.
> 
> For the attach test, the test is trying to instigate a failure by deleting the .java_pid files. Before the bug fix that this test was added for, the jcmd tool would get a com.sun.tools.attach.AttachNotSupportedException and print it on stderr, and also result in an exit value of 1. The test already checks the exit value, so this should be sufficient, but there is no harm in also checking stderr assuming we allow VM warnings, so this test is also switching to stderrShouldBeEmptyIgnoreVMWarnings().
> 
> Tested by running all affected tests with -XX:+UseLargePages on hosts that produce a warning message when you do this.

This pull request has now been integrated.

Changeset: b0536f9c
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0536f9c2a6ddfa27be8fad8f53783c6b28d22c9
Stats:     8 lines in 5 files changed: 0 ins; 0 del; 8 mod

8370201: Test serviceability/sa/TestJhsdbJstackWithVirtualThread.java fails due to VM warnings

Reviewed-by: kevinw, amenkov, sspitsyn

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

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

From bulasevich at openjdk.org  Wed Nov  5 16:03:41 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 5 Nov 2025 16:03:41 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
 <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>
Message-ID: <aSavq-NVJPJv2UXn5NLmS-C5i-s8Hz_XTYP2Pg97zW4=.730b943f-a7b4-4b4d-b4a7-8dd2eae9ac3d@github.com>

On Tue, 4 Nov 2025 13:46:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/abstract_vm_version.hpp line 195:
>> 
>>> 193: 
>>> 194:   // Is recursive fast locking implemented for this platform?
>>> 195:   constexpr static bool supports_recursive_fast_locking() { return false; }
>> 
>> Next cleanup: this is supported on all platforms now, so we can get rid of this migration aid.
>
> Not sure we can do that, since I don't find any implementation of recursive fast locking on ARM32.
> @bulasevich Any comment on this?

Recursive lightweight locking (JDK-8319796) was implemented for x86, AArch64, PPC64LE, RISC-V64, and S390, but not for ARM32.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2495179254

From cjplummer at openjdk.org  Wed Nov  5 16:20:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Nov 2025 16:20:16 GMT
Subject: RFR: 8371354: Problem list
 serviceability/sa/TestJhsdbJstackMixedWithXComp.java due to JDK-8371194
Message-ID: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>

This test failure is noisy so we need to problem list it. Testing in progress to make sure it really is excluded. I'd like to push this as trivial.

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

Commit messages:
 - problem list sa test

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

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

From kevinw at openjdk.org  Wed Nov  5 16:45:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 5 Nov 2025 16:45:32 GMT
Subject: RFR: 8371354: Problem list
 serviceability/sa/TestJhsdbJstackMixedWithXComp.java due to JDK-8371194
In-Reply-To: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
References: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
Message-ID: <9RPzU0_7dtVOWS3SoDf1tBbtuwLKAHwD8RGXz8KpNpQ=.91913a50-a15e-4391-a4ab-22bb592229b1@github.com>

On Wed, 5 Nov 2025 16:13:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test failure is noisy so we need to problem list it. Testing in progress to make sure it really is excluded. I'd like to push this as trivial.

Agreed 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28152#pullrequestreview-3423209909

From fbredberg at openjdk.org  Wed Nov  5 17:35:16 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 17:35:16 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Update two, after the review
 - Update after review
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

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

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=04
  Stats: 2981 lines in 80 files changed: 1263 ins; 1429 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

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

From cjplummer at openjdk.org  Wed Nov  5 18:06:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Nov 2025 18:06:18 GMT
Subject: RFR: 8371354: Problem list
 serviceability/sa/TestJhsdbJstackMixedWithXComp.java due to JDK-8371194
In-Reply-To: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
References: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
Message-ID: <edUywQCIUIm_EVAfbbcD7ys--xNHQUXugQ3NbXfZOG0=.894f2fd3-e8be-480f-9681-4394fdd7b029@github.com>

On Wed, 5 Nov 2025 16:13:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test failure is noisy so we need to problem list it. Testing in progress to make sure it really is excluded. I'd like to push this as trivial.

Thanks Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/28152#issuecomment-3492625188

From cjplummer at openjdk.org  Wed Nov  5 18:06:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Nov 2025 18:06:19 GMT
Subject: Integrated: 8371354: Problem list
 serviceability/sa/TestJhsdbJstackMixedWithXComp.java due to JDK-8371194
In-Reply-To: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
References: <Op4MUdgrw6WVf0CStjYq0NLZStPaAMxY9SerCZza2hE=.827de9d2-8f9b-48c9-86dc-747d6a67d723@github.com>
Message-ID: <ycFjUD1rt_nt0ZD6gZk7QfWRSyae4fzMpnTE5HJLtAs=.b4b4e8c7-00ba-4e16-89f4-78bee923af56@github.com>

On Wed, 5 Nov 2025 16:13:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test failure is noisy so we need to problem list it. Testing in progress to make sure it really is excluded. I'd like to push this as trivial.

This pull request has now been integrated.

Changeset: cf45e09c
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf45e09c388e95b5f11ad08ebdf7f277e968f90b
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8371354: Problem list serviceability/sa/TestJhsdbJstackMixedWithXComp.java due to JDK-8371194

Reviewed-by: kevinw

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

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

From sgehwolf at openjdk.org  Wed Nov  5 18:30:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Nov 2025 18:30:06 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping function
Message-ID: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>

Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.

For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):


f(x) = {(x - 2) \times 9999 + 1 \over 262142}


This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:


f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}


Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.

Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.

Thoughts?

**Testing:**
- [x] GHA
- [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

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

Commit messages:
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

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

From lmesnik at openjdk.org  Wed Nov  5 20:56:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 5 Nov 2025 20:56:13 GMT
Subject: RFR: 8371367: Replace remaining JvmtiJavaThreadEventTransition with
 JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
Message-ID: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>

The one JvmtiJavaThreadEventTransition mark should be replaced with macro.

Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.

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

Commit messages:
 - 8371367: Replace remaining JvmtiJavaThreadEventTransition with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK

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

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

From pchilanomate at openjdk.org  Wed Nov  5 21:05:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 5 Nov 2025 21:05:11 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
Message-ID: <KyupM4Q-0ERCwsb2jOuk-CfZjZ0Nc-9SecRSa2nXvoo=.00d5440c-c78a-4837-88f9-cb2f3501c298@github.com>

On Wed, 5 Nov 2025 17:35:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Looks good to me, thanks.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3424388594

From mr at openjdk.org  Wed Nov  5 21:55:02 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 5 Nov 2025 21:55:02 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <RNZzi6MSztflQxxrsQaHlPmRGLtr85_bSsSlOCz7S9w=.a3c23612-b237-40a5-b033-c556c8c98a6c@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

Changes requested by mr (Lead).

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:

> 76:        *  specification of the corresponding JVM command-line options, please refer
> 77:        * to https://openjdk.org/jeps/483 and https://openjdk.org/jeps/514.
> 78:        *

Please don't use bare URLs. Change these to

... please refer to JEPs <a href="https://openjdk.org/jeps/483">483</a> and
<a href="https://openjdk.org/jeps/514">514</a>.

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3424599728
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2496294936

From krk at openjdk.org  Thu Nov  6 11:16:58 2025
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 6 Nov 2025 11:16:58 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v9]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <91tUP7nn2ciUAGhkUxvWB_RcLOTrdti4uPa2AqUPzIU=.cc51aa81-590f-4dc0-9c42-a4b12bf8f37a@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Erase obsolete comments
 - Update src/jdk.hotspot.agent/doc/hsdb.html
   
   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - fix comments
 - Revert "run RotateLeftNode*IdealizationTests on amd64 too"
   
   This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.
 - requires hsdis
 - run RotateLeftNode*IdealizationTests on amd64 too
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - ... and 1 more: https://git.openjdk.org/jdk/compare/093e1287...7b67d1e8

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

Changes: https://git.openjdk.org/jdk/pull/27844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27844&range=08
  Stats: 2784 lines in 45 files changed: 623 ins; 2117 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/27844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27844/head:pull/27844

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

From eosterlund at openjdk.org  Thu Nov  6 11:38:35 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 6 Nov 2025 11:38:35 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v15]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <yYxT4X-RrbTIwIqBj6RbkYLjA35NaLV2tEZiY78hS34=.5564043f-10d1-4f5f-b02f-d8ffab7230a6@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

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

 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Comment update
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - remove include
 - Interned string value word accounting
 - Dont load all objects when JVMTI CFLH is on
 - Remove duplicate string dedup disabling when dumping
 - Accept interned strings sharing value with another string
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - ... and 21 more: https://git.openjdk.org/jdk/compare/b0536f9c...afdb11ee

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

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=14
  Stats: 8721 lines in 106 files changed: 5943 ins; 2318 del; 460 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From fbredberg at openjdk.org  Thu Nov  6 12:19:20 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 6 Nov 2025 12:19:20 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
Message-ID: <0Bp5MHdJNB3D3XZhG85m_clr-urKBKJ4StjZifsDTRg=.1ecc9574-3493-4a3e-8d7f-4aba5b9495ef@github.com>

On Wed, 5 Nov 2025 17:35:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Thank you for the reviews. Now let's...

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

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3496959325

From fbredberg at openjdk.org  Thu Nov  6 12:19:21 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 6 Nov 2025 12:19:21 GMT
Subject: Integrated: 8367982: Unify ObjectSynchronizer and
 LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <oNcbqD1fQv-fnS70SXCEvdZoHuqcvTc9uZa9BGtMiS8=.bcbca6ee-7f6b-465b-9b1a-b953e8c37f15@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

This pull request has now been integrated.

Changeset: 3930b1d4
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3930b1d4ddda9d56d0fb3626421283c72f4ad7f9
Stats:     2981 lines in 80 files changed: 1263 ins; 1429 del; 289 mod

8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Reviewed-by: pchilanomate, coleenp

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

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

From duke at openjdk.org  Thu Nov  6 14:05:15 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Nov 2025 14:05:15 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v9]
In-Reply-To: <91tUP7nn2ciUAGhkUxvWB_RcLOTrdti4uPa2AqUPzIU=.cc51aa81-590f-4dc0-9c42-a4b12bf8f37a@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <91tUP7nn2ciUAGhkUxvWB_RcLOTrdti4uPa2AqUPzIU=.cc51aa81-590f-4dc0-9c42-a4b12bf8f37a@github.com>
Message-ID: <c8exmwaqzNxSvJ2yHR0lOxoz5FtYAXQxbnX5IClUUpk=.caf5cad4-e7fc-4a70-b88e-63f25ad12481@github.com>

On Thu, 6 Nov 2025 11:16:58 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Erase obsolete comments
>  - Update src/jdk.hotspot.agent/doc/hsdb.html
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - fix comments
>  - Revert "run RotateLeftNode*IdealizationTests on amd64 too"
>    
>    This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.
>  - requires hsdis
>  - run RotateLeftNode*IdealizationTests on amd64 too
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/093e1287...7b67d1e8

@krk 
Your change (at version 7b67d1e8a04de7183c9b780cae26b1f2489e2e17) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27844#issuecomment-3497408352

From sspitsyn at openjdk.org  Thu Nov  6 14:43:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Nov 2025 14:43:13 GMT
Subject: RFR: 8371367: Replace remaining JvmtiJavaThreadEventTransition
 with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
In-Reply-To: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
References: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
Message-ID: <9Y8SOyUYCzAy-WycjlfcGzBjCnrJ3_yxY2FGxrnaAjk=.e15d5280-14f5-4801-b57f-72039c4a097d@github.com>

On Wed, 5 Nov 2025 20:50:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The one JvmtiJavaThreadEventTransition mark should be replaced with macro.
> 
> Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28165#pullrequestreview-3428520092

From shade at openjdk.org  Thu Nov  6 15:03:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Nov 2025 15:03:43 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v9]
In-Reply-To: <91tUP7nn2ciUAGhkUxvWB_RcLOTrdti4uPa2AqUPzIU=.cc51aa81-590f-4dc0-9c42-a4b12bf8f37a@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <91tUP7nn2ciUAGhkUxvWB_RcLOTrdti4uPa2AqUPzIU=.cc51aa81-590f-4dc0-9c42-a4b12bf8f37a@github.com>
Message-ID: <1cbkkn5KQJ2cnZYyH53ejSkev_Sw_4ykAnvYdfcl_Mw=.19c06250-7d59-44fa-9865-3809abd53b8b@github.com>

On Thu, 6 Nov 2025 11:16:58 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Erase obsolete comments
>  - Update src/jdk.hotspot.agent/doc/hsdb.html
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - fix comments
>  - Revert "run RotateLeftNode*IdealizationTests on amd64 too"
>    
>    This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.
>  - requires hsdis
>  - run RotateLeftNode*IdealizationTests on amd64 too
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/093e1287...7b67d1e8

Thanks! Let's go.

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

PR Comment: https://git.openjdk.org/jdk/pull/27844#issuecomment-3497660843

From krk at openjdk.org  Thu Nov  6 15:03:44 2025
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 6 Nov 2025 15:03:44 GMT
Subject: Integrated: 8351194: Clean up Hotspot SA after 32-bit x86 removal
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <QUbBgl7nkY9H_1fDVokdK38v3-oTLF96vOOCz9dUg7g=.6aa6160b-0fa7-487f-a6ea-ceda061a4572@github.com>

On Thu, 16 Oct 2025 10:05:08 GMT, Kerem Kat <krk at openjdk.org> wrote:

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

This pull request has now been integrated.

Changeset: 2d924ad3
Author:    Kerem Kat <krk at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d924ad3584a0ea8682f47c742dcdfd3be14937d
Stats:     2784 lines in 45 files changed: 623 ins; 2117 del; 44 mod

8351194: Clean up Hotspot SA after 32-bit x86 removal

Reviewed-by: cjplummer, shade, ayang, dholmes

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

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

From cjplummer at openjdk.org  Thu Nov  6 16:37:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 6 Nov 2025 16:37:24 GMT
Subject: RFR: 8371367: Replace remaining JvmtiJavaThreadEventTransition
 with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
In-Reply-To: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
References: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
Message-ID: <hgpQlfoNwkKDK0exDXykUKFlW4JGK3-sXBbPdHtbr38=.5fdd4c7a-5504-4cf6-a63c-f3abb0d82201@github.com>

On Wed, 5 Nov 2025 20:50:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The one JvmtiJavaThreadEventTransition mark should be replaced with macro.
> 
> Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28165#pullrequestreview-3429252368

From lmesnik at openjdk.org  Thu Nov  6 20:23:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 6 Nov 2025 20:23:15 GMT
Subject: Integrated: 8371367: Replace remaining JvmtiJavaThreadEventTransition
 with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
In-Reply-To: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
References: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
Message-ID: <HqtKR9FWNIUaQ9ODVGgzNNVAlI9xRijfh-6i5KK9ORw=.9af74c85-577c-4949-b0fa-5d85bcdace4d@github.com>

On Wed, 5 Nov 2025 20:50:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The one JvmtiJavaThreadEventTransition mark should be replaced with macro.
> 
> Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.

This pull request has now been integrated.

Changeset: 90ccdf29
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90ccdf2986b0e3705997fe31a23fd53c88a1bfaf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8371367: Replace remaining JvmtiJavaThreadEventTransition with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK

Reviewed-by: sspitsyn, cjplummer

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

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

From lmesnik at openjdk.org  Thu Nov  6 20:23:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 6 Nov 2025 20:23:13 GMT
Subject: RFR: 8371367: Replace remaining JvmtiJavaThreadEventTransition
 with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
In-Reply-To: <9Y8SOyUYCzAy-WycjlfcGzBjCnrJ3_yxY2FGxrnaAjk=.e15d5280-14f5-4801-b57f-72039c4a097d@github.com>
References: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>
 <9Y8SOyUYCzAy-WycjlfcGzBjCnrJ3_yxY2FGxrnaAjk=.e15d5280-14f5-4801-b57f-72039c4a097d@github.com>
Message-ID: <stMznmsVweCecCNkwUf-2tb55ZNbej7ehT7FSu4jAw0=.9e064271-61f7-42a5-8d73-0e1bbd4af975@github.com>

On Thu, 6 Nov 2025 14:40:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The one JvmtiJavaThreadEventTransition mark should be replaced with macro.
>> 
>> Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.
>
> Looks good.

@sspitsyn, @plummercj 
Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28165#issuecomment-3499238887

From lmesnik at openjdk.org  Thu Nov  6 21:33:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 6 Nov 2025 21:33:38 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
Message-ID: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>

The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.

The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.

The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.

Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
I am going to file separate RFE for this. 
Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

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

Commit messages:
 - 8371103: vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java failing

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

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

From amenkov at openjdk.org  Thu Nov  6 21:50:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Nov 2025 21:50:04 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <KytOlhCQQxsW3wHpp4HemKJC7MPSKthk_xZxh-tbgA8=.13430f42-0dfd-457a-a566-a76b674b796f@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28184#pullrequestreview-3430693825

From sspitsyn at openjdk.org  Thu Nov  6 22:31:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Nov 2025 22:31:02 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <_-7XKb0c-O5l0FmUztsbDj2NAAXeHhANS25nZFviFHg=.fd1ac36a-9450-4121-8a05-88a4e3593753@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28184#pullrequestreview-3430797067

From dlong at openjdk.org  Fri Nov  7 00:01:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 7 Nov 2025 00:01:29 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

We are seeing some new crashes ([JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388)) trying to access a PC that is just past the end of the nmethod and the page is unmapped because it also happens to be the last page of the CodeHeap.  Could it be related to the changes in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499890263

From duke at openjdk.org  Fri Nov  7 00:20:19 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 00:20:19 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
 <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>
Message-ID: <a3PldhvBpLPxAGLPBs-0tPMxSSBYxTXJBv2mRo2TIkM=.954278ed-ca1e-4e15-8a4f-2c0a8b6a3dfa@github.com>

On Thu, 6 Nov 2025 23:58:46 GMT, Dean Long <dlong at openjdk.org> wrote:

> We are seeing some new crashes ([JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388)) trying to access a PC that is just past the end of the nmethod and the page is unmapped because it also happens to be the last page of the CodeHeap. Could it be related to the changes in this PR?

Yes, I think it could be similar to the case fixed for AArch64 post-call NOP check earlier: https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L584 reads a 32-bit integer from the perceived call site. In case of the deoptimization handler, which is potentially located at the end of the code blob, the read would happen past the end of the code blob - which might cause the access to an unmapped page.

It could be replaced with the two-step comparison: first the comparison matching size of the `jmp` instruction (I believe that's 2 bytes), and if that's successful then comparison of the third byte as the second step. Alternatively, the specific deoptimization stub code could be extended by a `nop` in the `emit_deopt_handler`.

Would either of these options be suitable?

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499929974

From duke at openjdk.org  Fri Nov  7 00:50:27 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 00:50:27 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <FshSmNkcxww-JYqCueDtTIRMAfmoTiD6i0wNdzUunJk=.0eb2187d-2a71-42a5-9894-cafc27a5212e@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Indeed, the `jmp` size is `2` - I had incorrectly assumed it is `5` as specified here https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L412 however that's for a different case. The `10` as size of the deopt handler stub code at https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/x86.ad#L2774 is not correct either - it should be `7`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499993366

From thartmann at openjdk.org  Fri Nov  7 07:43:41 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 07:43:41 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
Message-ID: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>

Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).

Thanks,
Tobias

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

Commit messages:
 - Revert "8365047: Remove exception handler stub code in C2"

Changes: https://git.openjdk.org/jdk/pull/28187/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371388
  Stats: 569 lines in 41 files changed: 216 ins; 268 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/28187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28187/head:pull/28187

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

From thartmann at openjdk.org  Fri Nov  7 07:45:28 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 07:45:28 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <fjvYU_7dRq3NnQpBg2egiq7e2xK_fZVHrFXwY4Gsuec=.b7e410e5-ca00-4fc0-b9f9-f3f04cb6139a@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Backing out with https://github.com/openjdk/jdk/pull/28187.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3501135218

From thartmann at openjdk.org  Fri Nov  7 07:50:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 07:50:15 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v3]
In-Reply-To: <ZG83UmqRQlQ1_t4B4KZCgQO4CCXoNFJrckhIRc8oQLo=.dcb0cf71-bfe1-415d-8b69-d44f34f59d59@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
 <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
 <ZnFSViO4R9Bcp_qJryLWdqG6KK6yQm19rQb93ydgE5M=.3513d7b9-e9c9-489f-9f5c-8a1f5ffd3b8f@github.com>
 <ZG83UmqRQlQ1_t4B4KZCgQO4CCXoNFJrckhIRc8oQLo=.dcb0cf71-bfe1-415d-8b69-d44f34f59d59@github.com>
Message-ID: <uedUl6ednMGiZCsZdDXMZPd8TpbkAn0cTbrz0RF5Q48=.9fe962d3-9c50-4a95-a7e3-458e6c64d0b1@github.com>

On Mon, 27 Oct 2025 18:08:40 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> @chadrako, is PR ready for testing now?
>> 
>> Yes
>
>> @chadrako I think my suggestion was not correct. We should revert back to your first changes for `@requires`. Original code was correct and only `serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java` missed it.
> 
> Since the tests get run with different GCs anyways I don't think we need to explicitly require the GC that they run with and just have one test config

FTR, even with this fix, we still see failures: [JDK-8371121](https://bugs.openjdk.org/browse/JDK-8371121), [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046), [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150). @chadrako It would be great if you could prioritize fixing these remaining issues, as the failures cause quite some noise in our testing. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3501148078

From chagedorn at openjdk.org  Fri Nov  7 07:54:00 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 7 Nov 2025 07:54:00 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
In-Reply-To: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
Message-ID: <12t7qgPeVTYCh-u65W5b9CG7deELNKNQj_3jkcy9fbw=.3cb3afb1-4c99-4aea-9287-24dfb3ff5d2a@github.com>

On Fri, 7 Nov 2025 07:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
> 
> Thanks,
> Tobias

Looks good and trivial.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28187#pullrequestreview-3432114139

From epeter at openjdk.org  Fri Nov  7 07:57:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 7 Nov 2025 07:57:04 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
In-Reply-To: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
Message-ID: <nNA09qDJanjgSlIkYJKGp0HIQ5cjdNtIPjeMghy49eg=.66ddf02e-d77e-430f-8c60-d490bd8a4a99@github.com>

On Fri, 7 Nov 2025 07:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
> 
> Thanks,
> Tobias

Looks good to me, thanks for taking care of this!

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28187#pullrequestreview-3432123803

From thartmann at openjdk.org  Fri Nov  7 08:08:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 08:08:01 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
In-Reply-To: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
Message-ID: <bTvySEgXrAWmVVGNZFYxaZN0Ti86xwkbzrUuY3Ev4R0=.696f3bf1-1915-4fed-bf70-180fe24ffff2@github.com>

On Fri, 7 Nov 2025 07:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
> 
> Thanks,
> Tobias

Thanks for the quick reviews, Christian and Emanuel. Running sanity testing before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/28187#issuecomment-3501194557

From duke at openjdk.org  Fri Nov  7 09:03:03 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 09:03:03 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
In-Reply-To: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
Message-ID: <YJEuaIVnT6RFNIrQhvXVwejjnUv-RBMfdo0Aftj1wwA=.88e35fd9-28e5-4e4d-b5e0-dab39688b73d@github.com>

On Fri, 7 Nov 2025 07:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
> 
> Thanks,
> Tobias

I have a candidate patch that should address the reported failure from JDK-8371388. If preferred, I can open a PR with this fix as an alternative to reverting the original change. Please let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/28187#issuecomment-3501379345

From thartmann at openjdk.org  Fri Nov  7 09:20:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 09:20:17 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
In-Reply-To: <YJEuaIVnT6RFNIrQhvXVwejjnUv-RBMfdo0Aftj1wwA=.88e35fd9-28e5-4e4d-b5e0-dab39688b73d@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
 <YJEuaIVnT6RFNIrQhvXVwejjnUv-RBMfdo0Aftj1wwA=.88e35fd9-28e5-4e4d-b5e0-dab39688b73d@github.com>
Message-ID: <m4ycpTPcD3-xsmMgB1qR6jOfXq3fHCUlREjqB04cbKU=.0ffed6c6-ddbb-454d-89e2-02bb538eef87@github.com>

On Fri, 7 Nov 2025 09:00:48 GMT, Ruben <duke at openjdk.org> wrote:

>> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
>> 
>> Thanks,
>> Tobias
>
> I have a candidate patch that should address the reported failure from JDK-8371388. If preferred, I can open a PR with this fix as an alternative to reverting the original change. Please let me know.

Thanks @ruben-arm. Let's go with this clean back out for now - testing just came back clean. Once you have the REDO ready, I can submit some more sophisticated testing to make sure it addresses the issues we're seeing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28187#issuecomment-3501435282

From thartmann at openjdk.org  Fri Nov  7 09:20:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 09:20:18 GMT
Subject: Integrated: 8371388: [BACKOUT] JDK-8365047: Remove exception handler
 stub code in C2
In-Reply-To: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
References: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>
Message-ID: <1naK9sqlndcBD4rKhJm8zNEn1dMr-vwWOo4Qv4M2cxg=.17d0ade7-6c5f-4453-9fbf-cea4372ad1f8@github.com>

On Fri, 7 Nov 2025 07:36:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 48bbc950
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48bbc950f11113a57ea03f877bc3e526982c0eef
Stats:     569 lines in 41 files changed: 216 ins; 268 del; 85 mod

8371388: [BACKOUT] JDK-8365047: Remove exception handler stub code in C2

Reviewed-by: chagedorn, epeter

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

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

From eosterlund at openjdk.org  Fri Nov  7 10:11:08 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 7 Nov 2025 10:11:08 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v16]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <KxxzSTRlLYvsG2TWPxw8mstBJiWDD7QtRAz7aV5LEm0=.e846251a-e880-43d8-bb93-1762f0e0cc44@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Comment update
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - remove include
 - Interned string value word accounting
 - Dont load all objects when JVMTI CFLH is on
 - Remove duplicate string dedup disabling when dumping
 - Accept interned strings sharing value with another string
 - ... and 22 more: https://git.openjdk.org/jdk/compare/e34a8318...7e3dee89

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

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=15
  Stats: 8722 lines in 106 files changed: 5941 ins; 2318 del; 463 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From aboldtch at openjdk.org  Fri Nov  7 11:10:10 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 7 Nov 2025 11:10:10 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v16]
In-Reply-To: <KxxzSTRlLYvsG2TWPxw8mstBJiWDD7QtRAz7aV5LEm0=.e846251a-e880-43d8-bb93-1762f0e0cc44@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <KxxzSTRlLYvsG2TWPxw8mstBJiWDD7QtRAz7aV5LEm0=.e846251a-e880-43d8-bb93-1762f0e0cc44@github.com>
Message-ID: <stndk4Flreb7uG_vZlrUdyC7QzXcxUxK9DAWGmqoftg=.246b925f-95e0-4e4c-ba37-1a9c97b7d9c0@github.com>

On Fri, 7 Nov 2025 10:11:08 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Comment update
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - remove include
>  - Interned string value word accounting
>  - Dont load all objects when JVMTI CFLH is on
>  - Remove duplicate string dedup disabling when dumping
>  - Accept interned strings sharing value with another string
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/e34a8318...7e3dee89

Final merges looks good.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3433114312

From duke at openjdk.org  Fri Nov  7 11:14:58 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 11:14:58 GMT
Subject: RFR: 8371458: [REDO] - Remove exception handler stub code in C2
Message-ID: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>

The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.

The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.

According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

Commit messages:
 - x86: Fix post-call NOP check access outside code blob
 - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
 - Merge from the main branch
 - Address review comments and fix a mistype
 - Check for NOP and MOVK separately in NativePostCallNop
 - Test for deoptimization in virtual threads
 - Merge from the main branch
 - Address review comments
 - Address review comments
 - Address review comments
 - ... and 6 more: https://git.openjdk.org/jdk/compare/1922c4fd...7bb43523

Changes: https://git.openjdk.org/jdk/pull/28192/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371458
  Stats: 571 lines in 42 files changed: 269 ins; 216 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/28192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28192/head:pull/28192

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

From duke at openjdk.org  Fri Nov  7 11:19:03 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 11:19:03 GMT
Subject: RFR: 8371458: [REDO] - Remove exception handler stub code in C2
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <4Cyqe6dY27J8AnLfhLTyrliGYxnMdCJtAdGfJy2Ypxw=.cd37b689-667d-4e55-888b-fc4b7d440792@github.com>

On Fri, 7 Nov 2025 11:07:40 GMT, Ruben <duke at openjdk.org> wrote:

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

> Thanks @ruben-arm. Let's go with this clean back out for now - testing just came back clean. Once you have the REDO ready, I can submit some more sophisticated testing to make sure it addresses the issues we're seeing.

@TobiHartmann, I would appreciate it if you could initiate the extended testing for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3501950023

From thartmann at openjdk.org  Fri Nov  7 12:03:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 12:03:01 GMT
Subject: RFR: 8371458: [REDO] - Remove exception handler stub code in C2
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <ikeBOMyaijPJ58T40oHusToG_x_J1ly55ykFCgqC1h0=.8d8a6479-daaf-464f-a2e2-5eb3536fc988@github.com>

On Fri, 7 Nov 2025 11:07:40 GMT, Ruben <duke at openjdk.org> wrote:

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

Sure, I submitted testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3502158718

From eosterlund at openjdk.org  Fri Nov  7 12:57:49 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 7 Nov 2025 12:57:49 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v17]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <iGvNj4iZu0m0mC_8TG46NzCamhWWFdH7mLX8euEMvW8=.6e7a22ea-eefb-4de5-ae77-f31ad22b0d21@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Fix test group anomaly
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Comment update
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - remove include
 - Interned string value word accounting
 - Dont load all objects when JVMTI CFLH is on
 - ... and 24 more: https://git.openjdk.org/jdk/compare/167c952b...754006b5

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

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=16
  Stats: 8724 lines in 107 files changed: 5942 ins; 2318 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From aboldtch at openjdk.org  Fri Nov  7 12:57:49 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 7 Nov 2025 12:57:49 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v17]
In-Reply-To: <iGvNj4iZu0m0mC_8TG46NzCamhWWFdH7mLX8euEMvW8=.6e7a22ea-eefb-4de5-ae77-f31ad22b0d21@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <iGvNj4iZu0m0mC_8TG46NzCamhWWFdH7mLX8euEMvW8=.6e7a22ea-eefb-4de5-ae77-f31ad22b0d21@github.com>
Message-ID: <be0gv_PtpkZX-GRltWnHm1iRjeNkouIigfmyTM5lxRc=.ba41da4e-fd3b-41f9-97a1-c4d42ef336bd@github.com>

On Fri, 7 Nov 2025 12:54:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Fix test group anomaly
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Comment update
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - remove include
>  - Interned string value word accounting
>  - Dont load all objects when JVMTI CFLH is on
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/167c952b...754006b5

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3433727151

From eosterlund at openjdk.org  Fri Nov  7 14:50:52 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 7 Nov 2025 14:50:52 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v18]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Remove -server in test for static GHA build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/754006b5..84d79301

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=16-17

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

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

From aboldtch at openjdk.org  Fri Nov  7 14:50:53 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 7 Nov 2025 14:50:53 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v18]
In-Reply-To: <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
Message-ID: <X7kWC86qf8cBAZU05vLRwIHBEcmG_ncWcuIn8auq4BI=.301340f7-61c6-4c56-a943-5a81a922b389@github.com>

On Fri, 7 Nov 2025 14:47:07 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -server in test for static GHA build

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3434398193

From sgehwolf at openjdk.org  Fri Nov  7 15:28:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Nov 2025 15:28:01 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/2866c0a7..464d162f

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

  Stats: 17030 lines in 439 files changed: 10578 ins; 4853 del; 1599 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From eosterlund at openjdk.org  Fri Nov  7 15:28:46 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 7 Nov 2025 15:28:46 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v18]
In-Reply-To: <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
Message-ID: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com>

On Fri, 7 Nov 2025 14:50:52 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove -server in test for static GHA build

Thank you for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3503184650

From eosterlund at openjdk.org  Fri Nov  7 15:32:03 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 7 Nov 2025 15:32:03 GMT
Subject: Integrated: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <BQSSXdHH4DGKYbE1Aa991PQEJ4Mkf_pRkMJG3s-DY5c=.ceef8345-34b7-4326-a9d5-62f8373804c2@github.com>

On Thu, 9 Oct 2025 15:18:16 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

This pull request has now been integrated.

Changeset: c8656449
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8656449c28581ae9c3d815105e338e42253bb43
Stats:     8726 lines in 108 files changed: 5942 ins; 2318 del; 466 mod

8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC

Co-authored-by: Axel Boldt-Christmas <aboldtch at openjdk.org>
Co-authored-by: Joel Sikstr?m <jsikstro at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: aboldtch, iklam, kvn

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

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

From kvn at openjdk.org  Fri Nov  7 15:34:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 7 Nov 2025 15:34:27 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <4Cyqe6dY27J8AnLfhLTyrliGYxnMdCJtAdGfJy2Ypxw=.cd37b689-667d-4e55-888b-fc4b7d440792@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <4Cyqe6dY27J8AnLfhLTyrliGYxnMdCJtAdGfJy2Ypxw=.cd37b689-667d-4e55-888b-fc4b7d440792@github.com>
Message-ID: <TY4ICEN0uLsZjiVUzKyUUna9DV5KEPtcRNYNP3MS-9Q=.f56e0177-62c7-4f45-94aa-a38234459969@github.com>

On Fri, 7 Nov 2025 11:16:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
>> Thanks @ruben-arm. Let's go with this clean back out for now - testing just came back clean. Once you have the REDO ready, I can submit some more sophisticated testing to make sure it addresses the issues we're seeing.
> 
> @TobiHartmann, I would appreciate it if you could initiate the extended testing for this PR.

@ruben-arm what was the issue in the original changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3503214174

From duke at openjdk.org  Fri Nov  7 15:50:04 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 15:50:04 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <TY4ICEN0uLsZjiVUzKyUUna9DV5KEPtcRNYNP3MS-9Q=.f56e0177-62c7-4f45-94aa-a38234459969@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <4Cyqe6dY27J8AnLfhLTyrliGYxnMdCJtAdGfJy2Ypxw=.cd37b689-667d-4e55-888b-fc4b7d440792@github.com>
 <TY4ICEN0uLsZjiVUzKyUUna9DV5KEPtcRNYNP3MS-9Q=.f56e0177-62c7-4f45-94aa-a38234459969@github.com>
Message-ID: <rUaBG01y1O_uKjJYrpbA1sqPMiwNA2cvU_gOa8jnMIE=.7375c29e-785f-4cce-95c4-72349ba0d3f7@github.com>

On Fri, 7 Nov 2025 15:31:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Thanks @ruben-arm. Let's go with this clean back out for now - testing just came back clean. Once you have the REDO ready, I can submit some more sophisticated testing to make sure it addresses the issues we're seeing.
>> 
>> @TobiHartmann, I would appreciate it if you could initiate the extended testing for this PR.
>
> @ruben-arm what was the issue in the original changes?

@vnkozlov, the `NativePostCallNop::check` https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L584 was reading 4 bytes from the perceived call site.

That works when the check happens for an actual call site, as the post-call NOP sequence is always longer than 4 bytes.
However, it fails in case the return address in the stack frame, during deoptimization, is patched to point to the deoptimization stub code entry point.

With the change, the distance between the entry point and end of code blob can now be just 2 bytes - consequently the 4-bytes read would read outside the code blob.
The proposed fix is to split the read in the post-call NOP check into two 2-byte reads. If first read+comparison doesn't confirm it might be a post-call NOP sequence (it never will for the deoptimization stub code entry point) the second read wouldn't happen.

I initially missed this issue - having incorrectly concluded that the `jmp` at the entry point will take 5 bytes in size instead of 2 bytes.

https://github.com/openjdk/jdk/pull/28192/commits/7bb43523b3c9d1495d72a5bc75c3912c3f51e64c should address this issue by splitting the faulting read into two. It also adjusts the expected size of deoptimization handler stub code to 7 bytes in total instead of the incorrect estimate of 10 bytes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3503297153

From sgehwolf at openjdk.org  Fri Nov  7 17:43:18 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Nov 2025 17:43:18 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory limit
 fix in JDK-8370572
Message-ID: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>

Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.

The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.

Testing (all on Linux x86_64):
- [x] CG version 2, run as root. Engine: docker. Test is skipped.
- [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
- [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
- [X] CG version 1, run as non-root. Test skipped.
- [x] GHA, though I don't think this is very useful for this change.

Thoughts?

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

Commit messages:
 - 8370966: Create regression test for hierarchical memory limit fix in JDK-8370572

Changes: https://git.openjdk.org/jdk/pull/28201/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370966
  Stats: 191 lines in 8 files changed: 154 ins; 32 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28201/head:pull/28201

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

From sspitsyn at openjdk.org  Sat Nov  8 00:27:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 8 Nov 2025 00:27:20 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR:
 tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000)
Message-ID: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>

This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
 `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.

Testing:
 - TBD: Verify the test with mach5 test runs

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

Commit messages:
 - 8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

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

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

From duke at openjdk.org  Sat Nov  8 00:38:16 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Sat, 8 Nov 2025 00:38:16 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v3]
In-Reply-To: <ZG83UmqRQlQ1_t4B4KZCgQO4CCXoNFJrckhIRc8oQLo=.dcb0cf71-bfe1-415d-8b69-d44f34f59d59@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
 <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
 <ZnFSViO4R9Bcp_qJryLWdqG6KK6yQm19rQb93ydgE5M=.3513d7b9-e9c9-489f-9f5c-8a1f5ffd3b8f@github.com>
 <ZG83UmqRQlQ1_t4B4KZCgQO4CCXoNFJrckhIRc8oQLo=.dcb0cf71-bfe1-415d-8b69-d44f34f59d59@github.com>
Message-ID: <DoehW5krZ5jNsmTtHXMPnN9n5Y-FB2qyWqC9-gdhkMs=.230ad711-c0c1-4d22-be18-f21062e1a7d3@github.com>

On Mon, 27 Oct 2025 18:08:40 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> @chadrako, is PR ready for testing now?
>> 
>> Yes
>
>> @chadrako I think my suggestion was not correct. We should revert back to your first changes for `@requires`. Original code was correct and only `serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java` missed it.
> 
> Since the tests get run with different GCs anyways I don't think we need to explicitly require the GC that they run with and just have one test config

> FTR, even with this fix, we still see failures: [JDK-8371121](https://bugs.openjdk.org/browse/JDK-8371121), [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046), [JDK-8369150](https://bugs.openjdk.org/browse/JDK-8369150). @chadrako It would be great if you could prioritize fixing these remaining issues, as the failures cause quite some noise in our testing. Thanks!

@TobiHartmann I apologize for the noise and appreciate you bringing these to my attention. I am prioritizing the fixes and will keep the JBS issues updated with my progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3505482325

From syan at openjdk.org  Sat Nov  8 08:17:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 8 Nov 2025 08:17:39 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
Message-ID: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>

Hi all,

The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.

This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.

Change has been verified locally on linux-x64 by run the all touched tests.

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

Commit messages:
 - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Changes: https://git.openjdk.org/jdk/pull/28208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371503
  Stats: 39 lines in 11 files changed: 2 ins; 20 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208

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

From syan at openjdk.org  Sat Nov  8 08:23:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 8 Nov 2025 08:23:02 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000)
In-Reply-To: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
Message-ID: <FEKjaSADbGKhriv3zEqGUOmJSPKDCOZYHcViBXAf_6U=.27cd99b2-572a-43d8-baf0-4534e9d3aa3d@github.com>

On Sat, 8 Nov 2025 00:15:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
> 
> Testing:
>  - TBD: Verify the test with mach5 test runs

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp line 43:

> 41: 
> 42: #if (defined(WIN32) || defined(_WIN32))
> 43: static const jlong EXPECTED_ACCURACY = 32; // 16ms is longest clock update interval

Does the comment 16ms should be updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2506407679

From lmesnik at openjdk.org  Sat Nov  8 21:34:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 8 Nov 2025 21:34:11 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <pYjXk3JgsBrqbvTUuDXsZm16bsm5ZwJJQHr1PRarBaY=.0004afdf-3ae4-4f5e-8af6-3f321b47a542@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

@sspitsyn, @alexmenkov Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28184#issuecomment-3506944399

From lmesnik at openjdk.org  Sat Nov  8 21:34:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 8 Nov 2025 21:34:11 GMT
Subject: Integrated: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <FgY1YRwsG_XcZHqDgFM2YDz5nhlIjRA6fqqo7dqeUcs=.325aada8-b623-4a52-9fe6-c76536d5de6c@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

This pull request has now been integrated.

Changeset: 88c4678e
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88c4678eed818cbe9380f35352e90883fed27d33
Stats:     8 lines in 2 files changed: 4 ins; 4 del; 0 mod

8371103: vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java failing

Reviewed-by: amenkov, sspitsyn

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

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

From sspitsyn at openjdk.org  Sun Nov  9 10:30:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 9 Nov 2025 10:30:45 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
Message-ID: <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>

> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
> 
> Testing:
>  - TBD: Verify the test with mach5 test runs

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: restore original EXPECTED_ACCURACY for Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28206/files
  - new: https://git.openjdk.org/jdk/pull/28206/files/1df4f7d3..c53f9b40

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

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

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

From sspitsyn at openjdk.org  Sun Nov  9 10:30:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 9 Nov 2025 10:30:45 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <FEKjaSADbGKhriv3zEqGUOmJSPKDCOZYHcViBXAf_6U=.27cd99b2-572a-43d8-baf0-4534e9d3aa3d@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <FEKjaSADbGKhriv3zEqGUOmJSPKDCOZYHcViBXAf_6U=.27cd99b2-572a-43d8-baf0-4534e9d3aa3d@github.com>
Message-ID: <yfub4WHQmnLs2sS9UHg_Qk_PvAbLgjnHBOOEFxBVTUU=.853a807b-fa36-45f2-aa4d-b328e6cab74a@github.com>

On Sat, 8 Nov 2025 08:20:19 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: restore original EXPECTED_ACCURACY for Windows
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp line 43:
> 
>> 41: 
>> 42: #if (defined(WIN32) || defined(_WIN32))
>> 43: static const jlong EXPECTED_ACCURACY = 32; // 16ms is longest clock update interval
> 
> Does the comment 16ms should be updated.

Thank you for the comment. I've decided to restore the original `EXPECTED_ACCURACY` on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2507835929

From syan at openjdk.org  Mon Nov 10 06:24:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:24:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <HdeaUOSonudRRksAEEq9KmIMVMywA5lCi3LgEw__aHg=.1d680a89-f49a-43aa-bb84-8980cdab0603@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

test/hotspot/jtreg/containers/docker/TestMisc.java line 43:

> 41: import jdk.test.lib.process.OutputAnalyzer;
> 42: import jdk.test.lib.process.ProcessTools;
> 43: import jtreg.SkippedException;

Does this import 'import jtreg.SkippedException;' really needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508898251

From syan at openjdk.org  Mon Nov 10 06:43:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:43:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Before apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run failed. After apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run passed.

test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:

> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
> 150:             // value.
> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +

I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3441113583
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508932192

From syan at openjdk.org  Mon Nov 10 06:54:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:54:02 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 2:

> 1: /*
> 2:  * Copyright (C) 2025, IBM

Copyright (c) 2025 IBM Corporation. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2508961551

From sgehwolf at openjdk.org  Mon Nov 10 09:25:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 09:25:05 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
Message-ID: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>

On Mon, 10 Nov 2025 06:38:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
> 
>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>> 150:             // value.
>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
> 
> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509490319

From shade at openjdk.org  Mon Nov 10 09:26:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Nov 2025 09:26:06 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Looks fine, a few nits.

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 96:

> 94:         opts.addDockerOpts("--cgroup-parent=/" + cgroupParent);
> 95:         Common.run(opts)
> 96:             .shouldContain("Hierarchical Memory Limit is: " + expectedValue);

Indenting a a bit off here.

test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 107:

> 105:         Path sysFsMemory = Path.of("/", "sys", "fs", "cgroup", "memory");
> 106:         Path cgroupParentPath = sysFsMemory.resolve(cgroupParent);
> 107:         ProcessBuilder pb = new ProcessBuilder("mkdir", "-p", cgroupParentPath.toString());

So I am guessing we are fine with leaving this cgroup behind, after the test is done?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3441857489
PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509492642
PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509498605

From sgehwolf at openjdk.org  Mon Nov 10 09:29:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 09:29:01 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <a0H0mH4gtx3mH7cH68EjtJwPETNifusHmrtYBoIJN8c=.d6318db1-4ae8-44b5-b8f2-47352ec7c73c@github.com>
Message-ID: <0aHFgeT-Ikjw_Ad_evc1OoWZ97gBC-nD-_8UdoXiyO4=.ff3d18a7-35d1-4828-b8bb-3cd9db962283@github.com>

On Mon, 10 Nov 2025 09:23:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 107:
> 
>> 105:         Path sysFsMemory = Path.of("/", "sys", "fs", "cgroup", "memory");
>> 106:         Path cgroupParentPath = sysFsMemory.resolve(cgroupParent);
>> 107:         ProcessBuilder pb = new ProcessBuilder("mkdir", "-p", cgroupParentPath.toString());
> 
> So I am guessing we are fine with leaving this cgroup behind, after the test is done?

Yes. Unfortunately it's not easy to remove that. However, the test itself resets it to "unlimited" by setting the limit to `-1`. So it shouldn't make a difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2509510367

From syan at openjdk.org  Mon Nov 10 09:41:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 09:41:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
Message-ID: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>

On Mon, 10 Nov 2025 09:22:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
>> 
>>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>>> 150:             // value.
>>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
>> 
>> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'
>
> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509574859

From thartmann at openjdk.org  Mon Nov 10 10:16:06 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Nov 2025 10:16:06 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <ikeBOMyaijPJ58T40oHusToG_x_J1ly55ykFCgqC1h0=.8d8a6479-daaf-464f-a2e2-5eb3536fc988@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <ikeBOMyaijPJ58T40oHusToG_x_J1ly55ykFCgqC1h0=.8d8a6479-daaf-464f-a2e2-5eb3536fc988@github.com>
Message-ID: <7LtvXdcfrqOlHXnsZlsA5Kvf2RJXVt1I8IoVYz7Uj90=.eda5d489-7fbf-4051-88be-fd3c183761f6@github.com>

On Fri, 7 Nov 2025 12:00:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Sure, I submitted testing.

All testing passed. I leave it to the original reviewers to re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3510638686

From sgehwolf at openjdk.org  Mon Nov 10 10:22:07 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 10:22:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
 <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
Message-ID: <XW4XWiVMXxs8Mf4hzTxGEGfCnQ-v5WrEp2QJaoq2l40=.f42bb708-d928-4ed9-994e-f1e75ba9bdc4@github.com>

On Mon, 10 Nov 2025 09:38:32 GMT, SendaoYan <syan at openjdk.org> wrote:

>> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?
>
> So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

Yes, indeed. I'll remove it from `test/hotspot/jtreg/containers/docker/TestMisc.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509756250

From mdoerr at openjdk.org  Mon Nov 10 10:54:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Nov 2025 10:54:07 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <re5ECBmYsa2vwCr7uMCRpOxQgGlj9hkmXQk_FEHXaVA=.eed23f9f-3608-4d78-8a7e-ca09196b7f8b@github.com>

On Fri, 7 Nov 2025 11:07:40 GMT, Ruben <duke at openjdk.org> wrote:

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

I haven't checked the deopt handler size on x86. Otherwise, it still looks good to me.

src/hotspot/cpu/x86/nativeInst_x86.hpp line 585:

> 583:   };
> 584: 
> 585:   bool check() const { return short_at(0) == 0x1f0f && short_at(2) == 0x0084; }

Maybe a comment would be nice.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28192#pullrequestreview-3442431963
PR Review Comment: https://git.openjdk.org/jdk/pull/28192#discussion_r2509917846

From duke at openjdk.org  Mon Nov 10 13:00:55 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 10 Nov 2025 13:00:55 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - 8366659: Fixed whitespace.
 - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=03
  Stats: 374 lines in 3 files changed: 310 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From duke at openjdk.org  Mon Nov 10 14:27:52 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 10 Nov 2025 14:27:52 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <7LtvXdcfrqOlHXnsZlsA5Kvf2RJXVt1I8IoVYz7Uj90=.eda5d489-7fbf-4051-88be-fd3c183761f6@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <ikeBOMyaijPJ58T40oHusToG_x_J1ly55ykFCgqC1h0=.8d8a6479-daaf-464f-a2e2-5eb3536fc988@github.com>
 <7LtvXdcfrqOlHXnsZlsA5Kvf2RJXVt1I8IoVYz7Uj90=.eda5d489-7fbf-4051-88be-fd3c183761f6@github.com>
Message-ID: <qxJzRiZsI9YS3UMPrU-nITuUjK4ju_EOFrgYP1ig5Jg=.018b554c-21f1-4b47-a9b2-6053de530a04@github.com>

On Mon, 10 Nov 2025 10:13:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Sure, I submitted testing.
>
>> Sure, I submitted testing.
> 
> All testing passed. I leave it to the original reviewers to re-review.

Thanks, @TobiHartmann, for the extra tests, and apologies for missing this in the original PR.

@TheRealMDoerr, I will update the PR to add comments.

I am exploring a possibility to add a unit test for this issue, but I have not identified a deterministic way to make the deopt handler stub end at a page boundary.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3511994160

From cjplummer at openjdk.org  Mon Nov 10 17:10:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Nov 2025 17:10:31 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free vthread
 ThreadNodes
Message-ID: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>

This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.

This PR focuses on purging virtual thread ThreadNodes in two places:

1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"

At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.

Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.

At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.

Tested by running all tier2, tier5, and tier6 CI svc tests.

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

Commit messages:
 - update copyright
 - ThreadNode cleanup

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

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

From cjplummer at openjdk.org  Mon Nov 10 17:10:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Nov 2025 17:10:35 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <VE07rudD4VLE89rwv54WdTF-tvbNijrZbT0L_KLMkzM=.4521c51d-abd0-404a-808a-a37545abe7e5@github.com>

On Mon, 10 Nov 2025 03:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 431:

> 429:         }
> 430: #endif
> 431: 

I moved this to earlier in the function because at one point I was using the thread name in some debug printfs, and the thread name was being setup too late. I decided to keep it here just in case I need to do that again in the future.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1356:

> 1354:         } else {
> 1355:             *count = 0;
> 1356:         }

This change could use some explaining to help with the review. After this change the code is back to what it was before vthread support was added. This extra work was needed because sometimes the ThreadNode for the vthread did not already exist. Since now findRunningThread() will create the ThreadNode, there is no longer a need for this code to deal with it not existing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2508595620
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2508599927

From sgehwolf at openjdk.org  Mon Nov 10 17:43:02 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:02 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Indenting and copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28201/files
  - new: https://git.openjdk.org/jdk/pull/28201/files/86f8e1b8..faeff2a1

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

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

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

From sgehwolf at openjdk.org  Mon Nov 10 17:43:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:03 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <YMQBd3jKhOf-3EpB2EYiC-1_RB-hfyRyt_M0vEranrU=.515ae5d2-8f2f-4bcc-929c-ac7493e0f2e2@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

Thanks for the reviews. Updated the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/28201#issuecomment-3513094003

From sgehwolf at openjdk.org  Mon Nov 10 17:43:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:43:05 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <ASoh-fa6MT-uff-yqZsI6Dyq112cKXtEGYcWkN4ir04=.d29e6ef5-64e6-4826-a09f-ce47007e596e@github.com>
Message-ID: <1qZYZuODZnsxbV1e3S7_xemZyrGNBwtBuUns2K1hJrU=.c0282af9-4ed8-4b52-82f9-6b4f62b41ae8@github.com>

On Mon, 10 Nov 2025 06:51:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indenting and copyright
>
> test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2025, IBM
> 
> Copyright (c) 2025 IBM Corporation. All rights reserved.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28201#discussion_r2511417869

From shade at openjdk.org  Mon Nov 10 17:45:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Nov 2025 17:45:17 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <K6EsU8RCj9JycGg_Vid0pH9gfe3wqRxb6JP9Tq5TLZk=.a40ab45d-f446-4151-8fe3-8c074af7b227@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

Still good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3444430112

From sgehwolf at openjdk.org  Mon Nov 10 17:45:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:45:57 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove SkippedException import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/464d162f..8ba999a9

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

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

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

From amenkov at openjdk.org  Mon Nov 10 21:01:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 10 Nov 2025 21:01:53 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
Message-ID: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>

FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER

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

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

Commit messages:
 - fix

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

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

From acobbs at openjdk.org  Mon Nov 10 22:24:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 10 Nov 2025 22:24:52 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v5]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits:

 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=04
  Stats: 1667 lines in 35 files changed: 1492 ins; 49 del; 126 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From dcubed at openjdk.org  Tue Nov 11 02:44:26 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 11 Nov 2025 02:44:26 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
Message-ID: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>

On Mon, 10 Nov 2025 13:00:55 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - 8366659: Fixed whitespace.
>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4

Vaious minor nits here with a couple of queries about why
assert_mark_word_consistency calls were removed.

During my crawl through I ran into quite a few nits and typos,
but I'm putting those in a separate issue.

Thanks for adding two new sub-test cases for better coverage.

src/hotspot/share/runtime/objectMonitor.cpp line 533:

> 531: }
> 532: 
> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {

In the baseline also: `cm` is passed in, but it only used for this:
`assert(cm._monitor == this, "must be");`.

This makes me wonder if we're missing some code in `enter_with_contention_mark`
that is normally done when we are passed an `ObjectMonitorContentionMark`.

src/hotspot/share/runtime/objectMonitor.cpp line 1108:

> 1106:   assert(currentNode->_thread == current, "invariant");
> 1107:   assert(_waiters > 0, "invariant");
> 1108:   assert_mark_word_consistency();

Why remove call to `assert_mark_word_consistency();`?

src/hotspot/share/runtime/objectMonitor.cpp line 1186:

> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
> 1185:   assert(has_owner(current), "invariant");
> 1186:   assert_mark_word_consistency();

Why remove call to `assert_mark_word_consistency();`?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 387:

> 385:                 }
> 386:                 try { Thread.sleep(1000);
> 387:                 } catch(Exception e) {}

Nit: The `Thread.sleep` call should be on its own line after L386.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 452:

> 450: 
> 451:             try { Thread.sleep(1000);
> 452:             } catch(Exception e) {}

Nit: The Thread.sleep call should be on its own line after L451.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 506:

> 504:                 }
> 505:                 try { Thread.sleep(1000);
> 506:                 } catch(Exception e) {}

Nit: The Thread.sleep call should be on its own line after L505.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3444783084
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511785347
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511693213
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511698003
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512616795
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512620831
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512622710

From syan at openjdk.org  Tue Nov 11 02:57:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Nov 2025 02:57:08 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
Message-ID: <9_mUShL9w0WJOY_mRnI9Q6kjahjGy5C4r2nskAj84UU=.b998be5a-042f-4bcc-8eae-e5aaf485642c@github.com>

On Mon, 10 Nov 2025 17:45:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SkippedException import

This fix works for me

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3446022550

From syan at openjdk.org  Tue Nov 11 03:36:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Nov 2025 03:36:04 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <TG5MxAPNDtgIdqNZW3C75fGk6oL7ZxQt6CSa2CeLia8=.6e42a275-362c-42ad-a9c1-ea4afb83890d@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

The touch tests and new tests run passed on my local machine.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28201#pullrequestreview-3446098295

From lmesnik at openjdk.org  Tue Nov 11 03:58:21 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 03:58:21 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
Message-ID: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>

Please review following fix that move GC shutdown start after VM Death and agent's unloading.

The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.

The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

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

Commit messages:
 - 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence

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

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

From sgehwolf at openjdk.org  Tue Nov 11 09:21:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:21:43 GMT
Subject: RFR: 8370966: Create regression test for the hierarchical memory
 limit fix in JDK-8370572 [v2]
In-Reply-To: <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
 <OUDAZCbkETQoFlZUuKVpxJDWfewcfBByOfkn72kW-58=.a361005c-5423-40e0-aaa3-cede861a2e97@github.com>
Message-ID: <x8lwdeGS1I_9k2OWiS60WAnUSaYmKacg4melgyB6VJA=.79bbea30-d8b3-4357-922d-15baa07da462@github.com>

On Mon, 10 Nov 2025 17:43:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
>> 
>> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
>> 
>> Testing (all on Linux x86_64):
>> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
>> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
>> - [X] CG version 1, run as non-root. Test skipped.
>> - [x] GHA, though I don't think this is very useful for this change.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting and copyright

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28201#issuecomment-3515752649

From sgehwolf at openjdk.org  Tue Nov 11 09:21:45 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:21:45 GMT
Subject: Integrated: 8370966: Create regression test for the hierarchical
 memory limit fix in JDK-8370572
In-Reply-To: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
References: <DjSKh5zwGduGboF3jYBAHhuKYjKvpwn2xLo3_icyVnE=.c8adecaa-3446-4f89-85da-4eb8edc56475@github.com>
Message-ID: <mw60Y6T7DQnUia9RpJxCpX1oMigEbgmySAhgXT_-LBU=.79d5dadb-a6f3-4f2f-a1fd-35f9ed3009ae@github.com>

On Fri, 7 Nov 2025 16:41:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only enhancement. It creates a regression test for the Amazon ECS setup on cgroups v1 where the parent memory limit isn't visible inside the container and, thus, needs to rely on the cg v1 specific `hierarchical_memory_limit` token in `memory.stat`. The proposed test is cg v1 only and needs to be run as root. It's skipped otherwise. It's useful to have when working on refactorings like #27743  so as not to regress.
> 
> The other changes are an effort to reduce code duplication in the test code where similar patterns have been used in other container tests.
> 
> Testing (all on Linux x86_64):
> - [x] CG version 2, run as root. Engine: docker. Test is skipped.
> - [x] CG version 1, run as root. Engine: docker. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [x] CG version 1, run as root. Engine: podman. Test passes and fails without the product fix of [JDK-8370572](https://bugs.openjdk.org/browse/JDK-8370572)
> - [X] CG version 1, run as non-root. Test skipped.
> - [x] GHA, though I don't think this is very useful for this change.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 29100320
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/291003208c025ce4f9a94ba6093e207d0792bbb9
Stats:     191 lines in 8 files changed: 154 ins; 32 del; 5 mod

8370966: Create regression test for the hierarchical memory limit fix in JDK-8370572

Reviewed-by: shade, syan

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

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

From sgehwolf at openjdk.org  Tue Nov 11 09:57:39 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:57:39 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Remove SkippedException import
 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/8ba999a9..a2c6b160

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

  Stats: 152084 lines in 669 files changed: 106238 ins; 18592 del; 27254 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From ayang at openjdk.org  Tue Nov 11 10:06:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 10:06:14 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> move GC shutdown start after VM Death and agent's unloading

Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?

(The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3515988219

From stefank at openjdk.org  Tue Nov 11 10:25:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Nov 2025 10:25:43 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <0QVCSBQR8WrlEi7MbVIPpwgk5ndxBkTi7i-uK2z8P9U=.b105574d-980d-4303-9186-fece5e73f94d@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

I agree with Albert. I would prefer a patch that moves the JVMTI code instead. This is also what I've tested through tier1-8 in my queue of patches to clean up some of the shutdown code:
https://github.com/stefank/jdk/tree/remove_2s_shutdown_workaround

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3516108702

From sspitsyn at openjdk.org  Tue Nov 11 11:18:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Nov 2025 11:18:49 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>

On Mon, 10 Nov 2025 19:21:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1108:
> 
>> 1106:   assert(currentNode->_thread == current, "invariant");
>> 1107:   assert(_waiters > 0, "invariant");
>> 1108:   assert_mark_word_consistency();
> 
> Why remove call to `assert_mark_word_consistency();`?

Same question from me. :)

> src/hotspot/share/runtime/objectMonitor.cpp line 1186:
> 
>> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
>> 1185:   assert(has_owner(current), "invariant");
>> 1186:   assert_mark_word_consistency();
> 
> Why remove call to `assert_mark_word_consistency();`?

Same question from me. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513824738
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513824235

From duke at openjdk.org  Tue Nov 11 12:08:36 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 12:08:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
Message-ID: <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>

On Tue, 11 Nov 2025 11:15:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1108:
>> 
>>> 1106:   assert(currentNode->_thread == current, "invariant");
>>> 1107:   assert(_waiters > 0, "invariant");
>>> 1108:   assert_mark_word_consistency();
>> 
>> Why remove call to `assert_mark_word_consistency();`?
>
> Same question from me. :)

This assert only works in a non-blocked state. The call to `reenter_internal` is now done in a blocked state, I also changed the assertion on the state from `!=` to `==` a few lines above it. 

`assert_mark_word_consistency()` calls `object()` which calls `check_object_context()`, which can pass only if the state is either `_thread_in_vm` or `_thread_in_Java`. Since the call is now made from a blocked state, the assert has to be removed. 

`assert_mark_word_consistency()` is called after the thread is back to a non-blocked state.

>> src/hotspot/share/runtime/objectMonitor.cpp line 1186:
>> 
>>> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
>>> 1185:   assert(has_owner(current), "invariant");
>>> 1186:   assert_mark_word_consistency();
>> 
>> Why remove call to `assert_mark_word_consistency();`?
>
> Same question from me. :)

Same answer as above, it only works in a non-blocked state, but that is no longer the case here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513991947
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513993815

From duke at openjdk.org  Tue Nov 11 12:40:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 12:40:44 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>

On Mon, 10 Nov 2025 19:53:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> src/hotspot/share/runtime/objectMonitor.cpp line 533:
> 
>> 531: }
>> 532: 
>> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {
> 
> In the baseline also: `cm` is passed in, but it only used for this:
> `assert(cm._monitor == this, "must be");`.
> 
> This makes me wonder if we're missing some code in `enter_with_contention_mark`
> that is normally done when we are passed an `ObjectMonitorContentionMark`.

Yes, in `enter_with_contention_mark` the mark itself is only for assertion. I agree that is not clear, if there is any issue popping up, we can address it in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514088683

From duke at openjdk.org  Tue Nov 11 13:13:29 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:13:29 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v5]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <7LWuJgkzmagjtR5L5LQxskLT-zyMJKrPsFKy9VRjNF4=.36d14e51-9d61-4cbc-b24b-6d68208158a5@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Fixed lines in tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/31482ba4..7f26302e

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

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

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

From duke at openjdk.org  Tue Nov 11 13:13:34 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:13:34 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <LuYRe1Gq0xauwWf07K8Qyj4G5cDhqWTPfxTSMtdpGFQ=.0e8d0a61-830f-423d-9553-36ce10960036@github.com>

On Tue, 11 Nov 2025 02:33:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 452:
> 
>> 450: 
>> 451:             try { Thread.sleep(1000);
>> 452:             } catch(Exception e) {}
> 
> Nit: The Thread.sleep call should be on its own line after L451.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 506:
> 
>> 504:                 }
>> 505:                 try { Thread.sleep(1000);
>> 506:                 } catch(Exception e) {}
> 
> Nit: The Thread.sleep call should be on its own line after L505.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514175972
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514176496

From duke at openjdk.org  Tue Nov 11 13:53:36 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:53:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <D1JFQspsIPPkFVsxI3RgohU2JexIslgudEuV_4negfE=.1b6fee36-8634-4b05-a8bb-97da780e29ff@github.com>

On Tue, 11 Nov 2025 02:31:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 387:
> 
>> 385:                 }
>> 386:                 try { Thread.sleep(1000);
>> 387:                 } catch(Exception e) {}
> 
> Nit: The `Thread.sleep` call should be on its own line after L386.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514310008

From lmesnik at openjdk.org  Tue Nov 11 17:26:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 17:26:34 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v2]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <WuEpIa7R-e5BECyQgh4Ecyf1zFW4Wg0NNg0hklVTgiY=.6bae8127-ad2a-4728-bf7b-4cfb672cf2b1@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  moved jvmti/gc coce

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/a49d67ca..e728034d

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

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

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

From lmesnik at openjdk.org  Tue Nov 11 17:45:27 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 17:45:27 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v3]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <y87T3KsrPbenVRo0yCDQCtn4HZFcO-vK747sfcPBycA=.53382245-d0cf-48a3-a869-369de6846656@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  moving

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/e728034d..be6eb483

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

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

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

From ayang at openjdk.org  Tue Nov 11 17:50:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 17:50:43 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
Message-ID: <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>

> Trivial removing obsoleted code for unsupported arch.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28240/files
  - new: https://git.openjdk.org/jdk/pull/28240/files/03330ac2..0e447848

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

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

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

From ayang at openjdk.org  Tue Nov 11 17:50:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 17:50:44 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com>
Message-ID: <EEUA-hYnutyKLYkcxPhGuMk6mqM_TyXQtAgFkQvbduU=.b454305f-1e2f-4437-a6ad-1a9a2aee12ef@github.com>

On Tue, 11 Nov 2025 16:16:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> What happens if TLAB is at the end of heap page? Are you sure "prefetch" instructions on all OpenJDK platforms can touch unmapped memory? I see PPC can use AllocatePrefetchStyle == 3.

In every `<arch>.ad` file, there is `// Must be safe to execute with invalid address (cannot fault)` for prefetching.

I searched online that all currently supported platforms don't fault on prefetching invalid addresses.

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3518048288

From lmesnik at openjdk.org  Tue Nov 11 18:15:23 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 18:15:23 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  dot added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/be6eb483..6d367b4a

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

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

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

From lmesnik at openjdk.org  Tue Nov 11 18:33:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 18:33:04 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>
Message-ID: <naK6lKFlGDVOuWTfMy_Hf1qHiPPGxgrHQu2bWI1JihQ=.4a71b2a8-60d8-4ba8-b736-1bc690666fa2@github.com>

On Tue, 11 Nov 2025 10:03:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
>> move GC shutdown start after VM Death and agent's unloading
> 
> Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?
> 
> (The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.)

@albertnetymk, @stefank 

> > move GC shutdown start after VM Death and agent's unloading
> 
> Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?

I updated to move jvmti code. Seems that following opertaions
  WatcherThread::stop();
  NativeHeapTrimmer::cleanup(); 
might be done before sending jvmti vm_death.

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3518247296

From ayang at openjdk.org  Tue Nov 11 19:05:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 19:05:04 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <r-qyaOQu-GJxX3KyVYwWlxHXxrYfNiGlUdcfyFL1Uls=.e5c240a8-6ffb-445e-8dd6-e63096f040fb@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3449515538

From stefank at openjdk.org  Wed Nov 12 07:53:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 07:53:05 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <pv2J4Fp2x-vZq3IzCJVr_fqjhEthtQcAbxeEnJL7mWA=.6a957dad-42ed-4cb8-9366-c6ff436bbb0f@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Looks good and thanks for the test!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452083212

From iwalulya at openjdk.org  Wed Nov 12 08:39:05 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 12 Nov 2025 08:39:05 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <BJzN8ZpFEIVPLk8KfCn2ihF5ZMxUBJ9QOtTTaIfrzNQ=.60b9c93c-092c-49f6-a95e-657240948f13@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452233407

From duke at openjdk.org  Wed Nov 12 13:29:07 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 12 Nov 2025 13:29:07 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed lines in tests.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=05
  Stats: 377 lines in 3 files changed: 313 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aboldtch at openjdk.org  Wed Nov 12 14:06:32 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 12 Nov 2025 14:06:32 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <kRomgJ1rFIcPsIVDtUdACYKSX-dk_IKMeg0qMY0iEqU=.3d5a1146-f760-464e-a5ca-6c347eca9610@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3453617541

From kvn at openjdk.org  Wed Nov 12 15:24:30 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Nov 2025 15:24:30 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
Message-ID: <_iaflU1ISP1m0TQKu8cUvnyQ6NQ92xs4tI1Mqs6H3E8=.9e55e39f-b852-4604-acb4-ec9f3dedd014@github.com>

On Tue, 11 Nov 2025 17:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I ran our testing (tier1-5) and there are no new failures. So I approve this change.
But you need second review. Preferable from other platforms supporters (RISC-V, PPC64, s390)

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28240#pullrequestreview-3454014494

From cnorrbin at openjdk.org  Wed Nov 12 15:42:24 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 12 Nov 2025 15:42:24 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
Message-ID: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>

On Tue, 11 Nov 2025 09:57:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Remove SkippedException import
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Looks good! We are also starting to see tests failing. Some of the new tests fail on rootless cgroup v1 configurations, see comment.

test/hotspot/jtreg/containers/docker/TestMisc.java line 107:

> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
> 107:         printContainerInfo(1052, 1024, true);

These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
`Resource limits are not supported and ignored on cgroups V1 rootless systems`
and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3454095579
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2518801888

From sgehwolf at openjdk.org  Wed Nov 12 16:40:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 16:40:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
Message-ID: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>

On Wed, 12 Nov 2025 15:36:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Remove SkippedException import
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
> 
>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>> 107:         printContainerInfo(1052, 1024, true);
> 
> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519021505

From dcubed at openjdk.org  Wed Nov 12 17:17:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 17:17:18 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>
Message-ID: <88Sy8kwrXhq7vxLgsKOghkK51dK06psHKkJkcjtayV4=.6895c4a5-02ae-44dc-b620-3d9890078fa3@github.com>

On Tue, 11 Nov 2025 12:37:57 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 533:
>> 
>>> 531: }
>>> 532: 
>>> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {
>> 
>> In the baseline also: `cm` is passed in, but it only used for this:
>> `assert(cm._monitor == this, "must be");`.
>> 
>> This makes me wonder if we're missing some code in `enter_with_contention_mark`
>> that is normally done when we are passed an `ObjectMonitorContentionMark`.
>
> Yes, in `enter_with_contention_mark` the mark itself is only for assertion. I agree that is not clear, if there is any issue popping up, we can address it in a separate PR.

I took another look and since we don't do anything with `DEFLATER_MARKER`
in this code path, I concur that we are not missing any code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519150311

From dcubed at openjdk.org  Wed Nov 12 17:17:19 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 17:17:19 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
 <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>
Message-ID: <T9XYl901YPq1pIVmw3e5GIWZHBg_EVUbatUd5_YwTOY=.f25faea6-2fc8-4e5b-aa94-740a3a43e92b@github.com>

On Tue, 11 Nov 2025 12:05:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Same question from me. :)
>
> This assert only works in a non-blocked state. The call to `reenter_internal` is now done in a blocked state, I also changed the assertion on the state from `!=` to `==` a few lines above this line. 
> 
> `assert_mark_word_consistency()` calls `object()` which calls `check_object_context()`, which can pass only if the state is either `_thread_in_vm` or `_thread_in_Java`. Since the call is now made from a blocked state, the assert has to be removed. 
> 
> `assert_mark_word_consistency()` is called after the thread is back to a non-blocked state.

Thanks for the explanation!

Please add a comment above line 341:


// Can only be called from _thread_in_vm or _thread_in_Java due to object() call:
341: #define assert_mark_word_consistency()                                         \
342:   assert(UseObjectMonitorTable || object()->mark() == markWord::encode(this),  \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519143235

From cjplummer at openjdk.org  Wed Nov 12 18:24:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Nov 2025 18:24:38 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
Message-ID: <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>

On Sun, 9 Nov 2025 10:30:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
>> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
>> 
>> Testing:
>>  - TBD: Verify the test with mach5 test runs
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: restore original EXPECTED_ACCURACY for Windows

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp line 45:

> 43: static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock update interval
> 44: #else
> 45: static const jlong EXPECTED_ACCURACY = 32; // high frequency clock updates expected

The comments are somewhat misleading now. We choose 16 on WIN32 because that is the smallest interval allowed. We expect better clock refinement on other platforms and therefore better accuracy. Thus 10ms was chosen. Now we have one test case that was just over 16ms. Is there a reason to believe that couldn't happen with WIN32 also. If not, then the comments should reflect that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2519348665

From sspitsyn at openjdk.org  Wed Nov 12 18:33:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 12 Nov 2025 18:33:46 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <CLJ_kjOEHbkHTtR-9PWNvA47lYgoxsOy1I5Q-F0FerU=.31a7e113-6103-4ee4-a3cd-b505e609b68b@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Looks good. Thank you for fixing this issue!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3454892220

From lmesnik at openjdk.org  Wed Nov 12 18:58:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Nov 2025 18:58:04 GMT
Subject: Integrated: 8367902: Allocation after Universe::before_exit() in the
 VM shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <x05j3QvDn2P4VgFmEBRWUKGb8-9gOAZ_dyjkQhWv_uo=.a8cf6064-a3b1-47e9-b6e3-42cb247b9028@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

This pull request has now been integrated.

Changeset: 705bd6fb
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/705bd6fbdc0e78625d05dbfa8af547c50b076e69
Stats:     161 lines in 3 files changed: 151 ins; 9 del; 1 mod

8367902: Allocation after Universe::before_exit() in the VM shutdown sequence

Reviewed-by: ayang, stefank, iwalulya, aboldtch, sspitsyn

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

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

From dcubed at openjdk.org  Wed Nov 12 20:09:31 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 20:09:31 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

I've done another crawl thru review. Thanks for making changes after the first
round of comments. In this crawl-thru, my deep focus was on the modified test.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 297:

> 295:     }
> 296: 
> 297:     // Notify the resumer while holding the threadLock

Nit: please add a period at the end of this sentence.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:

> 370:                 // - a threadLock enter in the resumer thread
> 371:                 // - resumption of the waiter thread
> 372:                 // - a threadLock enter in the freshly resumed waiter thread

This list of step tests is identical to the list on L490 -> L493 and the
original llist on L256 -> L259.

This step comment:
`370:               // - a threadLock enter in the resumer thread`
should be updated to something like:

             // - a blocked threadLock enter in the resumer thread while the
             //   threadLock is held by the main thread.


This change of threadLock scope also requires this update from:

605:        // - tries to grab the threadLock (should not block!)


to:

605:        // - tries to grab the threadLock (should not block with doWork1!)

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:

> 386:                 try {
> 387:                     Thread.sleep(1000);
> 388:                 } catch(Exception e) {}

Why is this 1 second delay needed?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:

> 426:             // launch the waiter thread
> 427:             synchronized (barrierLaunch) {
> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);

This change to `wait` for `1` instead of `0` requires this comment to be updated from:

                // TS_READY_TO_NOTIFY is set after the main thread has
                // entered threadLock so a spurious wakeup can't get the
                // waiter thread out of this threadLock.wait(0) call:

to:

                // TS_READY_TO_NOTIFY is set after the main thread has
                // entered threadLock so a spurious wakeup can't get the
                // waiter thread out of this threadLock.wait(0) call in
                // doWork1 or doWork2. doWork3 passes a one so that the
                // wait() can terminate early and block on reentry.


I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
of a `notify()` from the main thread. 

In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
thread contends on threadsLock and finally the main thread suspends the worker thread.
The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
might get to re-entry block on threadsLock via a timeout instead of a notify.

What am I missing here?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:

> 452:             try {
> 453:                 Thread.sleep(1000);
> 454:             } catch(Exception e) {}

Why is this 1 second delay needed?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:

> 491:                 // - a threadLock enter in the resumer thread
> 492:                 // - resumption of the waiter thread
> 493:                 // - a threadLock enter in the freshly resumed waiter thread

This list of step tests is identical to the list on L369 -> L372 and the
original llist on L256 -> L259.

This step comment:

491:               // - a threadLock enter in the resumer thread

should be updated to something like:

             // - a blocked threadLock enter in the resumer thread while the
             //   threadLock is held by the main thread.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:

> 507:                 try {
> 508:                     Thread.sleep(1000);
> 509:                 } catch(Exception e) {}

Why is this 1 second delay needed?

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3454633483
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519187101
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519214534
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519476007
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519522596
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519194484
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519205810
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519483650

From dcubed at openjdk.org  Wed Nov 12 20:09:32 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 20:09:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
Message-ID: <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>

On Wed, 12 Nov 2025 17:36:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:
> 
>> 370:                 // - a threadLock enter in the resumer thread
>> 371:                 // - resumption of the waiter thread
>> 372:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L490 -> L493 and the
> original llist on L256 -> L259.
> 
> This step comment:
> `370:               // - a threadLock enter in the resumer thread`
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.
> 
> 
> This change of threadLock scope also requires this update from:
> 
> 605:        // - tries to grab the threadLock (should not block!)
> 
> 
> to:
> 
> 605:        // - tries to grab the threadLock (should not block with doWork1!)

I can't figure out why we're delaying the resumer thread in `doWork2`.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:
> 
>> 491:                 // - a threadLock enter in the resumer thread
>> 492:                 // - resumption of the waiter thread
>> 493:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L369 -> L372 and the
> original llist on L256 -> L259.
> 
> This step comment:
> 
> 491:               // - a threadLock enter in the resumer thread
> 
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.

I can't figure out why we're delaying the resumer thread in `doWork3`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519645665
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519646704

From sgehwolf at openjdk.org  Wed Nov 12 20:28:41 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:41 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Fix TestMisc for podman on cg v1 in rootless mode.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/a2c6b160..9417bdbe

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

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

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

From sgehwolf at openjdk.org  Wed Nov 12 20:28:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
 <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
Message-ID: <F44-sGqpPOFeUpz7wsxljtDtFiDzBaYwQ93l6faWR6g=.15546430-d8be-4459-82bb-a41c5a16e82c@github.com>

On Wed, 12 Nov 2025 16:37:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
>> 
>>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>>> 107:         printContainerInfo(1052, 1024, true);
>> 
>> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
>> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
>> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.
>
> OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

Should be fixed in the update with: https://github.com/openjdk/jdk/pull/28157/commits/9417bdbeb4d458489953a54d253e8f79dc678734

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519710367

From sspitsyn at openjdk.org  Wed Nov 12 22:49:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 12 Nov 2025 22:49:06 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
 <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
Message-ID: <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>

On Wed, 12 Nov 2025 18:22:05 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: restore original EXPECTED_ACCURACY for Windows
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp line 45:
> 
>> 43: static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock update interval
>> 44: #else
>> 45: static const jlong EXPECTED_ACCURACY = 32; // high frequency clock updates expected
> 
> The comments are somewhat misleading now. We choose 16 on WIN32 because that is the smallest interval allowed. We expect better clock refinement on other platforms and therefore better accuracy. Thus 10ms was chosen. Now we have one test case that was just over 16ms. Is there a reason to believe that couldn't happen with WIN32 also. If not, then the comments should reflect that.

I feel that all these checks are just a source of this test instability. :)
I'm not sure I fully understand why those are needed and what was the original design. It is always possible to have some delays in waiting time, so the original assumptions about expected accuracy are not fully correct as they are a little bit overly strong.
>From this point of view, I do not see why the comments are confusing. The `EXPECTED_ACCURACY` values are just based on the high frequency clock updates interval but should not be equal to it.
Would you like me to change the comments to something like below ? :
  `high frequency clock updates expected`
    =>
  `expected accuracy is based on high frequency clock updates`
  I do not want to change the Windows part until any failure is observed but can update the comment for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2520042629

From sspitsyn at openjdk.org  Wed Nov 12 23:36:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 12 Nov 2025 23:36:02 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
In-Reply-To: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
Message-ID: <MDteIivp7h02zH-XVFVC8UfV3Rey6CYSqL25X6yZyWY=.24b1001f-ded1-46b2-b519-bde884ad5faf@github.com>

On Mon, 10 Nov 2025 20:54:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
> 
> Testing: tier1..4,hs-tier5-svc

The fix looks good. I've posted a couple of nits.

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

> 2191: };
> 2192: 
> 2193: // A supporting closure used to process ClassLoaderData roots

Nit: Need dot at the end of comment.

test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 79:

> 77: 
> 78:   for (int i = 0; i < class_counter; i++) {
> 79:     tags[i] = i+1;

Nit: Need spaces around `+` sign.

test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 101:

> 99: }
> 100: 
> 101: 

Nit: Unneeded extra empty line.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28224#pullrequestreview-3455948919
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2520165317
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2520125928
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2520132469

From lmesnik at openjdk.org  Thu Nov 13 02:57:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 02:57:34 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni
Message-ID: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>

Please review following fix that adds jni exception check after calling java code. 

Tested by running test with and without -Xcheck:jni.

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

Commit messages:
 - 8371749: New test serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java fails with -Xcheck:jni

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

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

From sspitsyn at openjdk.org  Thu Nov 13 06:36:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 13 Nov 2025 06:36:01 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni
In-Reply-To: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
Message-ID: <hr6JpTG5KgHe1QY6h_HfTz4Gy6FDkDJKXj6mse1z78E=.a38b1e2d-1c29-4e80-8a84-5b9aacb1b2d7@github.com>

On Thu, 13 Nov 2025 02:51:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adds jni exception check after calling java code. 
> 
> Tested by running test with and without -Xcheck:jni.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28280#pullrequestreview-3457775471

From sspitsyn at openjdk.org  Thu Nov 13 07:04:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 13 Nov 2025 07:04:03 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni
In-Reply-To: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
Message-ID: <W2dPHGPKd4oM14Z0zRO_8RqtoT2gbOkb_9E-yWx7E6E=.3d65f8e7-3d78-4af4-9e10-a2f08aa20770@github.com>

On Thu, 13 Nov 2025 02:51:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adds jni exception check after calling java code. 
> 
> Tested by running test with and without -Xcheck:jni.

test/hotspot/jtreg/serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/libTestAllocatingInVMDeath.cpp line 42:

> 40:   if (jni->ExceptionOccurred()) {
> 41:     jni->ExceptionDescribe();
> 42:     fatal(jni, "Unexpected exception occured in cbVMDeath.");

Nit: Typo: `s/occured/occurred/`
Also, this message is confusing. Unexpected exception occurred in Java upcall made from the cbVMDeath.
Maybe something like this: "cbVMDeath: unexpected exception occurred in Java upcall method".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28280#discussion_r2521900137

From lmesnik at openjdk.org  Thu Nov 13 07:54:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 07:54:42 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni [v2]
In-Reply-To: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
Message-ID: <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>

> Please review following fix that adds jni exception check after calling java code. 
> 
> Tested by running test with and without -Xcheck:jni.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  error message fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28280/files
  - new: https://git.openjdk.org/jdk/pull/28280/files/8d539f86..12828417

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

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

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

From duke at openjdk.org  Thu Nov 13 07:58:14 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 13 Nov 2025 07:58:14 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <-h6G9ajUWQwDRcUMOtyI_YCUCkXz3pzRggJk_UaxM-0=.a8c772aa-2f09-48c0-9cfb-17e624393eb0@github.com>

On Fri, 7 Nov 2025 11:07:40 GMT, Ruben <duke at openjdk.org> wrote:

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

I am planning to update this PR today to include the comments.
However, I still have not identified a way to ensure the deopt handler stub ends at a page boundary in a unit test.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3526178620

From ysuenaga at openjdk.org  Thu Nov 13 08:25:46 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 13 Nov 2025 08:25:46 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing
Message-ID: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>

We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.

This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.

Big thanks to @pchilano for your help!

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

Commit messages:
 - 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java failing

Changes: https://git.openjdk.org/jdk/pull/28284/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28284&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371194
  Stats: 230 lines in 10 files changed: 117 ins; 39 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/28284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28284/head:pull/28284

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

From cnorrbin at openjdk.org  Thu Nov 13 09:05:32 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 13 Nov 2025 09:05:32 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <fF1hoR6uoYPtBN7Dy1V6wsoo3N6Yu69Ha_6qEOj9npI=.7a1c0dce-1c66-4a3a-936e-f134a45e7aae@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

LGTM

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

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3458531316

From mdoerr at openjdk.org  Thu Nov 13 09:34:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 13 Nov 2025 09:34:05 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
Message-ID: <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>

On Tue, 11 Nov 2025 17:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

We have seen crashes on many platforms (including x64) while running `make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`:

SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557
V  [libjvm.so+0x15bfe7a]  MemAllocator::finish(HeapWordImpl**) const+0xca  (klass.inline.hpp:72)
V  [libjvm.so+0x15c029f]  ObjAllocator::initialize(HeapWordImpl**) const+0x2f  (memAllocator.cpp:391)
V  [libjvm.so+0xb0630b]  CollectedHeap::fill_with_object(HeapWordImpl**, unsigned long, bool)+0x27b  (collectedHeap.cpp:491)
V  [libjvm.so+0x1c7a0bb]  ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b  (threadLocalAllocBuffer.cpp:118)
V  [libjvm.so+0x15c0b14]  MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x84  (memAllocator.cpp:286)
V  [libjvm.so+0x15c13ab]  MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb  (memAllocator.cpp:340)
V  [libjvm.so+0x15c14f9]  MemAllocator::allocate() const+0xa9  (memAllocator.cpp:353)
V  [libjvm.so+0x1cc052e]  TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13e  (collectedHeap.inline.hpp:41)
V  [libjvm.so+0x16fbc98]  oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38  (typeArrayKlass.hpp:51)
V  [libjvm.so+0x106b0f3]  java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0x413  (javaClasses.cpp:1246)
V  [libjvm.so+0x14100bc]  Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x66c  (klass.cpp:903)
V  [libjvm.so+0xfe2cb1]  InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81  (instanceKlass.cpp:2823)
V  [libjvm.so+0x1c0f5ad]  SystemDictionary::preload_class(Handle, InstanceKlass*, JavaThread*)+0x1ed  (systemDictionary.cpp:1198)
V  [libjvm.so+0x676e83]  AOTLinkedClassBulkLoader::preload_classes_in_table(Array<InstanceKlass*>*, char const*, Handle, JavaThread*)+0x1a3  (aotLinkedClassBulkLoader.cpp:103)
V  [libjvm.so+0x679af5]  AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165  (aotLinkedClassBulkLoader.cpp:76)
V  [libjvm.so+0x67c371]  AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11  (aotLinkedClassBulkLoader.cpp:61)
V  [libjvm.so+0x1d5bf30]  vmClasses::resolve_all(JavaThread*)+0x3e0  (vmClasses.cpp:126)
V  [libjvm.so+0x1c0f28c]  SystemDictionary::initialize(JavaThread*)+0x10c  (systemDictionary.cpp:1623)
V  [libjvm.so+0x1cc74ca]  Universe::genesis(JavaThread*)+0xfa  (universe.cpp:451)
V  [libjvm.so+0x1ccbbf5]  universe2_init()+0x35  (universe.cpp:1119)
V  [libjvm.so+0xfd5709]  init_globals2()+0x9  (init.cpp:173)
V  [libjvm.so+0x1c926b1]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x3a1  (threads.cpp:622)
V  [libjvm.so+0x118b634]  JNI_CreateJavaVM+0x54  (jni.cpp:3591)
C  [libjli.so+0x3d7f]  JavaMain+0x8f  (java.c:1506)
C  [libjli.so+0x7ad9]  ThreadJavaMain+0x9  (java_md.c:646)

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3526748535

From sspitsyn at openjdk.org  Thu Nov 13 10:00:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 13 Nov 2025 10:00:17 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni [v2]
In-Reply-To: <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
 <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
Message-ID: <WsOeTjyScsaiv1bqRxDEFkIzLGLqJkQJdbfFO2DJecE=.4b7e27da-a677-48be-b62a-9c718a8fc8d6@github.com>

On Thu, 13 Nov 2025 07:54:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that adds jni exception check after calling java code. 
>> 
>> Tested by running test with and without -Xcheck:jni.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   error message fixed

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28280#pullrequestreview-3458830380

From sgehwolf at openjdk.org  Thu Nov 13 10:05:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 13 Nov 2025 10:05:25 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <ho9I83ItEzD8807dKyFokWhJFoTGNAYL-iERqgO35lo=.2d687123-8174-4d01-a3f3-271e8b31b70e@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review. I still need a review from a Reviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3526909866

From ayang at openjdk.org  Thu Nov 13 11:38:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 13 Nov 2025 11:38:20 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
 <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
Message-ID: <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>

On Thu, 13 Nov 2025 09:31:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"

I suspect the crash is caused by a preexisting issue that is exposed by this patch.

In `vmClasses::resolve_all`:

#if INCLUDE_CDS
  if (CDSConfig::is_using_aot_linked_classes()) {
    AOTLinkedClassBulkLoader::preload_classes(THREAD);
  }
#endif

  // Preload commonly used klasses
  vmClassID scan = vmClassID::FIRST;
  // first do Object, then String, Class
  resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK);
  CollectedHeap::set_filler_object_klass(vmClasses::Object_klass());


The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj.

@iklam What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3527395697

From ysuenaga at openjdk.org  Thu Nov 13 12:53:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 13 Nov 2025 12:53:50 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
Message-ID: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>

> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
> 
> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
> 
> Big thanks to @pchilano for your help!

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update for Linux PPC64 and RISC-V

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28284/files
  - new: https://git.openjdk.org/jdk/pull/28284/files/4b854cd5..dfd947ab

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

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

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

From ysuenaga at openjdk.org  Thu Nov 13 12:57:19 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 13 Nov 2025 12:57:19 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing
In-Reply-To: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
Message-ID: <70sCitITz57g9qbvq_zHkO5qacFAnJztIRdGAW9N7Vw=.d45b9141-3717-411c-bad7-5a90585c553a@github.com>

On Thu, 13 Nov 2025 08:15:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
> 
> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
> 
> Big thanks to @pchilano for your help!

This PR is for Linux, other platforms (Windows, Mac) would not work. However I think it is not a problem because Windows and Mac has not been supported mixed jstack originally.

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3527677564

From tschatzl at openjdk.org  Thu Nov 13 14:17:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 13 Nov 2025 14:17:00 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
Message-ID: <sqLyO1KghT_l2FO1QIj4gTq6_oJyxRIOjDu_nUYQleI=.56c98454-2e9c-4377-8dd9-69f1eb5ff5ed@github.com>

On Tue, 11 Nov 2025 17:50:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Change looks good, but these AOT-related crashes should be fixed first.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28240#pullrequestreview-3460006822

From kevinw at openjdk.org  Thu Nov 13 14:29:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Nov 2025 14:29:16 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v10]
In-Reply-To: <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
Message-ID: <xfsaTsmeUyDrYo_1nx910RmTcD795mFtRDgE6m8V4lc=.aa5daa49-f2ab-4ace-bcd5-328375c47eec@github.com>

On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix phohensee review comments

Looks good.

Just a question on whether we really need to specify the GCs in the tests.
I was hoping we can not do this, it seems like more to maintain that should be automatic as long as we do test batches with the different collectors.

Do we need available GCs as specified in the tests get run on every test, or can we afford to let that be decided by the framework?
(There might be some tests where we do want to make sure they run with all GCs regardless of what jtreg command runs, but I would hope that is a small set.)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3460067101

From djelinski at openjdk.org  Thu Nov 13 14:37:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 14:37:43 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
Message-ID: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>

On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed line wrapping

Can you convert or remove the `IPAddressDNSIdentities` test as well?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:

> 34:  * @library /test/lib
> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA

as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 39:

> 37: 
> 38: /*
> 39:  * This test depends on binary keystore, crisubn.jks and trusted.jks. Because

Peease remove the crisubn.jks and trusted.jks files from this directory, they aren't used anywhere else.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 157:

> 155:         ks.setCertificateEntry("Trusted Cert", trustedCert);
> 156: 
> 157:         Certificate[] chain = new Certificate[] {serverCert, trustedCert};

(probably preexisting) you can remove the trusted cert from the chain; real servers usually don't send it.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 190:

> 188:     void doClientSide() throws Exception {
> 189: 
> 190:         if (!serverReady.await(SERVER_WAIT_SECS, TimeUnit.SECONDS)) {

I'd remove the time limit, it only causes trouble when people increase test concurrency and timeout factors.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:

> 1: /*

This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:

> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 103:                 .addBasicConstraintsExt(false, false, -1)
> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 119:

> 117:                         CertificateBuilder.KeyUsage.NONREPUDIATION,
> 118:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 119:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

Same here.

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

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3459883168
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523546617
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523539070
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523561169
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523555451
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523677717
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523705701
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523706426

From lmesnik at openjdk.org  Thu Nov 13 16:23:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 16:23:43 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <gKV9TIOUce_DKfwYB8-NOBT9dpTicD1cvTgHbDFv1IM=.7d75578d-96fe-4879-9041-6a3994b9f0c4@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3460609576

From lmesnik at openjdk.org  Thu Nov 13 16:33:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 16:33:03 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
In-Reply-To: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
Message-ID: <xREXHv3ljlOmZXNNySOx7ZBs5KMGmLMSP2c_UFMqWOg=.b3602b44-2fda-4c57-92b4-c438cc2f5424@github.com>

On Mon, 10 Nov 2025 20:54:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
> 
> Testing: tier1..4,hs-tier5-svc

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 43:

> 41:   switch (reference_kind) {
> 42:   case JVMTI_HEAP_REFERENCE_SYSTEM_CLASS:
> 43:     *tag_ptr = ++class_counter;

The callback is executed on VMThread, so counters should be atomic or protected by monitors.

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

PR Review: https://git.openjdk.org/jdk/pull/28224#pullrequestreview-3460651314
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524138908

From iklam at openjdk.org  Thu Nov 13 17:04:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Nov 2025 17:04:26 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
 <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
 <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
Message-ID: <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com>

On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj.
> 
> @iklam What do you think?

I am working on a fix now.

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3528798525

From macarte at openjdk.org  Thu Nov 13 17:52:32 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 17:52:32 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v5]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <GYXH5-lqF8Rcv8nyiQY7oWgwRY_8xSlUG0EKMDOdHDk=.a792bde2-3d26-4736-90a9-052ac738635b@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/d48a200f..bff7cb74

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

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

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

From macarte at openjdk.org  Thu Nov 13 17:57:04 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 17:57:04 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v2]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <AMbILLeAEkXIC83WjxrMvX2yFHFDPriJWN70I_Bh0nE=.c1f1f6eb-c41f-4493-9d45-56b04745c1ba@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/2f09c157..7b7e2f7e

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

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

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

From macarte at openjdk.org  Thu Nov 13 18:04:04 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 18:04:04 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v6]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <vAbJuQqT4STeXl3z1gn2yCMW__t6CNimzTf_zJeB8WI=.34e1596b-f57e-4509-8439-3c540a01a3ed@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording"
  Commit was intended for parent branch (that this branch is based on)
  
  This reverts commit bff7cb7408554232c13a57bba10b67a9fd19b811.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/bff7cb74..6a100586

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

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

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

From macarte at openjdk.org  Thu Nov 13 18:58:53 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 18:58:53 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v7]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <bGwueaZRgLg3yvDWzgPzk7XXPFaXir-A2Oq5UQKgNSw=.5686302e-6d13-4db2-8a0c-02af4c4ad471@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate changes from the CSR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/6a100586..b97a799f

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

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

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

From amenkov at openjdk.org  Thu Nov 13 19:05:21 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Nov 2025 19:05:21 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni [v2]
In-Reply-To: <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
 <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
Message-ID: <poLBtMwoCfAs1qKQYrzDQt_-MsdSHBMU3xCqt15xB2I=.d98f12d8-1b50-4a81-87ed-7ce6d22fd2cf@github.com>

On Thu, 13 Nov 2025 07:54:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that adds jni exception check after calling java code. 
>> 
>> Tested by running test with and without -Xcheck:jni.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   error message fixed

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28280#pullrequestreview-3461252832

From pchilanomate at openjdk.org  Thu Nov 13 19:20:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:20:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
Message-ID: <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>

On Wed, 12 Nov 2025 19:07:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:
> 
>> 386:                 try {
>> 387:                     Thread.sleep(1000);
>> 388:                 } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

We need to give time for the resumer thread to block on the `threadLock` before we release it. We could reduce the amount of sleep time though.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
> 
>> 426:             // launch the waiter thread
>> 427:             synchronized (barrierLaunch) {
>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
> 
> This change to `wait` for `1` instead of `0` requires this comment to be updated from:
> 
>                 // TS_READY_TO_NOTIFY is set after the main thread has
>                 // entered threadLock so a spurious wakeup can't get the
>                 // waiter thread out of this threadLock.wait(0) call:
> 
> to:
> 
>                 // TS_READY_TO_NOTIFY is set after the main thread has
>                 // entered threadLock so a spurious wakeup can't get the
>                 // waiter thread out of this threadLock.wait(0) call in
>                 // doWork1 or doWork2. doWork3 passes a one so that the
>                 // wait() can terminate early and block on reentry.
> 
> 
> I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
> in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
> of a `notify()` from the main thread. 
> 
> In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
> calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
> thread contends on threadsLock and finally the main thread suspends the worker thread.
> The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
> might get to re-entry block on threadsLock via a timeout instead of a notify.
> 
> What am I missing here?

The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:
> 
>> 452:             try {
>> 453:                 Thread.sleep(1000);
>> 454:             } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

This sleep is not needed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:
> 
>> 507:                 try {
>> 508:                     Thread.sleep(1000);
>> 509:                 } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

Same here, we need to give time for the resumer thread to block on the threadLock before we release it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524648214
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524652123
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524641301
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524648857

From amenkov at openjdk.org  Thu Nov 13 19:21:19 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Nov 2025 19:21:19 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
In-Reply-To: <xREXHv3ljlOmZXNNySOx7ZBs5KMGmLMSP2c_UFMqWOg=.b3602b44-2fda-4c57-92b4-c438cc2f5424@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
 <xREXHv3ljlOmZXNNySOx7ZBs5KMGmLMSP2c_UFMqWOg=.b3602b44-2fda-4c57-92b4-c438cc2f5424@github.com>
Message-ID: <EwYnMcnBauNhTpBJbmuJQVE6R1ghGGEMEf_5G9LdPbw=.903cb2e3-a3a6-4b47-bc98-6f42718d2d88@github.com>

On Thu, 13 Nov 2025 16:30:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
>> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
>> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 43:
> 
>> 41:   switch (reference_kind) {
>> 42:   case JVMTI_HEAP_REFERENCE_SYSTEM_CLASS:
>> 43:     *tag_ptr = ++class_counter;
> 
> The callback is executed on VMThread, so counters should be atomic or protected by monitors.

Not sure I follow. There is no concurrent access to the variables.
FollowReferences is executed at safepoint (so the counters are updated by single thread). The values are read after FollowReference returns (i.e. after the safepoint)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524652595

From pchilanomate at openjdk.org  Thu Nov 13 19:23:46 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:23:46 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:

> 29:  * @library /test/lib
> 30:  * @compile SuspendWithObjectMonitorWait.java
> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1

Note that these passed values are overriding timeMax.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524657555

From pchilanomate at openjdk.org  Thu Nov 13 19:20:39 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:20:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:

> 426:             // launch the waiter thread
> 427:             synchronized (barrierLaunch) {
> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);

We should increase this timeout to minimize the chance of it happening between the main thread acquiring the `threadLock` and issuing the notification, in which case the waiter will not go through `reenter_internal` but through `enter`. Also it avoids some funny scheduling where the main thread never acquires the `threadLock`.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 466:

> 464:                 testState = TS_READY_TO_NOTIFY;
> 465:                 threadLock.notify();
> 466: 

We should add a `Thread.sleep` here to give time for the wait to timeout before suspending the waiter thread. Should be more than what the waiter thread is using as timeout. I have tested a timeout value of 100ms and here sleeping 200ms and always see the deadlock on `reenter_internal` (with current mainline code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524640318
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524643382

From macarte at openjdk.org  Thu Nov 13 19:41:40 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 19:41:40 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Document use of DiagnosticCommand

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/7b7e2f7e..cdd1f1d4

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

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

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

From amenkov at openjdk.org  Thu Nov 13 19:42:00 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Nov 2025 19:42:00 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS [v2]
In-Reply-To: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
Message-ID: <Yg5kWOq0Iqud1UQO--ldZVCT_EJE70aXIb5IE47xlmU=.b59fb3c0-f0e9-4687-9c3d-d1cae6c5c685@github.com>

> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
> 
> Testing: tier1..4,hs-tier5-svc

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/28224/files
  - new: https://git.openjdk.org/jdk/pull/28224/files/1ee62064..efa0b538

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

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

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

From amenkov at openjdk.org  Thu Nov 13 19:46:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Nov 2025 19:46:33 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS [v2]
In-Reply-To: <MDteIivp7h02zH-XVFVC8UfV3Rey6CYSqL25X6yZyWY=.24b1001f-ded1-46b2-b519-bde884ad5faf@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
 <MDteIivp7h02zH-XVFVC8UfV3Rey6CYSqL25X6yZyWY=.24b1001f-ded1-46b2-b519-bde884ad5faf@github.com>
Message-ID: <7wURnzxhUcvMAvFBs1-ADLcdjSxsAs53lfH-M-6eHKA=.74ffc3ca-c15f-4bdc-a640-4fe50869c36c@github.com>

On Wed, 12 Nov 2025 23:32:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 2193:
> 
>> 2191: };
>> 2192: 
>> 2193: // A supporting closure used to process ClassLoaderData roots
> 
> Nit: Need dot at the end of comment.

Fixed

> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 79:
> 
>> 77: 
>> 78:   for (int i = 0; i < class_counter; i++) {
>> 79:     tags[i] = i+1;
> 
> Nit: Need spaces around `+` sign.

Fixed.

> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 101:
> 
>> 99: }
>> 100: 
>> 101: 
> 
> Nit: Unneeded extra empty line.

removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524717090
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524716711
PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524717427

From lmesnik at openjdk.org  Thu Nov 13 19:53:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 19:53:12 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS [v2]
In-Reply-To: <Yg5kWOq0Iqud1UQO--ldZVCT_EJE70aXIb5IE47xlmU=.b59fb3c0-f0e9-4687-9c3d-d1cae6c5c685@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
 <Yg5kWOq0Iqud1UQO--ldZVCT_EJE70aXIb5IE47xlmU=.b59fb3c0-f0e9-4687-9c3d-d1cae6c5c685@github.com>
Message-ID: <_yYrCkPQbFXAsI5lfc4ErWuwr585DFf_5h2alB5nF5E=.2beeda93-1e9e-4694-9188-302e72c52f05@github.com>

On Thu, 13 Nov 2025 19:42:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
>> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
>> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28224#pullrequestreview-3461421197

From lmesnik at openjdk.org  Thu Nov 13 19:53:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 19:53:14 GMT
Subject: RFR: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS [v2]
In-Reply-To: <EwYnMcnBauNhTpBJbmuJQVE6R1ghGGEMEf_5G9LdPbw=.903cb2e3-a3a6-4b47-bc98-6f42718d2d88@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
 <xREXHv3ljlOmZXNNySOx7ZBs5KMGmLMSP2c_UFMqWOg=.b3602b44-2fda-4c57-92b4-c438cc2f5424@github.com>
 <EwYnMcnBauNhTpBJbmuJQVE6R1ghGGEMEf_5G9LdPbw=.903cb2e3-a3a6-4b47-bc98-6f42718d2d88@github.com>
Message-ID: <AfdA_lA2kc0nCuTbVWShD9mlQx5qeAzhg5sJs31YSa4=.d9f84ae1-cc0f-4d4a-8e46-76fdd3890c0e@github.com>

On Thu, 13 Nov 2025 19:18:38 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/KindSystemClass/libKindSystemClass.cpp line 43:
>> 
>>> 41:   switch (reference_kind) {
>>> 42:   case JVMTI_HEAP_REFERENCE_SYSTEM_CLASS:
>>> 43:     *tag_ptr = ++class_counter;
>> 
>> The callback is executed on VMThread, so counters should be atomic or protected by monitors.
>
> Not sure I follow. There is no concurrent access to the variables.
> FollowReferences is executed at safepoint (so the counters are updated by single thread). The values are read after FollowReference returns (i.e. after the safepoint)

Thanks for explanation. Then it is no need to synchronize.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28224#discussion_r2524733585

From macarte at openjdk.org  Thu Nov 13 19:55:24 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 19:55:24 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Remove single whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/b97a799f..f4a4af61

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

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

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

From dcubed at openjdk.org  Thu Nov 13 20:35:28 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:35:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <VI_4cDAV4pRYjj58cxRqFyjG51UR5ifE_5JW6bhqVOY=.98296ac3-9ca1-4976-864c-bf0714b83f1d@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

The transaction diagram in SuspendWithObjectMonitorWait.java on L56 -> L77 is
for the `doWork1` test so the comment should be modifed to make that clear by
adding this above L56:

//
// doWork1 algorithm:

I've created a transaction diagram for doWork2:

//
// doWork2 algorithm:
//
// main               waiter              resumer
// =================  ==================  ===================
// launch waiter
// <launch returns>   waiter running
// launch resumer     enter threadLock
// <launch returns>   threadLock.wait()   resumer running
// enter threadLock   :                   wait for notify
// threadLock.notify  wait finishes       :
// :                  reenter blocks      :
// suspend waiter     <suspended>         :
// <ready to test>    :                   :
// :                  :                   :
// notify resumer     :                   wait finishes
// delay 1-second     :                   :
// exit threadLock    :                   :
// join resumer       :                   enter threadLock
// :                  <resumed>           resume waiter
// :                  :                   exit threadLock
// :                  reenter threadLock  :
// <join returns>     :                   resumer exits
// join waiter        :
// <join returns>     waiter exits
//
// Note: The sleep(1-second) in main along with the delayed exit
//       of threadLock in main forces the resumer thread to reach
//       "enter threadLock" and block. This difference from doWork1
//       forces the resumer thread to be contending for threadLock
//       while the waiter thread is in threadLock.wait() increasing
//       stress on the monitor sub-system.
//

I've created a transaction diagram for doWork3:

//
// doWork3 algorithm:
//
// main                 waiter                  resumer
// ===================  ======================  ===================
// launch waiter
// <launch returns>     waiter running
// launch resumer       enter threadLock
// <launch returns>     while !READY_TO_NOTIFY  resumer running
// delay 1-second         threadLock.wait(1)    wait for notify
// enter threadLock     :                       :
// set READY_TO_NOTIFY  :
// threadLock.notify    wait finishes           :
// :                    reenter blocks          :
// suspend waiter       <suspended>             :
// <ready to test>      :                       :
// :                    :                       :
// notify resumer       :                       wait finishes
// delay 1-second       :                       :
// exit threadLock      :                       :
// join resumer         :                       enter threadLock
// :                    <resumed>               resume waiter
// :                    :                       exit threadLock
// :                    reenter threadLock      :
// <join returns>       :                       resumer exits
// join waiter          :
// <join returns>       waiter exits
//
// Note: The sleep(1-second) in main along with the delayed exit
//       of threadLock in main forces the resumer thread to reach
//       "enter threadLock" and block. This difference from doWork1
//       forces the resumer thread to be contending for threadLock
//       while the waiter thread is in the threadLock.wait(1) tight
//       loop increasing stress on the monitor sub-system.
//
// Note: The first sleep(1-second) in main and the wait(1) in the waiter
//       thread allows the waiter thread to loop tightly here:
//         while !READY_TO_NOTIFY
//           threadLock.wait(1)
//

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529595262
PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529599987
PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529602353

From dcubed at openjdk.org  Thu Nov 13 20:46:49 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:49 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <LAqs9AH7Qt69n4QxE39tlrKQCHRDEU6kfWue98Pj_t0=.3f16c76d-d14d-4229-bfe9-431b29805d18@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

Marked as reviewed by dcubed (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 110:

> 108: 
> 109:     public static void main(String[] args) throws Exception {
> 110:         int test = Integer.parseInt(args[0]);

I think this will throw if the test is called without any parameters.

Also, the `usage` function needs to be updated to reflect the addition of the
test number parameter.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3461580809
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524858587

From dcubed at openjdk.org  Thu Nov 13 20:46:52 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:52 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
Message-ID: <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>

On Thu, 13 Nov 2025 19:20:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:
> 
>> 29:  * @library /test/lib
>> 30:  * @compile SuspendWithObjectMonitorWait.java
>> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1
> 
> Note that these passed values are overriding timeMax.

The addition of the test number should have been done as a required parameter.
That would push the optional timeMax parameter to be the optional second parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524856106

From dcubed at openjdk.org  Thu Nov 13 20:46:54 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:54 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
Message-ID: <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>

On Wed, 12 Nov 2025 20:04:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:
>> 
>>> 370:                 // - a threadLock enter in the resumer thread
>>> 371:                 // - resumption of the waiter thread
>>> 372:                 // - a threadLock enter in the freshly resumed waiter thread
>> 
>> This list of step tests is identical to the list on L490 -> L493 and the
>> original llist on L256 -> L259.
>> 
>> This step comment:
>> `370:               // - a threadLock enter in the resumer thread`
>> should be updated to something like:
>> 
>>              // - a blocked threadLock enter in the resumer thread while the
>>              //   threadLock is held by the main thread.
>> 
>> 
>> This change of threadLock scope also requires this update from:
>> 
>> 605:        // - tries to grab the threadLock (should not block!)
>> 
>> 
>> to:
>> 
>> 605:        // - tries to grab the threadLock (should not block with doWork1!)
>
> I can't figure out why we're delaying the resumer thread in `doWork2`.

Update: I figured this out. See the new doWork2 transaction diagram.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:
>> 
>>> 491:                 // - a threadLock enter in the resumer thread
>>> 492:                 // - resumption of the waiter thread
>>> 493:                 // - a threadLock enter in the freshly resumed waiter thread
>> 
>> This list of step tests is identical to the list on L369 -> L372 and the
>> original llist on L256 -> L259.
>> 
>> This step comment:
>> 
>> 491:               // - a threadLock enter in the resumer thread
>> 
>> should be updated to something like:
>> 
>>              // - a blocked threadLock enter in the resumer thread while the
>>              //   threadLock is held by the main thread.
>
> I can't figure out why we're delaying the resumer thread in `doWork3`.

Update: I figured this out. See the new doWork3 transaction diagram.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524860241
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524872816

From dcubed at openjdk.org  Thu Nov 13 20:46:58 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:58 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
Message-ID: <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>

On Thu, 13 Nov 2025 19:16:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:
>> 
>>> 386:                 try {
>>> 387:                     Thread.sleep(1000);
>>> 388:                 } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> We need to give time for the resumer thread to block on the `threadLock` before we release it. We could reduce the amount of sleep time though.

Agreed. I pretty much said the same thing about the resumer thread in the new doWork2 transaction
diagram (and the new doWork3 transaction diagram).

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
>> 
>>> 426:             // launch the waiter thread
>>> 427:             synchronized (barrierLaunch) {
>>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
>> 
>> This change to `wait` for `1` instead of `0` requires this comment to be updated from:
>> 
>>                 // TS_READY_TO_NOTIFY is set after the main thread has
>>                 // entered threadLock so a spurious wakeup can't get the
>>                 // waiter thread out of this threadLock.wait(0) call:
>> 
>> to:
>> 
>>                 // TS_READY_TO_NOTIFY is set after the main thread has
>>                 // entered threadLock so a spurious wakeup can't get the
>>                 // waiter thread out of this threadLock.wait(0) call in
>>                 // doWork1 or doWork2. doWork3 passes a one so that the
>>                 // wait() can terminate early and block on reentry.
>> 
>> 
>> I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
>> in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
>> of a `notify()` from the main thread. 
>> 
>> In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
>> calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
>> thread contends on threadsLock and finally the main thread suspends the worker thread.
>> The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
>> might get to re-entry block on threadsLock via a timeout instead of a notify.
>> 
>> What am I missing here?
>
> The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.

Please see the notes in the new doWork3 transaction diagram. I think I've covered this case.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:
>> 
>>> 452:             try {
>>> 453:                 Thread.sleep(1000);
>>> 454:             } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> This sleep is not needed.

I have a comment about this in the new doWork3 transaction diagram.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:
>> 
>>> 507:                 try {
>>> 508:                     Thread.sleep(1000);
>>> 509:                 } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> Same here, we need to give time for the resumer thread to block on the threadLock before we release it.

Agreed. I pretty much said the same thing about the resumer thread in the new doWork3 transaction
diagram (and the new doWork2 transaction diagram).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524862590
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524866785
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524870502
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524875174

From dcubed at openjdk.org  Thu Nov 13 20:54:16 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:54:16 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.

I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended
thread made the successor over and over again so that none of the other contending threads
ever get the monitor even though it is unlocked.

I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread
manages to re-enter the monitor and then gets suspended while on its way back to Java.

@toxaart and/or @pchilano - Please verify my understanding of this mapping from the two
new test cases to the two deadlocks. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529662045

From pchilanomate at openjdk.org  Thu Nov 13 21:49:46 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 21:49:46 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
Message-ID: <dW3uMNCyE3EqA3DTAQ7IVaKfhviQd1Q_kzCmglAAVvI=.464e99d1-6917-4a0f-98f0-9d7afa5aa080@github.com>

On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.
> 
> I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended thread made the successor over and over again so that none of the other contending threads ever get the monitor even though it is unlocked.
> 
> I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread manages to re-enter the monitor and then gets suspended while on its way back to Java.
> 
> @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two new test cases to the two deadlocks. Thanks!
>
The PR description of the cases isn?t quite accurate. The explanation in `1.` applies to both deadlocks, the only difference is where the successor could be suspended:
[1]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 (exercised by doWork2)
[2]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 (exercised by doWork3)

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529846713

From cjplummer at openjdk.org  Thu Nov 13 22:22:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Nov 2025 22:22:18 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
Message-ID: <7KUmTufrD6xtVMSP1L4QEFdXxRSe0hyoVV0KTwdgKDI=.76640a01-7d86-438f-9614-684b11773c37@github.com>

On Sun, 9 Nov 2025 10:30:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
>> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
>> 
>> Testing:
>>  - TBD: Verify the test with mach5 test runs
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: restore original EXPECTED_ACCURACY for Windows

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28206#pullrequestreview-3461917746

From cjplummer at openjdk.org  Thu Nov 13 22:23:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Nov 2025 22:23:06 GMT
Subject: RFR: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni [v2]
In-Reply-To: <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
 <nlCXiO2PE18AUbiKrdBXf4w7XBQEFq3-7v0XXnQkDBU=.160bd979-a091-4745-83d9-3bd95b981649@github.com>
Message-ID: <MDkbeGDfGv46z_c4pcrsLOz4MGv1DckX6Lqw_Us1Lrw=.d767093f-6cf2-4e4e-80aa-aace1f537b4e@github.com>

On Thu, 13 Nov 2025 07:54:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that adds jni exception check after calling java code. 
>> 
>> Tested by running test with and without -Xcheck:jni.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   error message fixed

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28280#pullrequestreview-3461921809

From sspitsyn at openjdk.org  Thu Nov 13 22:47:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 13 Nov 2025 22:47:00 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v3]
In-Reply-To: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
Message-ID: <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>

> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
> 
> Testing:
>  - TBD: Verify the test with mach5 test runs

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge
 - review: restore original EXPECTED_ACCURACY for Windows
 - 8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28206/files
  - new: https://git.openjdk.org/jdk/pull/28206/files/c53f9b40..e98facf9

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

  Stats: 245054 lines in 1955 files changed: 157091 ins; 53344 del; 34619 mod
  Patch: https://git.openjdk.org/jdk/pull/28206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28206/head:pull/28206

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

From duke at openjdk.org  Thu Nov 13 23:49:28 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 13 Nov 2025 23:49:28 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

  Add an assertion to detect out of bounds access in post-call NOP checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28192/files
  - new: https://git.openjdk.org/jdk/pull/28192/files/7bb43523..20cc58a3

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

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

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

From duke at openjdk.org  Thu Nov 13 23:49:29 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 13 Nov 2025 23:49:29 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <re5ECBmYsa2vwCr7uMCRpOxQgGlj9hkmXQk_FEHXaVA=.eed23f9f-3608-4d78-8a7e-ca09196b7f8b@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <re5ECBmYsa2vwCr7uMCRpOxQgGlj9hkmXQk_FEHXaVA=.eed23f9f-3608-4d78-8a7e-ca09196b7f8b@github.com>
Message-ID: <YaXq467of50F0FUIGt1VA3_aflTC2aTKaQjBFlWrHwE=.6586e70c-8e4d-498c-bc4e-ab30df72feb3@github.com>

On Mon, 10 Nov 2025 10:50:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an assertion to detect out of bounds access in post-call NOP checks
>
> src/hotspot/cpu/x86/nativeInst_x86.hpp line 585:
> 
>> 583:   };
>> 584: 
>> 585:   bool check() const { return short_at(0) == 0x1f0f && short_at(2) == 0x0084; }
> 
> Maybe a comment would be nice.

Thanks for the suggestion. Would the comments added at https://github.com/openjdk/jdk/pull/28192/commits/20cc58a3649db0650da054809f64e0c4416d616f be suitable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28192#discussion_r2525276626

From lmesnik at openjdk.org  Thu Nov 13 23:57:10 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 23:57:10 GMT
Subject: Integrated: 8371749: New test
 serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java
 fails with -Xcheck:jni
In-Reply-To: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
References: <qliCOLFlp2iSoP6HanoceYOuWf59TOM5-N8Vhs9ne-0=.f66bd15f-be20-4a2f-b06f-e7f30cfb96cf@github.com>
Message-ID: <emZ88YCxFf6d61Q4EHVw1OqREpfbkxMNOUR0zE7RTt0=.70dc892e-654a-4317-bdc8-91e114b30898@github.com>

On Thu, 13 Nov 2025 02:51:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that adds jni exception check after calling java code. 
> 
> Tested by running test with and without -Xcheck:jni.

This pull request has now been integrated.

Changeset: 155d7df5
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/155d7df555fcebc318db89408ef0fffbd95414a0
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8371749: New test serviceability/jvmti/events/VMDeath/AllocatingInVMDeath/TestAllocatingInVMDeath.java fails with -Xcheck:jni

Reviewed-by: sspitsyn, amenkov, cjplummer

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

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

From iklam at openjdk.org  Fri Nov 14 04:48:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 04:48:16 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
 <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
 <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
 <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com>
Message-ID: <GEP_1E2aHcssomBwEKQlO3j7sR1YNHVZn62l3wth8b4=.11ae1d29-a1aa-4e29-b82e-326bbf113e65@github.com>

On Thu, 13 Nov 2025 17:01:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj.
> > @iklam What do you think?
> 
> I am working on a fix now.

The fix is quite simple. See https://github.com/openjdk/jdk/pull/28315

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3530816677

From dfuchs at openjdk.org  Fri Nov 14 10:10:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 10:10:01 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
Message-ID: <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>

On Thu, 13 Nov 2025 14:32:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
> 
>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>> 103:                 .addBasicConstraintsExt(false, false, -1)
>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
> 
> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2526848102

From duke at openjdk.org  Fri Nov 14 11:11:43 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 14 Nov 2025 11:11:43 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v10]
In-Reply-To: <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
Message-ID: <Xin0FYMVR2_jAlyCddg3GpqFD5u126XOdiOstkXu_Ls=.b955b7c4-a732-43c8-ba03-c0ca2b0919fd@github.com>

On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix phohensee review comments

Thanks Kevin!

> Just a question on whether we really need to specify the GCs in the tests.

I think it is required for the shutdown test and we need to keep them all. However, we may omit this for the trivial API test. Would that be a reasonable compromise? I'd suggest to keep Epsilon and G1 for `TestGetTotalGcCpuTime`.

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

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

From duke at openjdk.org  Fri Nov 14 11:29:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 14 Nov 2025 11:29:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v11]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <dXmRDaV78jjwZ8nQOg5FmXQ7olZ3hlmACw3vZxHuBUI=.c0a24ae5-353f-4be2-8100-8355398e9794@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Reduce GC coverage for trivial API test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/44f5d864..8fd1ee09

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

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

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

From ayang at openjdk.org  Fri Nov 14 11:54:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 11:54:12 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <G0xVQpc_FSma3WnGWCHVJMdprWwW86IKyICAFeQJ29k=.cd4cff1c-b67f-4616-8c19-260435956bf1@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3464591706

From aartemov at openjdk.org  Fri Nov 14 12:04:26 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:26 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v7]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <-UqELJ5fcs2hmKx51_i77VwQGSq70cV4Wd73_6YkcGA=.2d572210-d0f7-45a1-9fd4-9b06f2e5609c@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Fixed the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/702880c6..15efce1b

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

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

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

From aartemov at openjdk.org  Fri Nov 14 12:04:30 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:30 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
Message-ID: <1sh5xXfgN3ykKP6JO7fkEO-06usdJoBMp_igGw9OzJI=.b9325a92-1e8d-49a2-aaed-b7a154d9bb6a@github.com>

On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.
> 
> I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended
> thread made the successor over and over again so that none of the other contending threads
> ever get the monitor even though it is unlocked.
> 
> I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread
> manages to re-enter the monitor and then gets suspended while on its way back to Java.
> 
> @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two
> new test cases to the two deadlocks. Thanks!

Thanks @dcubed-ojdk and @pchilano, I addressed all the points. The diagrams are now added to the test.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 110:
> 
>> 108: 
>> 109:     public static void main(String[] args) throws Exception {
>> 110:         int test = Integer.parseInt(args[0]);
> 
> I think this will throw if the test is called without any parameters.
> 
> Also, the `usage` function needs to be updated to reflect the addition of the
> test number parameter.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 297:
> 
>> 295:     }
>> 296: 
>> 297:     // Notify the resumer while holding the threadLock
> 
> Nit: please add a period at the end of this sentence.

Addressed in the latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3532412149
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527249217
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527245664

From aartemov at openjdk.org  Fri Nov 14 12:04:32 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
 <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>
Message-ID: <4J4hAvATWVRnKGA8E1_R2dYYY-QPd6rWm6BQECf2jpI=.e624cd45-7b4b-4f55-a870-3cfb66f577c4@github.com>

On Thu, 13 Nov 2025 20:34:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:
>> 
>>> 29:  * @library /test/lib
>>> 30:  * @compile SuspendWithObjectMonitorWait.java
>>> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1
>> 
>> Note that these passed values are overriding timeMax.
>
> The addition of the test number should have been done as a required parameter.
> That would push the optional timeMax parameter to be the optional second parameter.

Addressed in the latest commit. I did not figure out how to do it with jtreg, made it instead right in the test code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248823

From aartemov at openjdk.org  Fri Nov 14 12:04:32 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
 <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>
Message-ID: <qRVdIum5zsImnH0HZXysbFYpgbM751r6-_zydPGP72k=.3eaa9660-dcaa-4f8f-a338-72118a8d6e4a@github.com>

On Thu, 13 Nov 2025 20:36:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I can't figure out why we're delaying the resumer thread in `doWork2`.
>
> Update: I figured this out. See the new doWork2 transaction diagram.

Addressed.

>> I can't figure out why we're delaying the resumer thread in `doWork3`.
>
> Update: I figured this out. See the new doWork3 transaction diagram.

Addressed the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527246445
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527246193

From aartemov at openjdk.org  Fri Nov 14 12:04:33 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
 <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>
Message-ID: <kBR_mo5mAZQO4xyfJ9_CnKl98Bv9eoCZ-MyZTxhGt4k=.228dcc7a-328d-466c-baa5-59a0e5a5f4ff@github.com>

On Thu, 13 Nov 2025 20:38:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.
>
> Please see the notes in the new doWork3 transaction diagram. I think I've covered this case.

Thanks @dcubed-ojdk! I added your diagrams to the test.

>> This sleep is not needed.
>
> I have a comment about this in the new doWork3 transaction diagram.

Removed as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248191
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527245983

From aartemov at openjdk.org  Fri Nov 14 12:04:36 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>
Message-ID: <dt5IFHCnLsTSSVT0CWWbPGUSWHTOCHWbGPzCVKVLYcM=.2f73701a-d614-49bb-9e59-95f2f9df7f15@github.com>

On Thu, 13 Nov 2025 19:13:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
> 
>> 426:             // launch the waiter thread
>> 427:             synchronized (barrierLaunch) {
>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
> 
> We should increase this timeout to minimize the chance of it happening between the main thread acquiring the `threadLock` and issuing the notification, in which case the waiter will not go through `reenter_internal` but through `enter`. Also it avoids some funny scheduling where the main thread never acquires the `threadLock`.

Done.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 466:
> 
>> 464:                 testState = TS_READY_TO_NOTIFY;
>> 465:                 threadLock.notify();
>> 466: 
> 
> We should add a `Thread.sleep` here to give time for the wait to timeout before suspending the waiter thread. Should be more than what the waiter thread is using as timeout. I have tested a timeout value of 100ms and here sleeping 200ms and always see the deadlock on `reenter_internal` (with current mainline code).

Removed the sleep which was not needed and added another one with 200ms as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527251981
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248616

From kevinw at openjdk.org  Fri Nov 14 12:11:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Nov 2025 12:11:11 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v10]
In-Reply-To: <Xin0FYMVR2_jAlyCddg3GpqFD5u126XOdiOstkXu_Ls=.b955b7c4-a732-43c8-ba03-c0ca2b0919fd@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
 <Xin0FYMVR2_jAlyCddg3GpqFD5u126XOdiOstkXu_Ls=.b955b7c4-a732-43c8-ba03-c0ca2b0919fd@github.com>
Message-ID: <ZH7ai3_E1EXFkZrmR62YKrNfAa13I7vC3FKtHpGUNFg=.fdb794c7-ad3b-47f3-82f0-8a7cdb93aa18@github.com>

On Fri, 14 Nov 2025 11:08:40 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> I think it is required for the shutdown test and we need to keep them all. However, we may omit this for the trivial API test. Would that be a reasonable compromise? I'd suggest to keep Epsilon and G1 for `TestGetTotalGcCpuTime`.

OK that's great to cut it down a bit, thanks.  I meant I think we need to remove all the specific GCs from that test, and let the test harness run with the variety of collectors.  If test/jdk/java/lang/management/MemoryMXBean/TestGetTotalGcCpuTime.java specifies those two, doesn't it only run with those two?  We want most code to be tested with a variety of collectors, we should get that if we just say nothing. 8-)

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

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

From aartemov at openjdk.org  Fri Nov 14 12:15:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:15:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed the test.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed lines in tests.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=07
  Stats: 469 lines in 3 files changed: 397 ins; 44 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From kevinw at openjdk.org  Fri Nov 14 13:01:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Nov 2025 13:01:08 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
Message-ID: <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>

On Thu, 13 Nov 2025 19:41:40 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - Error! Not a recording run
>> - Error! Not recording
>> - Recording ended successfully
>> - Error! Failed to end recording
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully
>> - Error! Not recording
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document use of DiagnosticCommand

src/hotspot/share/services/diagnosticCommand.cpp line 991:

> 989: }
> 990: 
> 991: #if INCLUDE_CDS

A simple style nit-pick:  Error!
The JVM doesn't really dramatize problems like that.  It tells you there was an error, and calmly describes the problem after a colon. "Error: " 8-)

(There are some "Error!" exclamations in java.xml and one has got into jdk.jfr, but they are unusual.)

You can tell me that nit-picking is NOT hyphenated if you like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2527414361

From sgehwolf at openjdk.org  Fri Nov 14 13:15:18 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:18 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <gX0-1gsNi4RVPLEOaYS6FyXXa6L4TLi_LDS2IWyokE8=.5edb1a53-ce95-407c-b957-31fe82408847@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3532678185

From sgehwolf at openjdk.org  Fri Nov 14 13:15:19 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:19 GMT
Subject: Integrated: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <QLvbFlQI8t3MageG8gHw4_Sh7mGkUgIjDwiE44A3Ups=.f48a5d7c-cfeb-450d-bcd1-b43da0255568@github.com>

On Wed, 5 Nov 2025 18:13:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

This pull request has now been integrated.

Changeset: 5d65c23c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d65c23cd99b72527dcfab9eb6da9510e7dc6330
Stats:     107 lines in 4 files changed: 90 ins; 0 del; 17 mod

8370492: [Linux] Update cpu shares to cpu.weight mapping function

Reviewed-by: cnorrbin, ayang, syan

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

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

From kevinw at openjdk.org  Fri Nov 14 14:52:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Nov 2025 14:52:16 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v11]
In-Reply-To: <dXmRDaV78jjwZ8nQOg5FmXQ7olZ3hlmACw3vZxHuBUI=.c0a24ae5-353f-4be2-8100-8355398e9794@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <dXmRDaV78jjwZ8nQOg5FmXQ7olZ3hlmACw3vZxHuBUI=.c0a24ae5-353f-4be2-8100-8355398e9794@github.com>
Message-ID: <VCiVYXFfSt2CLBrgHgn3O84a8VaYowtczeeIWGZSKRs=.8bc28321-ce80-4bce-ab5d-f5a58c55835a@github.com>

On Fri, 14 Nov 2025 11:29:48 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce GC coverage for trivial API test

Or, if we don't want to remove the GC specifics and go with what the framework sets, then we should revert that last delete, sorry, otherwise with will just not be run with all GCs.  

I was thinking it was more efficient to say nothing in the test, but can leave this to be done with specifics in the test if you like. 8-)

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

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

From dcubed at openjdk.org  Fri Nov 14 18:19:40 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 14 Nov 2025 18:19:40 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
Message-ID: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>

On Fri, 14 Nov 2025 12:15:35 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed the test.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94

Another crawl thru review of the test with more suggested changes.

I'll be doing one last round of commenting on the argument parsing stuff.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 124:

> 122: // launch resumer       enter threadLock
> 123: // <launch returns>     while !READY_TO_NOTIFY  resumer running
> 124: // delay 1-second         threadLock.wait(1)    wait for notify

We've deleted this sleep, so this line should change from:

// delay 1-second         threadLock.wait(1)    wait for notify

to:

// :                      threadLock.wait(1)    wait for notify

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 128:

> 126: // set READY_TO_NOTIFY  :
> 127: // threadLock.notify    wait finishes           :
> 128: // :                    reenter blocks          :

We added a sleep here, so this line should change from:

// :                    reenter blocks          :

to:

// : delay 200ms        reenter blocks          :

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 153:

> 151: //       thread allows the waiter thread to loop tightly here:
> 152: //         while !READY_TO_NOTIFY
> 153: //           threadLock.wait(1)

Please replace this note with the following:

// Note: sleep(200ms) here while holding the threadLock to allow the waiter thread's
// timed wait to finish before we attempt to suspend the waiter thread.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:

> 210:                 argsLeft--;
> 211:             }
> 212:             if (argsLeft == 0) {

Because of the addition of a mandatory argument (test case), argument parsing will
be more complicated. I need to mull on this a bit and I'll post another suggestion
after this round.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 237:

> 235: 
> 236:     public static void usage() {
> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");

The `N` argument is not optional so it should not be surrounded by `[` and `]`.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 239:

> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
> 238:         System.err.println("where:");
> 239:         System.err.println("    N        ::= test case");

s/case/case: 1 | 2 | 3/

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 470:

> 468:                 }
> 469:                 try {
> 470:                     Thread.sleep(1000);

Please add something like this above the `sleep`:

// Delay for 1-second while holding the threadLock to force the
// resumer thread to block on entering the threadLock.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:

> 550:                 // wait for the waiter thread to block
> 551:                 logDebug("before contended enter wait");
> 552:                 int retCode = wait4ContendedEnter(waiter);

Since we are waiting here for ContendedEnter by the waiter thread, do we really
need the above `sleep(200)` or are we just being polite CPU resource wise?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 592:

> 590:                 }
> 591:                 try {
> 592:                     Thread.sleep(1000);

Please add something like this above the sleep:

// Delay for 1-second while holding the threadLock to force the
// resumer thread to block on entering the threadLock.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3466061446
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528454607
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528465014
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528473772
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528423196
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528406725
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528408659
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528432284
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528443735
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528446025

From kvn at openjdk.org  Fri Nov 14 18:41:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Nov 2025 18:41:11 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
Message-ID: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>

On Thu, 13 Nov 2025 19:41:40 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - Error! Not a recording run
>> - Error! Not recording
>> - Recording ended successfully
>> - Error! Failed to end recording
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully
>> - Error! Not recording
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document use of DiagnosticCommand

Comments.

src/hotspot/share/cds/aotMetaspace.cpp line 961:

> 959: }
> 960: 
> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {

I think the name should be `preimage_static_archive_dumped()` to match field's name you accessing and check ` == 1` instead. The code in `AOTEndRecordingDCmd::execute()` will be more clear then.

src/hotspot/share/cds/aotMetaspace.cpp line 962:

> 960: 
> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {
> 962:   if (CDSConfig::is_dumping_preimage_static_archive()) {

This is called after you already checked `CDSConfig::is_dumping_preimage_static_archive()`. May be replace the check with assert.

src/hotspot/share/cds/aotMetaspace.cpp line 973:

> 971:       return;
> 972:     }
> 973:   }

Add comment that this could be called from different threads and possibly concurrently: when JCMD requested it and normal call during VM exit. We should dump archive only once.

src/hotspot/share/services/diagnosticCommand.cpp line 996:

> 994:     output()->print_cr("Error! Not a recording run");
> 995:     return;
> 996:   }

First, is `output()` directed to VM's tty or somewhere else?

Second, I think you need to be more verbose in error. Maybe:

Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.

src/hotspot/share/services/diagnosticCommand.cpp line 1000:

> 998:   if (!AOTMetaspace::is_recording_preimage_static_archive()) {
> 999:     output()->print_cr("Error! Not recording");
> 1000:     return;

This check is confusing because your error message is cryptic.
Actually I think you don't need any message here - it is not error. Use comment instead:

  // The other thread already initiated end of recording.

src/hotspot/share/services/diagnosticCommand.cpp line 1007:

> 1005:     output()->print_cr("Recording ended successfully");
> 1006:     return;
> 1007:   }

I think this should be reversed and message replaced with comment.

if (AOTMetaspace::is_recording_preimage_static_archive()) {
    // Other thread already dumped archive.
    return;
}
output()->print_cr("AOT recording ended successfully");

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

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3466124096
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528503476
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528453164
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528486742
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528446012
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528465285
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528496380

From pchilanomate at openjdk.org  Fri Nov 14 18:42:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 14 Nov 2025 18:42:09 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <4dipoan9jnaJpGdBc2b4tpnEDvxsIOSjSPrvIMwnka8=.1ad85705-c8d1-46a2-b364-2a5880386845@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

Fix looks good to me (can't comment on the PPC and RISCV parts though).

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:

> 38:  * @requires vm.hasSA
> 39:  * @requires os.family == "linux"
> 40:  * @requires os.arch == "amd64"

Can't we run the test on AArch64 now?

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

PR Review: https://git.openjdk.org/jdk/pull/28284#pullrequestreview-3466259361
PR Review Comment: https://git.openjdk.org/jdk/pull/28284#discussion_r2528531491

From iklam at openjdk.org  Fri Nov 14 19:13:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 19:13:04 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
 <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
 <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
Message-ID: <09Z7-ZZkmzO2T0nkSl3czZlkhJPzun79PkiNngWrQcU=.472c6dd5-5f54-42f2-ae16-62cc74c197fe@github.com>

On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> We have seen crashes on many platforms (including x64) while running `make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`:
>> 
>> SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557
>> V  [libjvm.so+0x15bfe7a]  MemAllocator::finish(HeapWordImpl**) const+0xca  (klass.inline.hpp:72)
>> V  [libjvm.so+0x15c029f]  ObjAllocator::initialize(HeapWordImpl**) const+0x2f  (memAllocator.cpp:391)
>> V  [libjvm.so+0xb0630b]  CollectedHeap::fill_with_object(HeapWordImpl**, unsigned long, bool)+0x27b  (collectedHeap.cpp:491)
>> V  [libjvm.so+0x1c7a0bb]  ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b  (threadLocalAllocBuffer.cpp:118)
>> V  [libjvm.so+0x15c0b14]  MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x84  (memAllocator.cpp:286)
>> V  [libjvm.so+0x15c13ab]  MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb  (memAllocator.cpp:340)
>> V  [libjvm.so+0x15c14f9]  MemAllocator::allocate() const+0xa9  (memAllocator.cpp:353)
>> V  [libjvm.so+0x1cc052e]  TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13e  (collectedHeap.inline.hpp:41)
>> V  [libjvm.so+0x16fbc98]  oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38  (typeArrayKlass.hpp:51)
>> V  [libjvm.so+0x106b0f3]  java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0x413  (javaClasses.cpp:1246)
>> V  [libjvm.so+0x14100bc]  Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x66c  (klass.cpp:903)
>> V  [libjvm.so+0xfe2cb1]  InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81  (instanceKlass.cpp:2823)
>> V  [libjvm.so+0x1c0f5ad]  SystemDictionary::preload_class(Handle, InstanceKlass*, JavaThread*)+0x1ed  (systemDictionary.cpp:1198)
>> V  [libjvm.so+0x676e83]  AOTLinkedClassBulkLoader::preload_classes_in_table(Array<InstanceKlass*>*, char const*, Handle, JavaThread*)+0x1a3  (aotLinkedClassBulkLoader.cpp:103)
>> V  [libjvm.so+0x679af5]  AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165  (aotLinkedClassBulkLoader.cpp:76)
>> V  [libjvm.so+0x67c371]  AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11  (aotLinkedClassBulkLoader.cpp:61)
>> V  [libjvm.so+0x1d5bf30]  vmClasses::resolve_all(JavaThread*)+0x3e0  (vmClasses.cpp:126)
>> V  [libjvm.so+0x1c0f28c]  SystemDictionary::initialize(JavaThread*)+0x10c  (systemDictionary.cpp:1623)
>> V  [libjvm.so+0x1cc74ca]  Uni...
>
>> ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"
> 
> I suspect the crash is caused by a preexisting issue that is exposed by this patch.
> 
> In `vmClasses::resolve_all`:
> 
> #if INCLUDE_CDS
>   if (CDSConfig::is_using_aot_linked_classes()) {
>     AOTLinkedClassBulkLoader::preload_classes(THREAD);
>   }
> #endif
> 
>   // Preload commonly used klasses
>   vmClassID scan = vmClassID::FIRST;
>   // first do Object, then String, Class
>   resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK);
>   CollectedHeap::set_filler_object_klass(vmClasses::Object_klass());
> 
> 
> The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj.
> 
> @iklam What do you think?

@albertnetymk I've pushed https://github.com/openjdk/jdk/pull/28315. Please verify if it fixes the crash before integrating this PR. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3534185759

From ayang at openjdk.org  Fri Nov 14 19:22:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 19:22:39 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3]
In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
Message-ID: <GfRPOGf9HVKkF3EbNvPmPFCh_8qoq3ELqXOKtIoXSpY=.99dd57f3-c005-4c86-a408-cd8ebbfbedd9@github.com>

> Trivial removing obsoleted code for unsupported arch.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into remove-tlab-reserve
 - review
 - remove-tlab-reserve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28240/files
  - new: https://git.openjdk.org/jdk/pull/28240/files/0e447848..d6c34da7

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

  Stats: 10141 lines in 159 files changed: 5771 ins; 3554 del; 816 mod
  Patch: https://git.openjdk.org/jdk/pull/28240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28240/head:pull/28240

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

From amenkov at openjdk.org  Fri Nov 14 19:42:21 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 14 Nov 2025 19:42:21 GMT
Subject: Integrated: 8371083: FollowReferences reports non-class objects as
 JVMTI_HEAP_REFERENCE_SYSTEM_CLASS
In-Reply-To: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
References: <6rHIf2ptpmqaSNTLtKNv6bZSQCENxBpxnk3i193hOHE=.dbc266c3-e9b5-4c27-ac5a-5d9ca399ea87@github.com>
Message-ID: <B6il3x3sUI9N3ytMn6L6XhKY8LTZ4_eLPu6r_LrjfBk=.bcb2851a-39a6-4590-8eb2-0d4f02c64f1a@github.com>

On Mon, 10 Nov 2025 20:54:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FollowReferences with null initial_object starts heap walking from "heap roots", which include system classes.
> All oops from ClassLoaderDataGraph are reported with JVMTI_HEAP_REFERENCE_SYSTEM_CLASS kind, but some of the objects are not classes.
> The fix updates FollowReferences to report non-class objects from ClassLoaderDataGraph as JVMTI_HEAP_REFERENCE_OTHER
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: 3924a28a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3924a28a2281bbdb13fe9f1e0b5347d57197f8dc
Stats:     209 lines in 3 files changed: 206 ins; 0 del; 3 mod

8371083: FollowReferences reports non-class objects as JVMTI_HEAP_REFERENCE_SYSTEM_CLASS

Reviewed-by: lmesnik, sspitsyn

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

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

From dcubed at openjdk.org  Fri Nov 14 20:09:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 14 Nov 2025 20:09:08 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
Message-ID: <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>

On Fri, 14 Nov 2025 17:54:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed the test.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:
> 
>> 210:                 argsLeft--;
>> 211:             }
>> 212:             if (argsLeft == 0) {
> 
> Because of the addition of a mandatory argument (test case), argument parsing will
> be more complicated. I need to mull on this a bit and I'll post another suggestion
> after this round.

I emailed you an updated version of the current test (v07) with a better
parser. Feel free to merge it in or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528792374

From sspitsyn at openjdk.org  Fri Nov 14 20:34:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 14 Nov 2025 20:34:19 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v3]
In-Reply-To: <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
Message-ID: <Xbui9s8bbeEqXt7ihTQ1CcXenK2s1b9vbdOEMv8L-ow=.cc9f7017-d569-440b-ba88-beb0978b49ee@github.com>

On Thu, 13 Nov 2025 22:47:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
>> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
>> 
>> Testing:
>>  - TBD: Verify the test with mach5 test runs
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - review: restore original EXPECTED_ACCURACY for Windows
>  - 8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/28206#issuecomment-3534463535

From marcus.hirt at datadoghq.com  Fri Nov 14 21:20:34 2025
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 14 Nov 2025 22:20:34 +0100
Subject: Virtual Serviceability Meetup 2025
Message-ID: <CAOpWGx2vnS-BR7txfsw_+cLSrm+TzrUuY+rr+V1+KYO3K1JH+A@mail.gmail.com>

Hi all,

The 17th of December we're organizing another OpenJDK Serviceability Meetup!
Last time [1] 39 attendees from various companies (Oracle, Red Hat, Amazon,
SAP, Datadog, Jetbrains, and more) came together to discuss problems and
potential solutions related to OpenJDK serviceability.

If you?re interested in participating, here?s the registration form:
https://forms.gle/jFhiX8Wwfka58T8Z8

And here is a link to the form to propose topics:
https://forms.gle/dnM79D43wbKnef7m6

Registration is open until the 28th of November.

Hope to see you there!

Kind regards,
Marcus

[1]: https://mail.openjdk.org/pipermail/serviceability-dev/2024-July/056669.html

From duke at openjdk.org  Fri Nov 14 21:21:16 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 14 Nov 2025 21:21:16 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v12]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <jZ5Ymz6Gv7krZaEXCxUYSoaADTkR_YC5aF4LMMlKsjk=.ce6f39b3-4ca1-4579-bc4c-928de8da3836@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Reduce GC coverage for trivial API test"
  
  This reverts commit 8fd1ee093066138c9aa5602dcac0e7db1916db6b.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/8fd1ee09..97978d04

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

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

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

From duke at openjdk.org  Fri Nov 14 21:23:22 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Nov 2025 21:23:22 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v11]
In-Reply-To: <dXmRDaV78jjwZ8nQOg5FmXQ7olZ3hlmACw3vZxHuBUI=.c0a24ae5-353f-4be2-8100-8355398e9794@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <dXmRDaV78jjwZ8nQOg5FmXQ7olZ3hlmACw3vZxHuBUI=.c0a24ae5-353f-4be2-8100-8355398e9794@github.com>
Message-ID: <jcimEiOxRb6305YXlY0XM2RN-_I9lIyAKyxyG8LhQBo=.2b87e3fb-ace7-4ed0-9c55-6aca312e1bd4@github.com>

On Fri, 14 Nov 2025 11:29:48 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce GC coverage for trivial API test

@JonasNorlinder 
Your change (at version 97978d04c241061cd0fdf656748bfe08da88017a) is now ready to be sponsored by a Committer.

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

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

From lmesnik at openjdk.org  Fri Nov 14 22:52:07 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 14 Nov 2025 22:52:07 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v3]
In-Reply-To: <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
Message-ID: <Zw9TumVquztUFBJHw91cgMFnKSROj0mPdaZN9xww-TE=.195c26df-783c-47ce-8b8d-564168d1e94c@github.com>

On Thu, 13 Nov 2025 22:47:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
>> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
>> 
>> Testing:
>>  - TBD: Verify the test with mach5 test runs
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - review: restore original EXPECTED_ACCURACY for Windows
>  - 8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28206#pullrequestreview-3467119221

From sspitsyn at openjdk.org  Fri Nov 14 23:08:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 14 Nov 2025 23:08:04 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v3]
In-Reply-To: <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <CZZN3OhaShe6D5TxdNIVdSd-xhoHOTVcG3oa-UW5P58=.245903b3-4014-4a20-883d-70bb487f0e7d@github.com>
Message-ID: <wlpVWtL3aDIj4Vc7ezwMy7CiQgrLqrCrdX-Aceod1pk=.d2357d3e-c062-47fa-90e2-e7eea3c558c2@github.com>

On Thu, 13 Nov 2025 22:47:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
>> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
>> 
>> Testing:
>>  - TBD: Verify the test with mach5 test runs
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - review: restore original EXPECTED_ACCURACY for Windows
>  - 8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

Thank you for review, Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/28206#issuecomment-3534991646

From ysuenaga at openjdk.org  Sat Nov 15 01:35:07 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 15 Nov 2025 01:35:07 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <4dipoan9jnaJpGdBc2b4tpnEDvxsIOSjSPrvIMwnka8=.1ad85705-c8d1-46a2-b364-2a5880386845@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <4dipoan9jnaJpGdBc2b4tpnEDvxsIOSjSPrvIMwnka8=.1ad85705-c8d1-46a2-b364-2a5880386845@github.com>
Message-ID: <4BLSKl8w2Lhm2HDKDQ6jwVRsWQMssF_tUak9wNk5mkg=.36bcf655-a812-4b2b-86b7-1f02251740a9@github.com>

On Fri, 14 Nov 2025 18:36:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for Linux PPC64 and RISC-V
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:
> 
>> 38:  * @requires vm.hasSA
>> 39:  * @requires os.family == "linux"
>> 40:  * @requires os.arch == "amd64"
> 
> Can't we run the test on AArch64 now?

I think this PR works on Linux AArch64, but I'm not sure because previous change (#27885) worked on some Linux AArch64, but there are some platforms whch did not work. Thus I think it is better to keep this test for Linux AMD64 only.

I couldn't reproduce the problem on Fedora Rawhide on Raspberry Pi 4, but there might be some issue because SA does not have DWARF parser for AArch 64 - it means the native we cannot find sender frame which depends on DWARF, does not use FP as frame pointer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28284#discussion_r2529372235

From sspitsyn at openjdk.org  Sat Nov 15 01:54:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 15 Nov 2025 01:54:20 GMT
Subject: Integrated: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000)
In-Reply-To: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
Message-ID: <W7rnZmppwV-HHYiGg5XrL-UwlmjOYNKBPhyt_eQmLMA=.6cc1740f-5b0a-494a-85df-7f3d086c5f4d@github.com>

On Sat, 8 Nov 2025 00:15:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fix is to increase the `EXPECTED_ACCURACY` value in the test:
>  `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`.
> It is used check that the waiting time between `MonitorWait` and `MonitorWaited` event is not big. It seems that in some corner cases this time can be bigger than expected.
> 
> Testing:
>  - TBD: Verify the test with mach5 test runs

This pull request has now been integrated.

Changeset: f971ee5e
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f971ee5ea07e3e1c0efe447a416e7242f5e46a16
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

Reviewed-by: cjplummer, lmesnik

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

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

From syan at openjdk.org  Sat Nov 15 04:09:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 04:09:01 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <hkbUvD3G8QD-16jDxz6WF4glYdJioe21VMFm_3FWlSQ=.979554d6-1616-404f-9d20-7dfe7e733d24@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Looking for 2rd reviewer, since this PR touch files in hotspot directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3535663799

From mdoerr at openjdk.org  Sun Nov 16 13:23:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 16 Nov 2025 13:23:07 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2]
In-Reply-To: <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <VnTN97dwJGOLVspnLZ6c1sEG2cujhDY5v6s9HNN4NEw=.933ff17f-47cf-415e-aa8f-9a2493b4fedb@github.com>
 <tczdA21nRfpWOSsdlVgUiH9T4nVrCge4NAfH1kfz23U=.4a9a91b1-583e-4db8-9d80-303257d2ba36@github.com>
 <enUmfXbdJKWFMZtZ0bpS4aEmp_ayQTzgXlpA3nbJ48k=.e8745cdc-ab7a-4652-aa58-af59988b2dde@github.com>
Message-ID: <kOm8CCLamBKVgr_jFluAJYb9jV819wzpdBy_KRE1Wng=.8b9e2600-6620-4bc8-86e3-42b7e2d756dd@github.com>

On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> We have seen crashes on many platforms (including x64) while running `make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`:
>> 
>> SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557
>> V  [libjvm.so+0x15bfe7a]  MemAllocator::finish(HeapWordImpl**) const+0xca  (klass.inline.hpp:72)
>> V  [libjvm.so+0x15c029f]  ObjAllocator::initialize(HeapWordImpl**) const+0x2f  (memAllocator.cpp:391)
>> V  [libjvm.so+0xb0630b]  CollectedHeap::fill_with_object(HeapWordImpl**, unsigned long, bool)+0x27b  (collectedHeap.cpp:491)
>> V  [libjvm.so+0x1c7a0bb]  ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b  (threadLocalAllocBuffer.cpp:118)
>> V  [libjvm.so+0x15c0b14]  MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x84  (memAllocator.cpp:286)
>> V  [libjvm.so+0x15c13ab]  MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb  (memAllocator.cpp:340)
>> V  [libjvm.so+0x15c14f9]  MemAllocator::allocate() const+0xa9  (memAllocator.cpp:353)
>> V  [libjvm.so+0x1cc052e]  TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13e  (collectedHeap.inline.hpp:41)
>> V  [libjvm.so+0x16fbc98]  oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38  (typeArrayKlass.hpp:51)
>> V  [libjvm.so+0x106b0f3]  java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0x413  (javaClasses.cpp:1246)
>> V  [libjvm.so+0x14100bc]  Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x66c  (klass.cpp:903)
>> V  [libjvm.so+0xfe2cb1]  InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81  (instanceKlass.cpp:2823)
>> V  [libjvm.so+0x1c0f5ad]  SystemDictionary::preload_class(Handle, InstanceKlass*, JavaThread*)+0x1ed  (systemDictionary.cpp:1198)
>> V  [libjvm.so+0x676e83]  AOTLinkedClassBulkLoader::preload_classes_in_table(Array<InstanceKlass*>*, char const*, Handle, JavaThread*)+0x1a3  (aotLinkedClassBulkLoader.cpp:103)
>> V  [libjvm.so+0x679af5]  AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165  (aotLinkedClassBulkLoader.cpp:76)
>> V  [libjvm.so+0x67c371]  AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11  (aotLinkedClassBulkLoader.cpp:61)
>> V  [libjvm.so+0x1d5bf30]  vmClasses::resolve_all(JavaThread*)+0x3e0  (vmClasses.cpp:126)
>> V  [libjvm.so+0x1c0f28c]  SystemDictionary::initialize(JavaThread*)+0x10c  (systemDictionary.cpp:1623)
>> V  [libjvm.so+0x1cc74ca]  Uni...
>
>> ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"
> 
> I suspect the crash is caused by a preexisting issue that is exposed by this patch.
> 
> In `vmClasses::resolve_all`:
> 
> #if INCLUDE_CDS
>   if (CDSConfig::is_using_aot_linked_classes()) {
>     AOTLinkedClassBulkLoader::preload_classes(THREAD);
>   }
> #endif
> 
>   // Preload commonly used klasses
>   vmClassID scan = vmClassID::FIRST;
>   // first do Object, then String, Class
>   resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK);
>   CollectedHeap::set_filler_object_klass(vmClasses::Object_klass());
> 
> 
> The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj.
> 
> @iklam What do you think?

> @albertnetymk I've pushed #28315. Please verify if it fixes the crash before integrating this PR. Thanks!

The crashes are fixed. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538748578

From mdoerr at openjdk.org  Sun Nov 16 13:42:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 16 Nov 2025 13:42:02 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com>
Message-ID: <Xz2JFSgjMEQIjsEWv_9brmmQ0QcZNzxWoCXH2rTLkEQ=.908e8387-1415-4630-9e26-41152251d4b0@github.com>

On Tue, 11 Nov 2025 16:18:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Please ask all OpenJDK platforms supporters to test these changes.
> 
> Note, when this code was introduced we did not have so many platforms.

This change looks incomplete to me. @vnkozlov: Shouldn't we remove `AllocatePrefetchStyle == 3` completely? `PhaseMacroExpand::prefetch_allocation` still mentions "BIS instruction is used on SPARC as prefetch". Please note that PPC64 also still has an implementation for it (nodes with `predicate(AllocatePrefetchStyle == 3)`). I guess that we don't need it any more. Maybe we should check performance again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538765487

From ayang at openjdk.org  Sun Nov 16 17:19:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 16 Nov 2025 17:19:13 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3]
In-Reply-To: <GfRPOGf9HVKkF3EbNvPmPFCh_8qoq3ELqXOKtIoXSpY=.99dd57f3-c005-4c86-a408-cd8ebbfbedd9@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <GfRPOGf9HVKkF3EbNvPmPFCh_8qoq3ELqXOKtIoXSpY=.99dd57f3-c005-4c86-a408-cd8ebbfbedd9@github.com>
Message-ID: <xv94zcT4lo-9bCp8N0YWEuQ_Zyb32Y5eQrCIqBXKFZE=.c9733b22-5b81-4ff3-acea-db392840e181@github.com>

On Fri, 14 Nov 2025 19:22:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-tlab-reserve
>  - review
>  - remove-tlab-reserve

`AllocatePrefetchStyle == 3` means "generate one prefetch instruction per cache line".

This patch removes the reserved alignment that was required for `AllocatePrefetchStyle == 3` on SPARC, but that does not imply that `AllocatePrefetchStyle == 3` itself should be removed. (Maybe a separate ticket if it's indeed deemed useless.)

> PhaseMacroExpand::prefetch_allocation still mentions "BIS instruction is used on SPARC as prefetch".

Will remove it in the next revision.

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538970541

From mdoerr at openjdk.org  Sun Nov 16 21:13:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 16 Nov 2025 21:13:05 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3]
In-Reply-To: <GfRPOGf9HVKkF3EbNvPmPFCh_8qoq3ELqXOKtIoXSpY=.99dd57f3-c005-4c86-a408-cd8ebbfbedd9@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <GfRPOGf9HVKkF3EbNvPmPFCh_8qoq3ELqXOKtIoXSpY=.99dd57f3-c005-4c86-a408-cd8ebbfbedd9@github.com>
Message-ID: <X34gve35WJ4VpFchOyUxXEhvk7b9Qgk2-TlerCdaEBg=.fa841160-e7ec-4a38-9e32-2c3c7abfff2e@github.com>

On Fri, 14 Nov 2025 19:22:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-tlab-reserve
>  - review
>  - remove-tlab-reserve

At least PPC64 will need an update because your change breaks the following nodes:

diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad
index 7fcd096d2ad..c169d673aaf 100644
--- a/src/hotspot/cpu/ppc/ppc.ad
+++ b/src/hotspot/cpu/ppc/ppc.ad
@@ -6328,36 +6328,8 @@ instruct loadConD_Ex(regD dst, immD src) %{
 // Prefetch instructions.
 // Must be safe to execute with invalid address (cannot fault).
 
-// Special prefetch versions which use the dcbz instruction.
-instruct prefetch_alloc_zero(indirectMemory mem, iRegLsrc src) %{
-  match(PrefetchAllocation (AddP mem src));
-  predicate(AllocatePrefetchStyle == 3);
-  ins_cost(MEMORY_REF_COST);
-
-  format %{ "PREFETCH $mem, 2, $src \t// Prefetch write-many with zero" %}
-  size(4);
-  ins_encode %{
-    __ dcbz($src$$Register, $mem$$base$$Register);
-  %}
-  ins_pipe(pipe_class_memory);
-%}
-
-instruct prefetch_alloc_zero_no_offset(indirectMemory mem) %{
-  match(PrefetchAllocation mem);
-  predicate(AllocatePrefetchStyle == 3);
-  ins_cost(MEMORY_REF_COST);
-
-  format %{ "PREFETCH $mem, 2 \t// Prefetch write-many with zero" %}
-  size(4);
-  ins_encode %{
-    __ dcbz($mem$$base$$Register);
-  %}
-  ins_pipe(pipe_class_memory);
-%}
-
 instruct prefetch_alloc(indirectMemory mem, iRegLsrc src) %{
   match(PrefetchAllocation (AddP mem src));
-  predicate(AllocatePrefetchStyle != 3);
   ins_cost(MEMORY_REF_COST);
 
   format %{ "PREFETCH $mem, 2, $src \t// Prefetch write-many" %}
@@ -6370,7 +6342,6 @@ instruct prefetch_alloc(indirectMemory mem, iRegLsrc src) %{
 
 instruct prefetch_alloc_no_offset(indirectMemory mem) %{
   match(PrefetchAllocation mem);
-  predicate(AllocatePrefetchStyle != 3);
   ins_cost(MEMORY_REF_COST);
 
   format %{ "PREFETCH $mem, 2 \t// Prefetch write-many" %}

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3539357960

From dholmes at openjdk.org  Mon Nov 17 01:12:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Nov 2025 01:12:19 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
 <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
 <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>
Message-ID: <cnSL0lyY9zRoMcw10nBuVrBHUkVNkMxsrFEXoF0Q6kg=.b4ecf7f8-b697-49f1-b9ba-4458d1311d2c@github.com>

On Wed, 12 Nov 2025 22:45:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp line 45:
>> 
>>> 43: static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock update interval
>>> 44: #else
>>> 45: static const jlong EXPECTED_ACCURACY = 32; // high frequency clock updates expected
>> 
>> The comments are somewhat misleading now. We choose 16 on WIN32 because that is the smallest interval allowed. We expect better clock refinement on other platforms and therefore better accuracy. Thus 10ms was chosen. Now we have one test case that was just over 16ms. Is there a reason to believe that couldn't happen with WIN32 also. If not, then the comments should reflect that.
>
> I feel that all these checks are just a source of this test instability. :)
> I'm not sure I fully understand why those are needed and what was the original design. It is always possible to have some delays in waiting time, so the original assumptions about expected accuracy are not fully correct as they are a little bit overly strong.
> From this point of view, I do not see why the comments are confusing. The `EXPECTED_ACCURACY` values are just based on the high frequency clock updates interval but should not be equal to it.
> Would you like me to change the comments to something like below ? :
>   `high frequency clock updates expected`
>     =>
>   `expected accuracy is based on high frequency clock updates`
>   I do not want to change the Windows part until any failure is observed but can update the comment for consistency.

This is wrong. The "expected" accuracy is still 10ms or even 1ms, it is never 32ms. The test may need to wait longer but changing this value makes no sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2532387592

From cjplummer at openjdk.org  Mon Nov 17 03:14:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 17 Nov 2025 03:14:21 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <cnSL0lyY9zRoMcw10nBuVrBHUkVNkMxsrFEXoF0Q6kg=.b4ecf7f8-b697-49f1-b9ba-4458d1311d2c@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
 <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
 <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>
 <cnSL0lyY9zRoMcw10nBuVrBHUkVNkMxsrFEXoF0Q6kg=.b4ecf7f8-b697-49f1-b9ba-4458d1311d2c@github.com>
Message-ID: <6OyfaZdrxTVlW9fdpnuttddsAMPIRHXCE1oAPzCvj7A=.d92c4650-ce57-4ee6-b752-720ba524028b@github.com>

On Mon, 17 Nov 2025 01:10:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I feel that all these checks are just a source of this test instability. :)
>> I'm not sure I fully understand why those are needed and what was the original design. It is always possible to have some delays in waiting time, so the original assumptions about expected accuracy are not fully correct as they are a little bit overly strong.
>> From this point of view, I do not see why the comments are confusing. The `EXPECTED_ACCURACY` values are just based on the high frequency clock updates interval but should not be equal to it.
>> Would you like me to change the comments to something like below ? :
>>   `high frequency clock updates expected`
>>     =>
>>   `expected accuracy is based on high frequency clock updates`
>>   I do not want to change the Windows part until any failure is observed but can update the comment for consistency.
>
> This is wrong. The "expected" accuracy is still 10ms or even 1ms, it is never 32ms. The test may need to wait longer but changing this value makes no sense.

I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is being used as a max amount of elapsed time, not as an "accuracy" value. The comment on the WIN32 part just adds to the confusion. The "max elapsed time" has to be 16 ms because that is the clock is only accurate to 16ms, so even 1ms of elapsed times will show up as 16ms. The comment "16ms is longest clock update interval" should read "shortest", not "longest". 

EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2532529663

From ayang at openjdk.org  Mon Nov 17 09:35:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Nov 2025 09:35:49 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4]
In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
Message-ID: <uNhXBj43RFhFtF_e4hHstfJe-Y0HY4IxdPhBPUwo3RU=.f8d0a602-2be9-404f-a4e8-4db43ac8af04@github.com>

> Trivial removing obsoleted code for unsupported arch.
> 
> Test: tier1

Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:

 - review
 - patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28240/files
  - new: https://git.openjdk.org/jdk/pull/28240/files/d6c34da7..6c5a07ec

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

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

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

From mdoerr at openjdk.org  Mon Nov 17 09:53:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 17 Nov 2025 09:53:16 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4]
In-Reply-To: <uNhXBj43RFhFtF_e4hHstfJe-Y0HY4IxdPhBPUwo3RU=.f8d0a602-2be9-404f-a4e8-4db43ac8af04@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <uNhXBj43RFhFtF_e4hHstfJe-Y0HY4IxdPhBPUwo3RU=.f8d0a602-2be9-404f-a4e8-4db43ac8af04@github.com>
Message-ID: <tqkTKb101WDe8fVCo_3tjocrC4068o7YnKxHviKh_Qg=.1254bfc4-c82b-40e6-b373-20989d0232eb@github.com>

On Mon, 17 Nov 2025 09:35:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - patch

Thanks for the updates! `make run-test TEST=test/hotspot/jtreg/compiler/c2 JTREG="VM_OPTIONS=-XX:AllocatePrefetchStyle=3"` has passed on PPC64. I agree, the general AllocatePrefetchStyle==3 topic can be discussed separately.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28240#pullrequestreview-3471900133

From kevinw at openjdk.org  Mon Nov 17 10:45:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Nov 2025 10:45:34 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
 [v12]
In-Reply-To: <jZ5Ymz6Gv7krZaEXCxUYSoaADTkR_YC5aF4LMMlKsjk=.ce6f39b3-4ca1-4579-bc4c-928de8da3836@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <jZ5Ymz6Gv7krZaEXCxUYSoaADTkR_YC5aF4LMMlKsjk=.ce6f39b3-4ca1-4579-bc4c-928de8da3836@github.com>
Message-ID: <4qjsyzSPqc8GERYbwMkCVTvoa547lAHi2in0d1MotCY=.7f7d0fcd-bc20-49e6-833a-3ec2404006f8@github.com>

On Fri, 14 Nov 2025 21:21:16 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Reduce GC coverage for trivial API test"
>   
>   This reverts commit 8fd1ee093066138c9aa5602dcac0e7db1916db6b.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3472086274

From duke at openjdk.org  Mon Nov 17 10:45:36 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 17 Nov 2025 10:45:36 GMT
Subject: Integrated: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <cVXmLYpGu7PqdQd_zRziS4Jhc9Y0140oII9Sn-cb7TQ=.fee868cb-122b-466e-b551-752e71b5a9ea@github.com>

On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

This pull request has now been integrated.

Changeset: 812add27
Author:    Jonas Norlinder <jonas.norlinder at oracle.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/812add27abdc70bc52ca105bc9430494a6491ecd
Stats:     305 lines in 12 files changed: 302 ins; 1 del; 2 mod

8368527: JMX: Add an MXBeans method to query GC CPU time

Reviewed-by: phh, kevinw

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

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

From duke at openjdk.org  Mon Nov 17 12:14:07 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 17 Nov 2025 12:14:07 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <-h6G9ajUWQwDRcUMOtyI_YCUCkXz3pzRggJk_UaxM-0=.a8c772aa-2f09-48c0-9cfb-17e624393eb0@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <-h6G9ajUWQwDRcUMOtyI_YCUCkXz3pzRggJk_UaxM-0=.a8c772aa-2f09-48c0-9cfb-17e624393eb0@github.com>
Message-ID: <Us6SbX-VztiIbBdDMeEvzGAllBgnZSnzCb4B7zpkUrU=.133050a6-fd59-490e-94f3-96280909d6f0@github.com>

On Thu, 13 Nov 2025 07:54:32 GMT, Ruben <duke at openjdk.org> wrote:

> However, I still have not identified a way to ensure the deopt handler stub ends at a page boundary in a unit test.

The latest update implements an alternative way to detect the failure early during testing - via the newly added assertion in the `emit_deopt_handler`.

@adinn, @dean-long, @TheRealMDoerr, would it be possible for you to review the latest version of the PR?

Is there any additional testing you would recommend to perform before this can be integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3541484205

From kevinw at openjdk.org  Mon Nov 17 13:30:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Nov 2025 13:30:14 GMT
Subject: RFR: 8371991: Build failure in docs for MemoryMXBean
Message-ID: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>

Build failure after JDK-8368527 due to Javadoc linking between modules, causes a failure in "make docs-javase"
Remove the link and the existing warning suppression, change formatting.

This is part of an advisory apiNote which refers to other existing CPU timing methods in jdk.management, from java.management.

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

Commit messages:
 - 8371991: Build failure in docs for MemoryMXBean

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

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

From mdoerr at openjdk.org  Mon Nov 17 13:32:21 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 17 Nov 2025 13:32:21 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
Message-ID: <R01zEQTaztshYZkQ0J8X12R7BbLWPQQJTuxujX6zYP8=.ded457cb-fe2a-4abe-8678-31da237363e7@github.com>

On Thu, 13 Nov 2025 23:49:28 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an assertion to detect out of bounds access in post-call NOP checks

I think assertions would be sufficient in C1 instead of guarantee. But, ok. I'll put it into our test queue.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28192#pullrequestreview-3472719238

From alanb at openjdk.org  Mon Nov 17 13:35:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 13:35:24 GMT
Subject: RFR: 8371991: Build failure in docs for MemoryMXBean
In-Reply-To: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
References: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
Message-ID: <hJ5IKvtVGS2nXlESM5lBZiWyRGQ1hhHtTbjWWFezDsk=.07a5402a-d94c-4163-ba94-b48b3584b5e5@github.com>

On Mon, 17 Nov 2025 13:23:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Build failure after JDK-8368527 due to Javadoc linking between modules, causes a failure in "make docs-javase"
> Remove the link and the existing warning suppression, change formatting.
> 
> This is part of an advisory apiNote which refers to other existing CPU timing methods in jdk.management, from java.management.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28350#pullrequestreview-3472727251

From duke at openjdk.org  Mon Nov 17 13:35:25 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 17 Nov 2025 13:35:25 GMT
Subject: RFR: 8371991: Build failure in docs for MemoryMXBean
In-Reply-To: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
References: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
Message-ID: <YPsqXWppmpt_uH8vjwov1NQOsQNc6GD5b565dDkNvq4=.fe00d984-ff1f-402c-a9d0-77255d56a282@github.com>

On Mon, 17 Nov 2025 13:23:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Build failure after JDK-8368527 due to Javadoc linking between modules, causes a failure in "make docs-javase"
> Remove the link and the existing warning suppression, change formatting.
> 
> This is part of an advisory apiNote which refers to other existing CPU timing methods in jdk.management, from java.management.

LGTM. Thanks Kevin!

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

Marked as reviewed by JonasNorlinder at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28350#pullrequestreview-3472730382

From kevinw at openjdk.org  Mon Nov 17 13:35:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Nov 2025 13:35:26 GMT
Subject: RFR: 8371991: Build failure in docs for MemoryMXBean
In-Reply-To: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
References: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
Message-ID: <gTQvg5dFYk1NGHDjFoz7SasGny_0PpgKf2KdSP3dfFo=.3f085559-8d09-4208-bdf4-0d89edcf1917@github.com>

On Mon, 17 Nov 2025 13:23:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Build failure after JDK-8368527 due to Javadoc linking between modules, causes a failure in "make docs-javase"
> Remove the link and the existing warning suppression, change formatting.
> 
> This is part of an advisory apiNote which refers to other existing CPU timing methods in jdk.management, from java.management.

Thanks Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/28350#issuecomment-3541858039

From kevinw at openjdk.org  Mon Nov 17 13:43:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Nov 2025 13:43:28 GMT
Subject: Integrated: 8371991: Build failure in docs for MemoryMXBean
In-Reply-To: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
References: <UMgw46wGlmPSxICZI6nvwkCUFY6wz1hOZNHkzfz3PeE=.08d636fe-8b2d-493e-87cd-607a039f1b8e@github.com>
Message-ID: <5y--xSzUBzgg-krK1QNHtThGOZUu41byXpoLacltv8M=.5a512b1d-5976-41b0-be3d-9da2877c8cf5@github.com>

On Mon, 17 Nov 2025 13:23:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Build failure after JDK-8368527 due to Javadoc linking between modules, causes a failure in "make docs-javase"
> Remove the link and the existing warning suppression, change formatting.
> 
> This is part of an advisory apiNote which refers to other existing CPU timing methods in jdk.management, from java.management.

This pull request has now been integrated.

Changeset: 960987e8
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/960987e8c1428ce1d89ee13e007e06206fe6885c
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8371991: Build failure in docs for MemoryMXBean

Reviewed-by: alanb

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

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

From aartemov at openjdk.org  Mon Nov 17 13:50:30 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:30 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/2ac18b94..28725284

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

  Stats: 81 lines in 1 file changed: 49 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Mon Nov 17 13:50:38 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
Message-ID: <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>

On Fri, 14 Nov 2025 18:07:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed the test.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 124:
> 
>> 122: // launch resumer       enter threadLock
>> 123: // <launch returns>     while !READY_TO_NOTIFY  resumer running
>> 124: // delay 1-second         threadLock.wait(1)    wait for notify
> 
> We've deleted this sleep, so this line should change from:
> 
> // delay 1-second         threadLock.wait(1)    wait for notify
> 
> to:
> 
> // :                      threadLock.wait(1)    wait for notify

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 128:
> 
>> 126: // set READY_TO_NOTIFY  :
>> 127: // threadLock.notify    wait finishes           :
>> 128: // :                    reenter blocks          :
> 
> We added a sleep here, so this line should change from:
> 
> // :                    reenter blocks          :
> 
> to:
> 
> // : delay 200ms        reenter blocks          :

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 153:
> 
>> 151: //       thread allows the waiter thread to loop tightly here:
>> 152: //         while !READY_TO_NOTIFY
>> 153: //           threadLock.wait(1)
> 
> Please replace this note with the following:
> 
> // Note: sleep(200ms) here while holding the threadLock to allow the waiter thread's
> // timed wait to finish before we attempt to suspend the waiter thread.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 237:
> 
>> 235: 
>> 236:     public static void usage() {
>> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
> 
> The `N` argument is not optional so it should not be surrounded by `[` and `]`.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 239:
> 
>> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
>> 238:         System.err.println("where:");
>> 239:         System.err.println("    N        ::= test case");
> 
> s/case/case: 1 | 2 | 3/

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 470:
> 
>> 468:                 }
>> 469:                 try {
>> 470:                     Thread.sleep(1000);
> 
> Please add something like this above the `sleep`:
> 
> // Delay for 1-second while holding the threadLock to force the
> // resumer thread to block on entering the threadLock.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:
> 
>> 550:                 // wait for the waiter thread to block
>> 551:                 logDebug("before contended enter wait");
>> 552:                 int retCode = wait4ContendedEnter(waiter);
> 
> Since we are waiting here for ContendedEnter by the waiter thread, do we really
> need the above `sleep(200)` or are we just being polite CPU resource wise?

Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 592:
> 
>> 590:                 }
>> 591:                 try {
>> 592:                     Thread.sleep(1000);
> 
> Please add something like this above the sleep:
> 
> // Delay for 1-second while holding the threadLock to force the
> // resumer thread to block on entering the threadLock.

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136973
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534137344
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534137633
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135509
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135744
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534138176
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136258
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136725

From aartemov at openjdk.org  Mon Nov 17 13:50:39 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>
Message-ID: <n9Zhw7amVqdxFuJxxiZQPoD3M-zo1nEkH2aafiiLYsA=.5fa6eccb-dcfb-49be-b368-bcd01ad666ce@github.com>

On Fri, 14 Nov 2025 20:05:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:
>> 
>>> 210:                 argsLeft--;
>>> 211:             }
>>> 212:             if (argsLeft == 0) {
>> 
>> Because of the addition of a mandatory argument (test case), argument parsing will
>> be more complicated. I need to mull on this a bit and I'll post another suggestion
>> after this round.
>
> I emailed you an updated version of the current test (v07) with a better
> parser. Feel free to merge it in or not.

Thanks, I added your parsing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135964

From xuelei at openjdk.org  Mon Nov 17 18:27:26 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 17 Nov 2025 18:27:26 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v18]
In-Reply-To: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
 <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com>
Message-ID: <WFamkhPRrkpcbJPucvcRb4pEUdPJAamwTcn4p_FYW-U=.712335f4-a7fd-407e-9484-bbdbf43b75c3@github.com>

On Fri, 7 Nov 2025 15:25:49 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove -server in test for static GHA build
>
> Thank you for the reviews everyone!

@fisk Is there any chance to backport this update to 25?

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3543306783

From eosterlund at openjdk.org  Mon Nov 17 19:02:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 17 Nov 2025 19:02:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v18]
In-Reply-To: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <UltMYd8YMhZgvf-tVwA5dlN0L1NXMrBfNKOiEvkcHzs=.4156669e-e3a2-4d45-8bb9-24743f5d8703@github.com>
 <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com>
Message-ID: <Pu9KJ6o4pLS1nND91hYq8kbDAa0ehg4NBS3f1Y5e3gE=.a40c083f-17bf-4bed-8328-352d15b505f7@github.com>

On Fri, 7 Nov 2025 15:25:49 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove -server in test for static GHA build
>
> Thank you for the reviews everyone!

> @fisk Is there any chance to backport this update to 25?

Unfortunately, we generally do not backport JEPs. But the next LTS is just around the corner, in the grand scheme of things.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3543420953

From dcubed at openjdk.org  Mon Nov 17 19:30:43 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 17 Nov 2025 19:30:43 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
Message-ID: <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>

On Mon, 17 Nov 2025 13:50:30 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Addressed reviewer's comments.

Marked as reviewed by dcubed (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 140:

> 138: // launch resumer       enter threadLock
> 139: // <launch returns>     while !READY_TO_NOTIFY  resumer running
> 140: // :                    threadLock.wait(1)      wait for notify

The wait(1) call is in the while-loop. Please insert two spaces before the `threadlock.wait(1)` call.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 235:

> 233:                 } catch (NumberFormatException nfe) {
> 234:                     System.err.println("'" + args[argIndex] +
> 235:                             "': invalid test_case value.");

The leading double quote should be lined up with the one on the previous line.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 251:

> 249:                 } catch (NumberFormatException nfe) {
> 250:                     System.err.println("'" + args[argIndex] +
> 251:                             "': invalid time_max value.");

The leading double quote should be lined up with the one on the previous line.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3474239279
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535265622
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535273619
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535274696

From dcubed at openjdk.org  Mon Nov 17 19:34:28 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 17 Nov 2025 19:34:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
Message-ID: <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>

On Mon, 17 Nov 2025 13:45:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:
>> 
>>> 550:                 // wait for the waiter thread to block
>>> 551:                 logDebug("before contended enter wait");
>>> 552:                 int retCode = wait4ContendedEnter(waiter);
>> 
>> Since we are waiting here for ContendedEnter by the waiter thread, do we really
>> need the above `sleep(200)` or are we just being polite CPU resource wise?
>
> Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?

Sorry, I wasn't very clear. I'm questioning the need for the 200ms delay since our call
to `wait4ContendedEnter` will already delay the calling thread. Since @pchilano requested
the addition of the 200ms delay, he should probably chime in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535285282

From pchilanomate at openjdk.org  Mon Nov 17 21:14:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 17 Nov 2025 21:14:03 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <nZp3A9ifzFeJJe6bh_iNUjcl8jHqv2eV6PcIK-xsWuc=.21325d70-b5b2-4223-adc1-34f06c600930@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28284#pullrequestreview-3474569448

From pchilanomate at openjdk.org  Mon Nov 17 21:53:04 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 17 Nov 2025 21:53:04 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent
Message-ID: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>

When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.

This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:

- Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. An alternative that avoids the extra fence would be to place extra overhead on the thread requesting to disable transitions (e.g. by using
  a safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so I believe this approach is simpler.

- Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.

- The code was structured in terms of mount and unmount cases, and a variable was used to differentiate between start or end of the transition. With the changes to make the mechanism independent of JVMTI it becomes simpler to invert this and structure the code in terms of start transition and end transition, and use a variable to differentiate between mount and unmount cases.

- All JVMTI code required during start/end transitions has been encapsulated in classes `JVMTIStartTransition` and `JVMTIEndTransition`. I kept the ordering of event posting as it is today.

- Global variables `_sync_protocol_enabled_count` and `_sync_protocol_enabled_permanently` were removed. Variable `_VTMS_transition_disable_for_all_count` was renamed to `_global_start_transition_disable_count`, `_SR_mode` to `_exclusive_operation_ongoing` and `_VTMS_notify_jvmti_events` to `_notify_jvmti_events`. New global variable `_active_disablers` replaces the functionality of `_VTMS_transition_disable_for_one_count`.

- Now, when the first agent attaches we not only set `_notify_jvmti_events` but we also increase global counter `_global_start_transition_disable_count`. This has the effect of always forcing the slow path when starting and ending a transition as we do today when `_VTMS_notify_jvmti_events` is set.

A new `Handshake::execute` variant to handshake a virtual thread is introduced with this patch, which makes use of the new `MountUnmountDisabler` class. Method `ThreadSnapshotFactory::get_thread_snapshot` has been simplified to use this handshake variant to capture the snapshot of a virtual thread.

The changes include new test `DumpThreadsWhenParking.java` from @AlanBateman which reliably reproduces the issue. I also verified the changes in Mach5 tiers1-7.

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/28361/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364343
  Stats: 1848 lines in 40 files changed: 844 ins; 824 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

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

From jnorlinder at openjdk.org  Mon Nov 17 21:56:39 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Mon, 17 Nov 2025 21:56:39 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some GC
 CPU time must have been reported)
Message-ID: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>

Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.

Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

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

Commit messages:
 - Add some work for GC

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

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

From sspitsyn at openjdk.org  Mon Nov 17 22:51:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 17 Nov 2025 22:51:13 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <6OyfaZdrxTVlW9fdpnuttddsAMPIRHXCE1oAPzCvj7A=.d92c4650-ce57-4ee6-b752-720ba524028b@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
 <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
 <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>
 <cnSL0lyY9zRoMcw10nBuVrBHUkVNkMxsrFEXoF0Q6kg=.b4ecf7f8-b697-49f1-b9ba-4458d1311d2c@github.com>
 <6OyfaZdrxTVlW9fdpnuttddsAMPIRHXCE1oAPzCvj7A=.d92c4650-ce57-4ee6-b752-720ba524028b@github.com>
Message-ID: <fcRFPMd7RyZ89ChV1u50kyC1Cv5OkMPVsqVcE1RR_tQ=.c9f455ea-abf0-4ed6-b41a-de62c26723ed@github.com>

On Mon, 17 Nov 2025 03:11:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is wrong. The "expected" accuracy is still 10ms or even 1ms, it is never 32ms. The test may need to wait longer but changing this value makes no sense.
>
> I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is being used as a max amount of elapsed time, not as an "accuracy" value. The comment on the WIN32 part just adds to the confusion. The "max elapsed time" has to be 16 ms because that is the clock is only accurate to 16ms, so even 1ms of elapsed times will show up as 16ms. The comment "16ms is longest clock update interval" should read "shortest", not "longest". 
> 
> EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed.

Thank you, Chris. My intention was to fix this intermittent failure and achieve better stability. My preference would be to get rid of these troublesome and useless checks instead of fixing confusing constant names and comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2535742944

From cjplummer at openjdk.org  Mon Nov 17 23:17:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 17 Nov 2025 23:17:05 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <LWeS1Ytb2W0yzGvFg3t78fsUTQTxtQzztNREXcSDuq0=.c2160e08-635a-4b48-a0ef-90a7e469dadc@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28362#pullrequestreview-3474885533

From cjplummer at openjdk.org  Mon Nov 17 23:19:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 17 Nov 2025 23:19:06 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <4BLSKl8w2Lhm2HDKDQ6jwVRsWQMssF_tUak9wNk5mkg=.36bcf655-a812-4b2b-86b7-1f02251740a9@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <4dipoan9jnaJpGdBc2b4tpnEDvxsIOSjSPrvIMwnka8=.1ad85705-c8d1-46a2-b364-2a5880386845@github.com>
 <4BLSKl8w2Lhm2HDKDQ6jwVRsWQMssF_tUak9wNk5mkg=.36bcf655-a812-4b2b-86b7-1f02251740a9@github.com>
Message-ID: <Eecvl4S_IsCMFB2eVo_MOeC3whcf18oYRLVCIQaxKhw=.786e424c-ce01-47c5-b82e-14260e199222@github.com>

On Sat, 15 Nov 2025 01:31:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:
>> 
>>> 38:  * @requires vm.hasSA
>>> 39:  * @requires os.family == "linux"
>>> 40:  * @requires os.arch == "amd64"
>> 
>> Can't we run the test on AArch64 now?
>
> I think this PR works on Linux AArch64, but I'm not sure because previous change (#27885) worked on some Linux AArch64, but there are some platforms whch did not work. Thus I think it is better to keep this test for Linux AMD64 only.
> 
> I couldn't reproduce the problem on Fedora Rawhide on Raspberry Pi 4, but there might be some issue because SA does not have DWARF parser for AArch 64 - it means the native we cannot find sender frame which depends on DWARF, does not use FP as frame pointer.

I enabled this test for linux-aarch64 and it seems to pass our testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28284#discussion_r2535790504

From ysuenaga at openjdk.org  Tue Nov 18 00:15:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 18 Nov 2025 00:15:06 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <Eecvl4S_IsCMFB2eVo_MOeC3whcf18oYRLVCIQaxKhw=.786e424c-ce01-47c5-b82e-14260e199222@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <4dipoan9jnaJpGdBc2b4tpnEDvxsIOSjSPrvIMwnka8=.1ad85705-c8d1-46a2-b364-2a5880386845@github.com>
 <4BLSKl8w2Lhm2HDKDQ6jwVRsWQMssF_tUak9wNk5mkg=.36bcf655-a812-4b2b-86b7-1f02251740a9@github.com>
 <Eecvl4S_IsCMFB2eVo_MOeC3whcf18oYRLVCIQaxKhw=.786e424c-ce01-47c5-b82e-14260e199222@github.com>
Message-ID: <oU6skpk8hoa8bT8Vnbrq9UcLCC-yO3N0kvc8UhEmx3k=.8525efc5-cabb-4f7a-b058-d46881f109f8@github.com>

On Mon, 17 Nov 2025 23:16:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I think this PR works on Linux AArch64, but I'm not sure because previous change (#27885) worked on some Linux AArch64, but there are some platforms whch did not work. Thus I think it is better to keep this test for Linux AMD64 only.
>> 
>> I couldn't reproduce the problem on Fedora Rawhide on Raspberry Pi 4, but there might be some issue because SA does not have DWARF parser for AArch 64 - it means the native we cannot find sender frame which depends on DWARF, does not use FP as frame pointer.
>
> I enabled this test for linux-aarch64 and it seems to pass our testing.

I saw the problem on `VMError::report_and_die` because its frame could not be unwinded without DWARF.

I have not seen the problem in other place, but I'm concerned the test fails on some Linux AArch64 platforms. Thus I think it is better to wait enabling  the test until SA supports DWARF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28284#discussion_r2535887854

From sspitsyn at openjdk.org  Tue Nov 18 00:54:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 18 Nov 2025 00:54:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
Message-ID: <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>

On Mon, 17 Nov 2025 13:50:30 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Addressed reviewer's comments.

src/hotspot/share/runtime/objectMonitor.cpp line 1950:

> 1948:         // as having "-locked" the monitor, but the OS and java.lang.Thread
> 1949:         // states will still report that the thread is blocked trying to
> 1950:         // acquire it.

Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). Dan, can you comment on this, please?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 52:

> 50:  * @compile SuspendWithObjectMonitorWait.java
> 51:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 3
> 52:  */

Q: I'm not that happy with adding this complexity into one single test. Would it make sense to split `doWork1`, `doWork2` and `doWork3` tests into independent test sharing some parts, e.g. .cpp file, `SuspendWithObjectMonitorWaitWorker` class etc.? Then the only duplication will be the `main()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535945583
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535957986

From sspitsyn at openjdk.org  Tue Nov 18 03:02:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 18 Nov 2025 03:02:24 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <bwVEgFzsixp0pyRMj-IhDCJvuXyNBvOXYsP0JvUnxJg=.6576a827-1e11-4533-8b6f-91340ae054e6@github.com>

On Mon, 10 Nov 2025 03:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 564:

> 562:      * to keep the node around. It's possible for it to be 0 yet we still need to
> 563:      * keep the node around. Also, it's possbile for it to be non-zero yet we
> 564:      * don't need to keep the node around. More details int he comments below.

Nit: Typo: s/int he/in the/

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1399:

> 1397:     if (node == NULL) {
> 1398:         node = findThread(&otherThreads, thread);
> 1399:     }

Q: Could you explain a little bit why this change is needed? Do we need an update of the comment above?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2536075055
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2536120552

From dholmes at openjdk.org  Tue Nov 18 04:16:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 04:16:23 GMT
Subject: RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails:
 ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) <
 (EXPECTED_ACCURACY * 1000000) [v2]
In-Reply-To: <fcRFPMd7RyZ89ChV1u50kyC1Cv5OkMPVsqVcE1RR_tQ=.c9f455ea-abf0-4ed6-b41a-de62c26723ed@github.com>
References: <jllwQh6NKz8C_JrXGl3xMiTmVU-Ql7MTuVjWYgsdJb0=.4f170fcc-eae7-4d1d-b558-fa0f4c527ba6@github.com>
 <05mxQE7Br_qOo9qhqPc5cx6aGbUq6v7hwm4iuvFGsCk=.c9e384cf-1e00-4976-baa5-f489424f4391@github.com>
 <r0E4RZF2U0Yl0Uxb_LB-zXOl4B5yYfehP_B4AB6GMFI=.59bfd15a-8094-4c83-89d8-fcdf4263f976@github.com>
 <OXAlz17gX2d3E6i2LaBiht7LQwlSj-Lq-2Pn4y0z4jw=.2fba66d0-c8a3-4f75-8f27-58b5bfa87533@github.com>
 <cnSL0lyY9zRoMcw10nBuVrBHUkVNkMxsrFEXoF0Q6kg=.b4ecf7f8-b697-49f1-b9ba-4458d1311d2c@github.com>
 <6OyfaZdrxTVlW9fdpnuttddsAMPIRHXCE1oAPzCvj7A=.d92c4650-ce57-4ee6-b752-720ba524028b@github.com>
 <fcRFPMd7RyZ89ChV1u50kyC1Cv5OkMPVsqVcE1RR_tQ=.c9f455ea-abf0-4ed6-b41a-de62c26723ed@github.com>
Message-ID: <cLzFV_zkpinGKcM3KHmT_OVz3BP0ttbm6pjmbx8dZ9I=.b2c54a8a-02f9-4f29-af11-eb00366ce06c@github.com>

On Mon, 17 Nov 2025 22:48:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is being used as a max amount of elapsed time, not as an "accuracy" value. The comment on the WIN32 part just adds to the confusion. The "max elapsed time" has to be 16 ms because that is the clock is only accurate to 16ms, so even 1ms of elapsed times will show up as 16ms. The comment "16ms is longest clock update interval" should read "shortest", not "longest". 
>> 
>> EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed.
>
> Thank you, Chris. My intention was to fix this intermittent failure and achieve better stability. My preference would be to get rid of these troublesome and useless checks instead of fixing confusing constant names and comments.

> The comment "16ms is longest clock update interval" should read "shortest", not "longest".

No it is the longest interval between clock updates (actually 15.259) based on the old PIT timer (1/65536). Modern hardware will have 10ms or even 1ms.

The code expects to see at most one timer-tick of elapsed time, hence the name and the value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2536241336

From cjplummer at openjdk.org  Tue Nov 18 04:48:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Nov 2025 04:48:14 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <VV2VuF0G_nFeebRphAK_StUNsyrg-R_qAcrc0Z2qIcM=.25cb2382-a1f7-45a5-98e9-610705a12ebd@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

On macosx I'm seeing the following when running ClhsdbPStack.java:
``` Opening core file, please wait...
hsdb> hsdb> + verbose true
hsdb> + pstack -v
Deadlock Detection:

No deadlocks found.

Not available for Mac OS X processes
hsdb> + quit

The "Not available for Mac OS X processes" message is expected when running on a macosx process, but in this case the test is running the core version of the test, so SA is acting on a core file. The test goes on to fail because there are no threads in the output.

The message is generated by PStack.java whenever the thread list is null and it is running on OSX. In that case it assumes the reason the thread list is null is because it is running on a macosx process. It's not clear to me why the thread list is null. I don't see any changes that look like they could cause that.

This happens with both x64 and aarch64, although you need to remove the test from the problem list for macosx-aarch64 to get it to reproduce. macosx-x64 is not problem listed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3545013052

From cjplummer at openjdk.org  Tue Nov 18 05:02:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Nov 2025 05:02:06 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes
In-Reply-To: <bwVEgFzsixp0pyRMj-IhDCJvuXyNBvOXYsP0JvUnxJg=.6576a827-1e11-4533-8b6f-91340ae054e6@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <bwVEgFzsixp0pyRMj-IhDCJvuXyNBvOXYsP0JvUnxJg=.6576a827-1e11-4533-8b6f-91340ae054e6@github.com>
Message-ID: <7gBK0x7oqxFNv50kwhyx9kbGZQD6hMxsawxRJY7-h0A=.8ff3fe4c-ebc4-49be-b2dc-3c3ea63bd027@github.com>

On Tue, 18 Nov 2025 02:45:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1399:
> 
>> 1397:     if (node == NULL) {
>> 1398:         node = findThread(&otherThreads, thread);
>> 1399:     }
> 
> Q: Could you explain a little bit why this change is needed? Do we need an update of the comment above?

You need to call findRunningThread() to get the ThreadNode created if there isn't already one. findThread() does not create the ThreadNode like findRunningThread() does, so after my changes to free up ThreadNodes, findThread() was returning NULL, which causes a lot of problems here.

You then need to add the findThread(&otherThreads, thread) call because this is normally done by findThread() but is purposefully note done by findRunningThread(). otherThreads hold threads that have been created but not yet started. It's kind of rare that threads every end up on the list. It means the debugger somehow got hold of a ThreadReferences (such as through a local var) and then called a ThreadReference API with it. The usual way it works is when an event finally comes in on the thread, that is when it gets moved from otherThreads to runningThreads or runningVThreads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2536308645

From ysuenaga at openjdk.org  Tue Nov 18 06:43:08 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 18 Nov 2025 06:43:08 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <VV2VuF0G_nFeebRphAK_StUNsyrg-R_qAcrc0Z2qIcM=.25cb2382-a1f7-45a5-98e9-610705a12ebd@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <VV2VuF0G_nFeebRphAK_StUNsyrg-R_qAcrc0Z2qIcM=.25cb2382-a1f7-45a5-98e9-610705a12ebd@github.com>
Message-ID: <RcFNfVXFoORVnkUVYW2BWYNgOB_E-mErUIWRPWtHjIg=.a44d8f3c-430d-4a73-b79d-a99853937543@github.com>

On Tue, 18 Nov 2025 04:45:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The message is generated by PStack.java whenever the thread list is null and it is running on OSX.

Maybe it is a side effect of deleting `initJFrameCache()` from PStack.java.
I do not have Mac, so I cannot verify the following...

`BsdDebuggerLocal::threadList` would be filled in `getJavaThreadsInfo()`, and it is eventually called through a chain of calls starting from `BsdThread::getContext()`. It is eventually called by `getCurrentFrameGuess()` from `PStack::initJFrameCache()`.

I think it is better to separate BsdDebuggerLocal::getJavaThreadsInfo() - filling threadList can move to getThreadList() because it is not needed in getJavaThreadsInfo().

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3545625295

From dholmes at openjdk.org  Tue Nov 18 07:46:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 07:46:32 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <h2n5k_4Opz8_zghqW5MFHvVPkSV1Gi-NJNAdfXqrjZg=.668ed02b-500d-40f1-89f1-b7e4ecabf6d3@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

Having the test actually do something that looks like it triggers GC certainly makes sense. I'm unclear what a GC's "slower update rate" means.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28362#pullrequestreview-3475947140

From jnorlinder at openjdk.org  Tue Nov 18 08:34:09 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 18 Nov 2025 08:34:09 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <V6FwBFvDJVO3bgd7K1BU7pLBULvrrChQTXUBEMxUTbg=.36ebaf51-0344-4ac1-a57f-7aa6df677d7a@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

Thanks David and Chris for the reviews!

> I'm unclear what a GC's "slower update rate" means.

It is the OS's scheduler that needs to schedule its task to update the thread CPU time.

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

PR Comment: https://git.openjdk.org/jdk/pull/28362#issuecomment-3546173687

From duke at openjdk.org  Tue Nov 18 08:34:10 2025
From: duke at openjdk.org (duke)
Date: Tue, 18 Nov 2025 08:34:10 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <donr8rJr0ivlymBgsg0VzjdTzVEbZfzMvnlP1BgPLnE=.42d79a73-70b9-45c1-8b13-a5ad220bc059@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28362#issuecomment-3546176137

From alanb at openjdk.org  Tue Nov 18 08:50:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 08:50:04 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <xUMy7hOoQgcQcCw5Ld8uHdcMhr_qwJQUJuzOpbQ1jXw=.33b5b49e-3556-4c4c-94d8-b03054856fdf@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

test/jdk/java/lang/management/MemoryMXBean/TestGetTotalGcCpuTime.java line 106:

> 104:             objs.add(new Object());
> 105:           }
> 106:           System.gc();

No concern that escape analysis will eliminate the allocations here?

Minor nit, should use 4-space indentation here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28362#discussion_r2536907844

From jnorlinder at openjdk.org  Tue Nov 18 09:00:04 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 18 Nov 2025 09:00:04 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v2]
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <rMH0qsGSI5RaA4sTJtmhycS4QchmxnPaMNESWfnC4kQ=.746465d0-8724-4803-ad29-c84c30d992cf@github.com>

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Prevent escaping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28362/files
  - new: https://git.openjdk.org/jdk/pull/28362/files/f6d3a127..dff1c323

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

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

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

From jnorlinder at openjdk.org  Tue Nov 18 09:06:24 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 18 Nov 2025 09:06:24 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v3]
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Prevent escaping: no shadowing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28362/files
  - new: https://git.openjdk.org/jdk/pull/28362/files/dff1c323..f99ad286

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

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

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

From kevinw at openjdk.org  Tue Nov 18 09:06:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Nov 2025 09:06:25 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v2]
In-Reply-To: <rMH0qsGSI5RaA4sTJtmhycS4QchmxnPaMNESWfnC4kQ=.746465d0-8724-4803-ad29-c84c30d992cf@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
 <rMH0qsGSI5RaA4sTJtmhycS4QchmxnPaMNESWfnC4kQ=.746465d0-8724-4803-ad29-c84c30d992cf@github.com>
Message-ID: <dNq9olsFwb6JFI5z6lvw0gilVIpxC873ng2rRfyEftE=.62b4c82e-ee15-4897-822c-e2d65d409376@github.com>

On Tue, 18 Nov 2025 09:00:04 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
>> 
>> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent escaping

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28362#pullrequestreview-3476300135

From kevinw at openjdk.org  Tue Nov 18 09:06:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Nov 2025 09:06:26 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v3]
In-Reply-To: <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
 <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
Message-ID: <LOD-LgEa6eBG4lzp0L2yTHu4lglS8jteqjuSdqZQaek=.628a7f6c-5abd-4a58-a95b-8820f032729f@github.com>

On Tue, 18 Nov 2025 09:01:53 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
>> 
>> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent escaping: no shadowing

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28362#pullrequestreview-3476311218

From jnorlinder at openjdk.org  Tue Nov 18 09:06:29 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 18 Nov 2025 09:06:29 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v3]
In-Reply-To: <xUMy7hOoQgcQcCw5Ld8uHdcMhr_qwJQUJuzOpbQ1jXw=.33b5b49e-3556-4c4c-94d8-b03054856fdf@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
 <xUMy7hOoQgcQcCw5Ld8uHdcMhr_qwJQUJuzOpbQ1jXw=.33b5b49e-3556-4c4c-94d8-b03054856fdf@github.com>
Message-ID: <ijGuUoxK0ZFrwUnxnJGPpA94f-lGUpKIpFjpfWst6n4=.d7092753-ae77-40b3-b7a6-84dff61af99b@github.com>

On Tue, 18 Nov 2025 08:47:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prevent escaping: no shadowing
>
> test/jdk/java/lang/management/MemoryMXBean/TestGetTotalGcCpuTime.java line 106:
> 
>> 104:             objs.add(new Object());
>> 105:           }
>> 106:           System.gc();
> 
> No concern that escape analysis will eliminate the allocations here?
> 
> Minor nit, should use 4-space indentation here.

Thanks Alan. I believe this didn't happen with the current implementation. That being said, I reached out to @robcasloz to get his opinion if there are any risks.

FWIW; I added objs as a private static field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28362#discussion_r2536969057

From alanb at openjdk.org  Tue Nov 18 09:14:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 09:14:49 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v3]
In-Reply-To: <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
 <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
Message-ID: <_AJyLNZXwD5jk4Mo3u3Qa3UO3miYJueM9PpjcPBtpm4=.9cd8bd86-0dd5-473b-a106-daad14ad2611@github.com>

On Tue, 18 Nov 2025 09:06:24 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
>> 
>> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent escaping: no shadowing

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28362#pullrequestreview-3476366794

From ayang at openjdk.org  Tue Nov 18 09:40:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Nov 2025 09:40:37 GMT
Subject: RFR: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4]
In-Reply-To: <uNhXBj43RFhFtF_e4hHstfJe-Y0HY4IxdPhBPUwo3RU=.f8d0a602-2be9-404f-a4e8-4db43ac8af04@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
 <uNhXBj43RFhFtF_e4hHstfJe-Y0HY4IxdPhBPUwo3RU=.f8d0a602-2be9-404f-a4e8-4db43ac8af04@github.com>
Message-ID: <D0RhZiAwCHGXkyjZK_R6N9z-Ks2z7N1OIh-eQ9zsqto=.59972279-a1f3-44ab-b2b0-99c5d363b5a7@github.com>

On Mon, 17 Nov 2025 09:35:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing obsoleted code for unsupported arch.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - patch

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3546476614

From ayang at openjdk.org  Tue Nov 18 09:40:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Nov 2025 09:40:38 GMT
Subject: Integrated: 8371643: Remove
 ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch
In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com>
Message-ID: <aD4YfROGAm9HwUG3O3-U2EOXSXgQgihbYi1L-jK2dYc=.256dfc28-06c0-45b5-9e65-0672396dcaec@github.com>

On Tue, 11 Nov 2025 15:42:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing obsoleted code for unsupported arch.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 50a30497
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50a30497370799e8f377a11914562a15b0a48fbb
Stats:     69 lines in 7 files changed: 0 ins; 66 del; 3 mod

8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch

Reviewed-by: mdoerr, kvn, tschatzl

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

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

From kevinw at openjdk.org  Tue Nov 18 09:42:22 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 18 Nov 2025 09:42:22 GMT
Subject: RFR: 8372008: TestGetTotalGcCpuTime test failures on Windows (Some
 GC CPU time must have been reported) [v3]
In-Reply-To: <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
 <UHox8R0yAnEX4jcePm-317xHx8jFwGgoAMadRNtqEQ4=.69ae8ac0-6107-4c7b-81fb-161b8133dd5b@github.com>
Message-ID: <p8dr1EXCJjlDgBvus-vvgPOgQXtVVf4hwQpoHl8sSDw=.3c6a0560-5660-4666-8d4e-f41499630919@github.com>

On Tue, 18 Nov 2025 09:06:24 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
>> 
>> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent escaping: no shadowing

Looks good. Runs many times for me, I let it go for 15 iterations with jtreg.
Then I let it run for 4 iterations with -Xcomp and over 20 with -XX:-TieredCompilation

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

PR Comment: https://git.openjdk.org/jdk/pull/28362#issuecomment-3546490368

From mdoerr at openjdk.org  Tue Nov 18 10:09:11 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Nov 2025 10:09:11 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
Message-ID: <IJ1-Avg8M0RlJC91IhQnjy0gjROcv073EYeeHaOnamI=.c7ac055d-6fb0-4321-bff1-4787ca273983@github.com>

On Thu, 13 Nov 2025 23:49:28 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an assertion to detect out of bounds access in post-call NOP checks

Our tests haven't revealed any new issues related to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3546631812

From jnorlinder at openjdk.org  Tue Nov 18 10:12:00 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Tue, 18 Nov 2025 10:12:00 GMT
Subject: Integrated: 8372008: TestGetTotalGcCpuTime test failures on Windows
 (Some GC CPU time must have been reported)
In-Reply-To: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
References: <6SMM4ifRY34vKE5h6ORjtewOgVLkEpttbk2N8Mlq6Yo=.dc7fbfb0-7d23-4035-9af4-03f8ed6a7a03@github.com>
Message-ID: <Az980qCpXK-ELNSHfDjnQyOSir4hJc4DR9IPDo3jyJ4=.867a4528-4548-4200-a3f6-cf048495dc53@github.com>

On Mon, 17 Nov 2025 20:32:52 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Current trivial test for `TestGetTotalGcCpuTime` fails as some OSs may have a slower update rate for the underlying CPU time thread counters than the code anticipated, causing the test to fail which assumes that some work have been performed and the count should be non-zero.
> 
> Solution: All GCs we are testing are tracing GCs. Therefore, add some marking job to inflate the GC CPU time such that we can guarantee to observe a non-zero value.

This pull request has now been integrated.

Changeset: 28d94d6a
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28d94d6ab4994b844af98c5c227b40b5fb8a72e5
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8372008: TestGetTotalGcCpuTime test failures on Windows (Some GC CPU time must have been reported)

Reviewed-by: kevinw, alanb, cjplummer, dholmes

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

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

From aartemov at openjdk.org  Tue Nov 18 10:14:19 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 10:14:19 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v10]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <WwygcxPd-fZ1BtaOiADco08l5JBAF-daSgXyYUahYYQ=.3684be06-e786-4672-96e8-207817da1025@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/28725284..a429cb26

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

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

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

From aartemov at openjdk.org  Tue Nov 18 10:14:22 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 10:14:22 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
 <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>
Message-ID: <KOYbj_QCIBlnrg300pGhuvSaSEc-7RQzKoc5LH2q7_w=.66159ec7-3f04-4963-baf3-35647fd677d0@github.com>

On Mon, 17 Nov 2025 19:23:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewer's comments.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 140:
> 
>> 138: // launch resumer       enter threadLock
>> 139: // <launch returns>     while !READY_TO_NOTIFY  resumer running
>> 140: // :                    threadLock.wait(1)      wait for notify
> 
> The wait(1) call is in the while-loop. Please insert two spaces before the `threadlock.wait(1)` call.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 235:
> 
>> 233:                 } catch (NumberFormatException nfe) {
>> 234:                     System.err.println("'" + args[argIndex] +
>> 235:                             "': invalid test_case value.");
> 
> The leading double quote should be lined up with the one on the previous line.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 251:
> 
>> 249:                 } catch (NumberFormatException nfe) {
>> 250:                     System.err.println("'" + args[argIndex] +
>> 251:                             "': invalid time_max value.");
> 
> The leading double quote should be lined up with the one on the previous line.

Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288143
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288285
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288511

From aartemov at openjdk.org  Tue Nov 18 13:03:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 13:03:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v11]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <5fIR4uxrdE0GVVCOwUYVlz5OyBpiio0fe32-BKOmO_I=.2b262076-a045-4a51-929f-2fb6e5201880@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Refactored the big test into 3 smaller tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/a429cb26..3da08471

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

  Stats: 1696 lines in 7 files changed: 921 ins; 773 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Tue Nov 18 13:03:37 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 13:03:37 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
 <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>
Message-ID: <ZBouMKx3jvovFMLoB93H-GZ7fAt1Q1dbb-rbEQuMyog=.91d1a23f-f6ec-4bfb-a646-61095840c4a4@github.com>

On Tue, 18 Nov 2025 00:48:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewer's comments.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 52:
> 
>> 50:  * @compile SuspendWithObjectMonitorWait.java
>> 51:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 3
>> 52:  */
> 
> Q: I'm not that happy with adding this complexity into one single test. It is usually not easy to deal with such big and multi-mode tests. Would it make sense to split `doWork1`, `doWork2` and `doWork3` tests into independent tests `SuspendWithObjectMonitorWait{1|2|3}.java` sharing some parts, e.g. .cpp file, `SuspendWithObjectMonitorWaitWorker.java` class etc.? Then the only duplication will be the `main()` method.

Actually I agree, it has become way too long. I refactored it into 3 smaller tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2538107049

From erikj at openjdk.org  Tue Nov 18 14:08:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Nov 2025 14:08:15 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <JjPQmA7hi_vP_slIWRgagQ-WA4jbLSH0ESZaaQWN49Q=.330e3fea-3cd1-4c96-ba04-d192218c9ae7@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <U5v9_rGEaHgAKSvDyOChfJ4Wqr1FbHRfAruQsdPEwyQ=.f0c516d2-ba7f-4415-bb7e-0f5cd6e52f79@github.com>
 <JjPQmA7hi_vP_slIWRgagQ-WA4jbLSH0ESZaaQWN49Q=.330e3fea-3cd1-4c96-ba04-d192218c9ae7@github.com>
Message-ID: <Qt2AWyurXd8FZO8leTwNa9xpmorz2f9sKZL4cz1sqew=.a950d36d-9c99-4ff1-bbb2-ec867722381f@github.com>

On Tue, 18 Nov 2025 08:55:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Is there is a particular reason to not apply this on x64 as well?
> 
> On macOS x86_64 I saw in our CI those tests failing when enabling the dead_strip feature serviceability/sa/ClhsdbCDSCore.java serviceability/sa/ClhsdbFindPC.jav serviceability/sa/ClhsdbPstack.java

That information should at least be stated in the bug for future reference on why this decision was made. 
 
> For macOS aarch64, the tests in our CI were fine but I see some failures in the GHA in the serviceability area.
> 
> ```
> finding class loader instances ..java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> ```

Adding serviceability label as this is affecting their tests. I have a vague memory of some seemingly dead code being necessary for certain sa functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547789577

From duke at openjdk.org  Tue Nov 18 14:18:11 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 18 Nov 2025 14:18:11 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <IJ1-Avg8M0RlJC91IhQnjy0gjROcv073EYeeHaOnamI=.c7ac055d-6fb0-4321-bff1-4787ca273983@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
 <IJ1-Avg8M0RlJC91IhQnjy0gjROcv073EYeeHaOnamI=.c7ac055d-6fb0-4321-bff1-4787ca273983@github.com>
Message-ID: <kppTc2rExxZ9ARDm6h7-JldccWa0iNK27oZiaZG5aVI=.41121ea0-d122-469e-9489-120fc3478350@github.com>

On Tue, 18 Nov 2025 10:05:48 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an assertion to detect out of bounds access in post-call NOP checks
>
> Our tests haven't revealed any new issues related to this PR.

Thank you, @TheRealMDoerr,

> I think assertions would be sufficient in C1 instead of guarantee.

Sure, I will change these to assertions.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3547827280

From aartemov at openjdk.org  Tue Nov 18 14:35:16 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 14:35:16 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Added bool arg to notify_contended_enter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/3da08471..8c82d39c

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

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

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

From mbaesken at openjdk.org  Tue Nov 18 14:38:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 14:38:17 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <Qt2AWyurXd8FZO8leTwNa9xpmorz2f9sKZL4cz1sqew=.a950d36d-9c99-4ff1-bbb2-ec867722381f@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <U5v9_rGEaHgAKSvDyOChfJ4Wqr1FbHRfAruQsdPEwyQ=.f0c516d2-ba7f-4415-bb7e-0f5cd6e52f79@github.com>
 <JjPQmA7hi_vP_slIWRgagQ-WA4jbLSH0ESZaaQWN49Q=.330e3fea-3cd1-4c96-ba04-d192218c9ae7@github.com>
 <Qt2AWyurXd8FZO8leTwNa9xpmorz2f9sKZL4cz1sqew=.a950d36d-9c99-4ff1-bbb2-ec867722381f@github.com>
Message-ID: <B1IuGj1WlGEz8eGCTYVR_i4fh3CIp2zDkFmLgtdzdng=.82b739dc-a60b-4815-8810-a520b6309ff6@github.com>

On Tue, 18 Nov 2025 14:05:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I have a vague memory of some seemingly dead code being necessary for certain sa functionality.

Yeah I remember too,
We noticed similar issues when  using  the lto configure flag on libjvm  with gcc  (other platform and switch but similar issues).

Is there a way to attribute such 'dead' functions with  e.g. an attribute to pragma or something similar to avoid removal of those ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547901166

From mbaesken at openjdk.org  Tue Nov 18 14:42:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 14:42:19 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <OjM3ybLdOEVaS_Ub3Wt1pB9TLh937tIZhUbcZVUTi1M=.9e3ec749-8782-4da9-a01d-5e2a889ac647@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

The was a bit of discussion on serviceability-dev  some years ago about that lto on libjvm issue and the serviceability errors and Magnus commented 

'We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. There is still a "link-time-opt" JVM feature present; afaik it still works and adds the -flto flag. The main drawback of this is the *extremely* long link times of libjvm.so.
I don't think servicability was ever supported for that platform, so I'm not surprised this does not work. '

Probably the dead-strip feature runs into similar issues.

I commented back then 
'The  serviceability   tests like  serviceability/sa   seems to rely   heavily  on the "normal"   structure  of   libjvm.so   (from what I   understand  e.g. in  LinuxVtblAccess  it is attempted to access  internal symbols  like  _ZTV ).'

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547920976

From aartemov at openjdk.org  Tue Nov 18 14:45:45 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 14:45:45 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <aGPfZCwLmf2TONOqGFVUFzDKAVaefS2A8Xwcdun1Qps=.bc9443ab-46a8-4855-97a9-e313d3f32c07@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

@sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:

Master branch, events posted: wait -> waited -> contended enter -> contended entered
This PR: events posted: wait -> contended enter -> contended entered -> waited

I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of `wait` or not?

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3547934122

From coleenp at openjdk.org  Tue Nov 18 15:43:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Nov 2025 15:43:00 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
Message-ID: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>

ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
Tested with tier1-4.  5-7 in progress.

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

Commit messages:
 - Fix C2 to test for array first.
 - Move AccessFlags to InstanceKlass - array classes don't set access flags so don't look for them there.

Changes: https://git.openjdk.org/jdk/pull/28371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372098
  Stats: 155 lines in 29 files changed: 62 ins; 54 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/28371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28371/head:pull/28371

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

From liach at openjdk.org  Tue Nov 18 15:43:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 15:43:03 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <QRsphYOUpIHhgSouprdE7ruop9fwI_nEmuMsKyRoXY4=.00784872-cda1-4d04-9efe-de415fa42b13@github.com>

On Tue, 18 Nov 2025 13:27:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

src/hotspot/share/oops/constantPool.cpp line 1228:

> 1226: 
> 1227:       // Check constant pool method consistency
> 1228:       InstanceKlass* callee = InstanceKlass::cast(k);

I know a MethodRef can be `[I`, `clone`, `()Ljava/lang/Object;` for `intArray.clone()` Java calls translated by javac. I wonder if this new code would break for such an array callee class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2538494116

From coleenp at openjdk.org  Tue Nov 18 15:58:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Nov 2025 15:58:15 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <QRsphYOUpIHhgSouprdE7ruop9fwI_nEmuMsKyRoXY4=.00784872-cda1-4d04-9efe-de415fa42b13@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <QRsphYOUpIHhgSouprdE7ruop9fwI_nEmuMsKyRoXY4=.00784872-cda1-4d04-9efe-de415fa42b13@github.com>
Message-ID: <SZOao5PMYJx-rsF6v9IgXPXYcBFm0EJ6MZtb78oSqfU=.1b47d0b0-ff7a-45af-9a4c-9bdebc1d070c@github.com>

On Tue, 18 Nov 2025 14:48:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> src/hotspot/share/oops/constantPool.cpp line 1228:
> 
>> 1226: 
>> 1227:       // Check constant pool method consistency
>> 1228:       InstanceKlass* callee = InstanceKlass::cast(k);
> 
> I know a MethodRef can be `[I`, `clone`, `()Ljava/lang/Object;` for `intArray.clone()` Java calls translated by javac. I wonder if this new code would break for such an array callee class.

At one point, I removed is_interface() from class Klass, but then restored it because dependencies uses this a lot and has many Klass parameter types, instead of InstanceKlass.  I'll revert this change, but I'm curious why none of the tests failed with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2538747727

From aph at openjdk.org  Tue Nov 18 18:00:10 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 18 Nov 2025 18:00:10 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <yAUizbzTa4C7y3RkiceDWUyctBcNEE79Skz64ZAKkvc=.b23dcb06-66c1-4b48-aa63-b7507aca06c8@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

Surely you're going to use features that are provided for debugging. They aren't called from anywhere, but they are used when debugging HotSpot. And you still need them even if you're not using a debug build.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3548890774

From duke at openjdk.org  Tue Nov 18 18:21:35 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 18 Nov 2025 18:21:35 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <w8cyNGc96lMStaA508iiRtQBYDBu0QFmGfOwN-b9IBI=.9c1084c2-cf8d-40d8-a2f3-5999597c0cc1@github.com>

On Tue, 18 Nov 2025 13:27:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

src/hotspot/share/classfile/classFileParser.cpp line 815:

> 813:         interface_index, CHECK);
> 814:       if (cp->tag_at(interface_index).is_klass()) {
> 815:         interf = InstanceKlass::cast(cp->resolved_klass_at(interface_index));

Note?that a?resolved `CONSTANT_Class` can refer to an array?type, so?this?cast is?incorrect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2539226107

From coleenp at openjdk.org  Tue Nov 18 18:55:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Nov 2025 18:55:03 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <w8cyNGc96lMStaA508iiRtQBYDBu0QFmGfOwN-b9IBI=.9c1084c2-cf8d-40d8-a2f3-5999597c0cc1@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <w8cyNGc96lMStaA508iiRtQBYDBu0QFmGfOwN-b9IBI=.9c1084c2-cf8d-40d8-a2f3-5999597c0cc1@github.com>
Message-ID: <Two5HnyOCpyEn03NktpDEP5D7vGcNDOyP2Kkac7M0Wg=.72afcdb7-6656-4f05-a585-c2e775fce653@github.com>

On Tue, 18 Nov 2025 18:15:40 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> src/hotspot/share/classfile/classFileParser.cpp line 815:
> 
>> 813:         interface_index, CHECK);
>> 814:       if (cp->tag_at(interface_index).is_klass()) {
>> 815:         interf = InstanceKlass::cast(cp->resolved_klass_at(interface_index));
> 
> Note?that a?resolved `CONSTANT_Class` can refer to an array?type, so?this?cast is?incorrect.

There are a bunch of tests that we don't have. This would be an error since Interfaces are never arrays, but that's checked later.  I'll revert some of these casts (as well as try to write a test for this).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2539318553

From liach at openjdk.org  Tue Nov 18 20:05:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 20:05:14 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass
In-Reply-To: <Two5HnyOCpyEn03NktpDEP5D7vGcNDOyP2Kkac7M0Wg=.72afcdb7-6656-4f05-a585-c2e775fce653@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <w8cyNGc96lMStaA508iiRtQBYDBu0QFmGfOwN-b9IBI=.9c1084c2-cf8d-40d8-a2f3-5999597c0cc1@github.com>
 <Two5HnyOCpyEn03NktpDEP5D7vGcNDOyP2Kkac7M0Wg=.72afcdb7-6656-4f05-a585-c2e775fce653@github.com>
Message-ID: <HNpDb_Y0CCXSj9SBUgGQv0juV4SM1L1YduID6rEzlZc=.a7aaea12-3f04-43bb-83ec-7bad14e24217@github.com>

On Tue, 18 Nov 2025 18:50:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 815:
>> 
>>> 813:         interface_index, CHECK);
>>> 814:       if (cp->tag_at(interface_index).is_klass()) {
>>> 815:         interf = InstanceKlass::cast(cp->resolved_klass_at(interface_index));
>> 
>> Note?that a?resolved `CONSTANT_Class` can refer to an array?type, so?this?cast is?incorrect.
>
> There are a bunch of tests that we don't have. This would be an error since Interfaces are never arrays, but that's checked later.  I'll revert some of these casts (as well as try to write a test for this).

I thought the cast at line 839 would have handled this. Turns out it has a `!interf->is_interface()` check before so this cast is problematic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2539538759

From pchilanomate at openjdk.org  Tue Nov 18 21:41:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 18 Nov 2025 21:41:43 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
 <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>
Message-ID: <nLe1FJCTVs3dgEMZ5gg9LOhgwzEYUDZoEP6EN-g5OBY=.e842019d-33a3-41cc-928b-b29354a08b19@github.com>

On Mon, 17 Nov 2025 19:30:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?
>
> Sorry, I wasn't very clear. I'm questioning the need for the 200ms delay since our call
> to `wait4ContendedEnter` will already delay the calling thread. Since @pchilano requested
> the addition of the 200ms delay, he should probably chime in here.

We need it because the `notify()` call already changes the state of the waiter to the BLOCKED state [1] (note that it doesn't unpark it). That means this call to `wait4ContendedEnter` will always return immediately (except for the rare case of the wait timing out before the notify call).

[1] https://github.com/openjdk/jdk/blob/27a38d9093958ae4851bc61b8d3f0d71dc780823/src/hotspot/share/runtime/objectMonitor.cpp#L2077

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2539670920

From cjplummer at openjdk.org  Tue Nov 18 21:47:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Nov 2025 21:47:05 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <iTo_5UzStQe0wf351WxSGPPnatjuYbkp3HUisHjf1fo=.a4713e17-c588-42ba-9fc2-7037391b7462@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

SA is throwing an exception on the following:

`      Klass classLoaderKlass = vm.getSystemDictionary().getClassLoaderKlass();`

This looks to be the first thing it is doing that involves looking up a hotspot symbol. Possibly the issue is with symbols in general being stripped, or maybe just this one was. The fact that only 3 tests failed makes me think it is some very selective dead stripping of symbols that is the problem. Most SA functionality does not use SystemDictionary().getClassLoaderKlass(), so if just this one symbol was missing, that would explain why for the most part SA is working.

On the assumption that it is just this one symbol, Hotspot declares an array of InstanceKlass* for some critical classes:


InstanceKlass* vmClasses::_klasses[static_cast<int>(vmClassID::LIMIT)]
                                                 =  { nullptr /*, nullptr...*/ };


In SA, the failed SystemDictionary.initialize() part of the stacktrace shows an attempt to access this array for the ClassLoader InstanceKlass*

`    classLoaderKlassField = type.getAddressField(VM_CLASS_AT("ClassLoader_klass"));`


  private static String VM_CLASS_AT(String name) {
    return "_klasses[static_cast<int>(" + VM_CLASS_ID(name) + ")]";
  }


And in vmStructs we have:

`     static_field(vmClasses,                   VM_CLASS_AT(ClassLoader_klass),                   InstanceKlass*)                     `

I think this vmStructs static field is getting dead stripped.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549555596

From coleenp at openjdk.org  Tue Nov 18 21:50:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Nov 2025 21:50:35 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v2]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <yPrjJ9zU1XqMvIqftusNDw2xtCiUZ77KLpJoPDKSnOY=.3ecac3e6-c381-4cb2-88b2-68856136e6ba@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Revert two InstanceKlass::cast() calls that might not be InstanceKlass.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/80079012..e8973f59

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

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

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

From coleenp at openjdk.org  Tue Nov 18 21:50:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Nov 2025 21:50:38 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v2]
In-Reply-To: <HNpDb_Y0CCXSj9SBUgGQv0juV4SM1L1YduID6rEzlZc=.a7aaea12-3f04-43bb-83ec-7bad14e24217@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <w8cyNGc96lMStaA508iiRtQBYDBu0QFmGfOwN-b9IBI=.9c1084c2-cf8d-40d8-a2f3-5999597c0cc1@github.com>
 <Two5HnyOCpyEn03NktpDEP5D7vGcNDOyP2Kkac7M0Wg=.72afcdb7-6656-4f05-a585-c2e775fce653@github.com>
 <HNpDb_Y0CCXSj9SBUgGQv0juV4SM1L1YduID6rEzlZc=.a7aaea12-3f04-43bb-83ec-7bad14e24217@github.com>
Message-ID: <zk4R1RQA9rvtBRTelFLmHvyg0UQrETz56TfpteAMLNs=.6dd5ad7b-d21a-4e3a-937f-e81baf1e77d4@github.com>

On Tue, 18 Nov 2025 20:02:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> There are a bunch of tests that we don't have. This would be an error since Interfaces are never arrays, but that's checked later.  I'll revert some of these casts (as well as try to write a test for this).
>
> I thought the cast at line 839 would have handled this. Turns out it has a `!interf->is_interface()` check before so this cast is problematic.

There's a reason this isn't tested.  The constant pool reference for JVM_CONSTANT_Class is tested to be resolved at line 814 and because it's an interface, it's not easy to be resolved by this point (unless it's a duplicate class in which case it will be an InstanceKlass).  The array case goes through the else part of this and throws a ClassFormatError.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2539645039

From cjplummer at openjdk.org  Tue Nov 18 21:51:26 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Nov 2025 21:51:26 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v2]
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <eABh9Vl7Kz1AfvXBt2GSuNdavNd7E-bU8LG0yD59m2o=.bb5441d8-a8bb-4aa7-9c74-c145e57df55e@github.com>

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  comment typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28211/files
  - new: https://git.openjdk.org/jdk/pull/28211/files/717f9d70..49a358c5

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

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

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

From cjplummer at openjdk.org  Tue Nov 18 22:27:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Nov 2025 22:27:03 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <2CNk3Ufuu-ZmSz5qfhB4jKCP4H7VGDP0DqA_xAsEKic=.50f3f7c7-38db-4a94-a607-82837685e5d2@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

Sorry, I think I went somewhat astray in my comments above. I think `classLoaderKlassField` is being initialized. It's value (an address) is then passed to instantiateWrapperFor():

  public static InstanceKlass getClassLoaderKlass() {
    return (InstanceKlass)Metadata.instantiateWrapperFor(classLoaderKlassField.getValue());
  }

instantiateWrapperFor() is failing. If you look at the stack trace (and the accompanying code), it appears that it has failed to lookup the base type, which is Metadata. There probably are no instances of Metadata allocated, just instances of subclasses, so possibly the Metadata vtbl has been dead stripped, and SA needs it. However, I would think this would result in mass failures since we call Metadata.instantiateWrapperFor() all over the place.

If you want to attempt a fix, have hotspot allocate a Metadata instance somewhere and keep a reference to it. That should prevent the Metadata vtbl from being dead stripped.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549682521

From duke at openjdk.org  Tue Nov 18 22:35:38 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 18 Nov 2025 22:35:38 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v3]
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

  Replace `guarantee` with `assert` in the C1 `emit_deopt_handler`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28192/files
  - new: https://git.openjdk.org/jdk/pull/28192/files/20cc58a3..3a014376

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

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

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

From serb at openjdk.org  Tue Nov 18 23:39:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 18 Nov 2025 23:39:32 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <nyDtm2Xmvgx9JjP5M6TKUsIJe_Mw3NW_Kta5zR-576Y=.d65500ff-7823-432f-8460-f09ca5dda703@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

As usual, maybe it is possible to split this patch between hotspot and the libraries?

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549889174

From cjplummer at openjdk.org  Wed Nov 19 02:31:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 02:31:51 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

I reproduced the SA issues locally. Not surprisingly almost every SA test failed (I'm not sure why only 3 were listed above). They seemed to all fail trying to get a vtable for a hotspot type. The tests that didn't failed were doing mundane things like testing attaching, hotspot flags, and clhsdb history, but not doing anything with hotspot objects, or at least not with hotspot metadata.

I was able to confirm the problem is with the Metadata vtable missing. I fixed it by allocating a Metadata instance and assigning it to a global. However, in order to get this to compile I had make Metadata no longer be abstract. All tests passed after I did this. I'm not sure how viable a solution this is. The hotspot team will probably object to the Metadata changes. Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3550388831

From ysuenaga at openjdk.org  Wed Nov 19 03:05:17 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 19 Nov 2025 03:05:17 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <VV2VuF0G_nFeebRphAK_StUNsyrg-R_qAcrc0Z2qIcM=.25cb2382-a1f7-45a5-98e9-610705a12ebd@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <VV2VuF0G_nFeebRphAK_StUNsyrg-R_qAcrc0Z2qIcM=.25cb2382-a1f7-45a5-98e9-610705a12ebd@github.com>
Message-ID: <Yvi6V1Q7J48mJLGqxySOxChyeHhdD9TqAdZng_IgdCA=.dd415d9a-5220-42a4-82f4-ff7a05b83161@github.com>

On Tue, 18 Nov 2025 04:45:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for Linux PPC64 and RISC-V
>
> On macosx I'm seeing the following when running ClhsdbPStack.java:
> ``` Opening core file, please wait...
> hsdb> hsdb> + verbose true
> hsdb> + pstack -v
> Deadlock Detection:
> 
> No deadlocks found.
> 
> Not available for Mac OS X processes
> hsdb> + quit
> 
> The "Not available for Mac OS X processes" message is expected when running on a macosx process, but in this case the test is running the core version of the test, so SA is acting on a core file. The test goes on to fail because there are no threads in the output.
> 
> The message is generated by PStack.java whenever the thread list is null and it is running on OSX. In that case it assumes the reason the thread list is null is because it is running on a macosx process. It's not clear to me why the thread list is null. I don't see any changes that look like they could cause that.
> 
> This happens with both x64 and aarch64, although you need to remove the test from the problem list for macosx-aarch64 to get it to reproduce. macosx-x64 is not problem listed.

@plummercj Can you try this patch on your Mac? You can apply it to this PR branch.


diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
index 10f6881d010..f091b22f9d7 100644
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2025, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,9 @@
 package sun.jvm.hotspot.debugger.bsd;

 import java.util.ArrayList;
+import java.util.Collections;
 import java.util.List;
+import java.util.stream.IntStream;

 import sun.jvm.hotspot.debugger.Address;
 import sun.jvm.hotspot.debugger.DebuggerBase;
@@ -75,10 +77,11 @@ public class BsdDebuggerLocal extends DebuggerBase implements BsdDebugger {
     // CDebugger support
     private BsdCDebugger cdbg;

-    // threadList and loadObjectList are filled by attach0 method
-    private List<ThreadProxy> threadList;
+    // loadObjectList are filled by attach0 method
     private List<LoadObject> loadObjectList;

+    private List<JavaThread> javaThreadList;
+
     // called by native method lookupByAddress0
     private ClosestSymbol createClosestSymbol(String name, long offset) {
        return new ClosestSymbol(name, offset);
@@ -244,7 +247,7 @@ private void findABIVersion() throws DebuggerException {
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(int processID) throws DebuggerException {
         checkAttached();
-        threadList = new ArrayList<>();
+        javaThreadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         class AttachTask implements WorkerThreadTask {
            int pid;
@@ -264,7 +267,7 @@ public void doit(BsdDebuggerLocal debugger) {
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(String execName, String coreName) {
         checkAttached();
-        threadList = new ArrayList<>();
+        javaThreadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         attach0(execName, coreName);
         attached = true;
@@ -278,7 +281,7 @@ public synchronized boolean detach() {
             return false;
         }

-        threadList = null;
+        javaThreadList = null;
         loadObjectList = null;

         if (isCore) {
@@ -492,7 +495,25 @@ public Address newAddress(long value) {
     /** From the BsdCDebugger interface */
     public List<ThreadProxy> getThreadList() {
       requireAttach();
-      return threadList;
+
+      if (javaThreadList == null) {
+        return null;
+      }
+      if (!isCore) {
+        // TODO: thread list is now supported for corefile only.
+        return Collections.emptyList();
+      }
+
+      if (javaThreadList.isEmpty()) {
+        Threads threads = VM.getVM().getThreads();
+        IntStream.range(0, threads.getNumberOfThreads())
+                 .mapToObj(threads::getJavaThreadAt)
+                 .forEach(javaThreadList::add);
+      }
+
+      return javaThreadList.stream()
+                           .map(t -> t.getThreadProxy())
+                           .toList();
     }

     /** From the BsdCDebugger interface */
@@ -561,21 +582,16 @@ public void doit(BsdDebuggerLocal debugger) {
     /** this functions used for core file reading and called from native attach0,
         it returns an array of long integers as
         [thread_id, stack_start, stack_end, thread_id, stack_start, stack_end, ....] for
-        all java threads recorded in Threads. Also adds the ThreadProxy to threadList */
+        all java threads recorded in Threads. */
     public long[] getJavaThreadsInfo() {
         requireAttach();
-        Threads threads = VM.getVM().getThreads();
-        int len = threads.getNumberOfThreads();
-        long[] result = new long[len * 3];    // triple
+        long[] result = new long[javaThreadList.size() * 3];    // triple
         long beg, end;
         int i = 0;
-        for (int k = 0; k < threads.getNumberOfThreads(); k++) {
-            JavaThread t = threads.getJavaThreadAt(k);
+        for (var t : javaThreadList) {
             end = t.getStackBaseValue();
             beg = end - t.getStackSize();
-            BsdThread bsdt = (BsdThread)t.getThreadProxy();
-            long uid = bsdt.getUniqueThreadId();
-            if (threadList != null) threadList.add(bsdt);
+            long uid = ((BsdThread)t.getThreadProxy()).getUniqueThreadId();
             result[i] = uid;
             result[i + 1] = beg;
             result[i + 2] = end;

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3550467374

From dlong at openjdk.org  Wed Nov 19 04:20:44 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Nov 2025 04:20:44 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v3]
In-Reply-To: <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
Message-ID: <2VkzhmbwgWzKma52fXgAHF-zi2Asd54tED_c57K8WOk=.6ee5549b-2136-489d-a71b-ba468b1e1de0@github.com>

On Tue, 18 Nov 2025 22:35:38 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace `guarantee` with `assert` in the C1 `emit_deopt_handler`

src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp line 539:

> 537:     // the return address points to the deopt handler stub code entry point which could be
> 538:     // at the end of page.
> 539:     first_check_size = 4

Suggestion:

    first_check_size = instruction_size

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28192#discussion_r2540463385

From dlong at openjdk.org  Wed Nov 19 04:27:09 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Nov 2025 04:27:09 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v3]
In-Reply-To: <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
Message-ID: <LfADpkIeDVQ7kgXNT87lC5C1SZR8-mdhjAMGHxTCX5M=.e693d0ae-dc5e-4762-8f1c-5d861aa1a7ae@github.com>

On Tue, 18 Nov 2025 22:35:38 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace `guarantee` with `assert` in the C1 `emit_deopt_handler`

src/hotspot/cpu/s390/nativeInst_s390.hpp line 657:

> 655:     // code entry point, then it has to happen in two stages - to prevent out of bounds access
> 656:     // in case the return address points to the entry point which could be at the end of page.
> 657:     first_check_size = 0

Suggestion:

    first_check_size = 0 // check is unimplemented

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28192#discussion_r2540471158

From dlong at openjdk.org  Wed Nov 19 04:31:41 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Nov 2025 04:31:41 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <Us6SbX-VztiIbBdDMeEvzGAllBgnZSnzCb4B7zpkUrU=.133050a6-fd59-490e-94f3-96280909d6f0@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <-h6G9ajUWQwDRcUMOtyI_YCUCkXz3pzRggJk_UaxM-0=.a8c772aa-2f09-48c0-9cfb-17e624393eb0@github.com>
 <Us6SbX-VztiIbBdDMeEvzGAllBgnZSnzCb4B7zpkUrU=.133050a6-fd59-490e-94f3-96280909d6f0@github.com>
Message-ID: <yRRZIhvHvqoMZXM_eEKmHmAsCQ7ACGfNapyZYD8zv88=.139da312-e5c0-498b-88d1-462a36540356@github.com>

On Mon, 17 Nov 2025 12:10:45 GMT, Ruben <duke at openjdk.org> wrote:

> Is there any additional testing you would recommend to perform before this can be integrated?

Oracle likes to make sure the final version passes in our CI.  I got burned last time testing an earlier version and not the final version.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3550665267

From sspitsyn at openjdk.org  Wed Nov 19 04:57:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 04:57:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

Thank you for refactoring the test into several tests which share a common part. It is nice!
May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3550803652

From sspitsyn at openjdk.org  Wed Nov 19 05:08:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 05:08:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <fDuBWVKs7Dn3InszOukk8szwq73jXBBZpMcSQf1-5vI=.f21965da-161b-4522-8f44-bd5e2de0c8bd@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 218:

> 216: 
> 217:         return 0;
> 218:     }

Nit: Launch of `Waiter` and `Resumer`, some testing steps and test shutdown are identical for all 3 tests. So, they can be factored out into separate functions located in the base file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2540553311

From cjplummer at openjdk.org  Wed Nov 19 05:48:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 05:48:59 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <mZRJCg7VlrR_8pNTmJk4Zj9fDW0Wxe5CetoIGMT0oEA=.e6a9b1e6-d8fb-4bf3-b1d7-088398fbfb52@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

With your diffs ClhsdbPStack.java is passing but now I'm seeing issues with the following 3 core file tests on both aarch64 and x64:


serviceability/sa/ClhsdbFindPC.java#xcomp-core
serviceability/sa/ClhsdbFindPC.java#no-xcomp-core
serviceability/sa/ClhsdbCDSCore.java


In the log it is having trouble with the stack trace:


hsdb> + jstack -v
Deadlock Detection:

No deadlocks found.

"main" #3 prio=5 tid=0x00007fa48a809010 nid=10499 runnable [0x000070000b780000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native

Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet(BsdDebuggerLocal.java:462)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:68)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.bsd_amd64.BsdAMD64JavaThreadPDAccess.getCurrentFrameGuess(BsdAMD64JavaThreadPDAccess.java:98)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:266)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:228)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:81)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$23.doit(CommandProcessor.java:1020)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2088)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2058)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1929)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:113)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:45)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)


This repeats for every thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3550910458

From ysuenaga at openjdk.org  Wed Nov 19 07:09:30 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 19 Nov 2025 07:09:30 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <mZRJCg7VlrR_8pNTmJk4Zj9fDW0Wxe5CetoIGMT0oEA=.e6a9b1e6-d8fb-4bf3-b1d7-088398fbfb52@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <mZRJCg7VlrR_8pNTmJk4Zj9fDW0Wxe5CetoIGMT0oEA=.e6a9b1e6-d8fb-4bf3-b1d7-088398fbfb52@github.com>
Message-ID: <QGbhf4usYX_dgynMrOLtCJa5IfWXayKZy4ve4MziLI4=.9b1a7cb8-6811-4cea-961e-c3219e161de8@github.com>

On Wed, 19 Nov 2025 05:46:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for Linux PPC64 and RISC-V
>
> With your diffs ClhsdbPStack.java is passing but now I'm seeing issues with the following 3 core file tests on both aarch64 and x64:
> 
> 
> serviceability/sa/ClhsdbFindPC.java#xcomp-core
> serviceability/sa/ClhsdbFindPC.java#no-xcomp-core
> serviceability/sa/ClhsdbCDSCore.java
> 
> 
> In the log it is having trouble with the stack trace:
> 
> 
> hsdb> + jstack -v
> Deadlock Detection:
> 
> No deadlocks found.
> 
> "main" #3 prio=5 tid=0x00007fa48a809010 nid=10499 runnable [0x000070000b780000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 
> Error occurred during stack walking:
> sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
> 	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet(BsdDebuggerLocal.java:462)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:68)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.bsd_amd64.BsdAMD64JavaThreadPDAccess.getCurrentFrameGuess(BsdAMD64JavaThreadPDAccess.java:98)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:266)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:228)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:81)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$23.doit(CommandProcessor.java:1020)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2088)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2058)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1929)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:113)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:45)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> This repeats for every thread.

@plummercj Thanks a lot for your report! The error what you saw is caused that thread list wasn't made in `attach()`.
I think following patch goes well... Can you try it?


diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
index 10f6881d010..7c71dcd0ca5 100644
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2025, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,9 @@
 package sun.jvm.hotspot.debugger.bsd;

 import java.util.ArrayList;
+import java.util.Collections;
 import java.util.List;
+import java.util.stream.IntStream;

 import sun.jvm.hotspot.debugger.Address;
 import sun.jvm.hotspot.debugger.DebuggerBase;
@@ -75,10 +77,11 @@ public class BsdDebuggerLocal extends DebuggerBase implements BsdDebugger {
     // CDebugger support
     private BsdCDebugger cdbg;

-    // threadList and loadObjectList are filled by attach0 method
-    private List<ThreadProxy> threadList;
+    // loadObjectList are filled by attach0 method
     private List<LoadObject> loadObjectList;

+    private List<JavaThread> javaThreadList;
+
     // called by native method lookupByAddress0
     private ClosestSymbol createClosestSymbol(String name, long offset) {
        return new ClosestSymbol(name, offset);
@@ -241,10 +244,16 @@ private void findABIVersion() throws DebuggerException {
         }
     }

+    private List<JavaThread> generateJavaThreadList() {
+      Threads threads = VM.getVM().getThreads();
+      return IntStream.range(0, threads.getNumberOfThreads())
+                      .mapToObj(threads::getJavaThreadAt)
+                      .toList();
+    }
+
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(int processID) throws DebuggerException {
         checkAttached();
-        threadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         class AttachTask implements WorkerThreadTask {
            int pid;
@@ -253,6 +262,10 @@ public void doit(BsdDebuggerLocal debugger) {
               debugger.attached = true;
               debugger.isCore = false;
               findABIVersion();
+
+              // TODO: thread list on macOS is now supported for corefile only.
+              debugger.javaThreadList = debugger.isDarwin ? Collections.emptyList()
+                                                          : generateJavaThreadList();
            }
         }

@@ -264,12 +277,12 @@ public void doit(BsdDebuggerLocal debugger) {
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(String execName, String coreName) {
         checkAttached();
-        threadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         attach0(execName, coreName);
         attached = true;
         isCore = true;
         findABIVersion();
+        javaThreadList = generateJavaThreadList();
     }

     /** From the Debugger interface via JVMDebugger */
@@ -278,7 +291,7 @@ public synchronized boolean detach() {
             return false;
         }

-        threadList = null;
+        javaThreadList = null;
         loadObjectList = null;

         if (isCore) {
@@ -492,7 +505,9 @@ public Address newAddress(long value) {
     /** From the BsdCDebugger interface */
     public List<ThreadProxy> getThreadList() {
       requireAttach();
-      return threadList;
+      return javaThreadList.stream()
+                           .map(JavaThread::getThreadProxy)
+                           .toList();
     }

     /** From the BsdCDebugger interface */
@@ -561,21 +576,16 @@ public void doit(BsdDebuggerLocal debugger) {
     /** this functions used for core file reading and called from native attach0,
         it returns an array of long integers as
         [thread_id, stack_start, stack_end, thread_id, stack_start, stack_end, ....] for
-        all java threads recorded in Threads. Also adds the ThreadProxy to threadList */
+        all java threads recorded in Threads. */
     public long[] getJavaThreadsInfo() {
         requireAttach();
-        Threads threads = VM.getVM().getThreads();
-        int len = threads.getNumberOfThreads();
-        long[] result = new long[len * 3];    // triple
+        long[] result = new long[javaThreadList.size() * 3];    // triple
         long beg, end;
         int i = 0;
-        for (int k = 0; k < threads.getNumberOfThreads(); k++) {
-            JavaThread t = threads.getJavaThreadAt(k);
+        for (var t : javaThreadList) {
             end = t.getStackBaseValue();
             beg = end - t.getStackSize();
-            BsdThread bsdt = (BsdThread)t.getThreadProxy();
-            long uid = bsdt.getUniqueThreadId();
-            if (threadList != null) threadList.add(bsdt);
+            long uid = ((BsdThread)t.getThreadProxy()).getUniqueThreadId();
             result[i] = uid;
             result[i + 1] = beg;
             result[i + 2] = end;

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3551112603

From mbaesken at openjdk.org  Wed Nov 19 08:32:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 08:32:25 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>
Message-ID: <aDCri5ZhnIwjnFWmXkCDDWPiM1elG33O9RnAOweAZwE=.628d1666-8ee1-4b67-a600-2c84d6344984@github.com>

On Wed, 19 Nov 2025 02:29:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped.

Would be good to have a fix people agree on, because we already saw the issue with lto enabled for Hotspot (see my comment above).  So it is not only an issue related to the dead_strip flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3551410166

From mdoerr at openjdk.org  Wed Nov 19 09:15:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Nov 2025 09:15:51 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v3]
In-Reply-To: <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <SCzlDKru1LYLQfHh2ByUqRD9R27CI-mM39ulYhDuSXw=.69e63f7e-22ad-4f3f-a64e-39e1238153d8@github.com>
Message-ID: <lJrdgT-LGhKZfHlb2xgSRMY5V7q5X5SU1YcEqa4-6bQ=.c982386b-61f6-453b-a960-f72a06609fa8@github.com>

On Tue, 18 Nov 2025 22:35:38 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace `guarantee` with `assert` in the C1 `emit_deopt_handler`

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28192#pullrequestreview-3481619005

From adinn at openjdk.org  Wed Nov 19 09:33:52 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 19 Nov 2025 09:33:52 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v2]
In-Reply-To: <kppTc2rExxZ9ARDm6h7-JldccWa0iNK27oZiaZG5aVI=.41121ea0-d122-469e-9489-120fc3478350@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <Nn8IH_V2juZLEX4TvL0RB3ucR75tlsd6NaAzBas2mQQ=.0216481c-aeb7-44d4-b73d-35a4aeeb293c@github.com>
 <IJ1-Avg8M0RlJC91IhQnjy0gjROcv073EYeeHaOnamI=.c7ac055d-6fb0-4321-bff1-4787ca273983@github.com>
 <kppTc2rExxZ9ARDm6h7-JldccWa0iNK27oZiaZG5aVI=.41121ea0-d122-469e-9489-120fc3478350@github.com>
Message-ID: <OfqQKyoN96m6c8WFFPoEUBPIqaWH5pJDI4GT9ZV-Pp0=.e33cb4e9-56e2-4249-80dc-09c517547357@github.com>

On Tue, 18 Nov 2025 14:15:58 GMT, Ruben <duke at openjdk.org> wrote:

>> Our tests haven't revealed any new issues related to this PR.
>
> Thank you, @TheRealMDoerr,
> 
>> I think assertions would be sufficient in C1 instead of guarantee.
> 
> Sure, I will change these to assertions.

@ruben-arm I'm ok with this version assuming it passes tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3551720864

From coleenp at openjdk.org  Wed Nov 19 12:34:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Nov 2025 12:34:30 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v3]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <KhHcTXHg33ph1n7IYvbH8t1PnKdiwv21ukgLys6kZrk=.28f59b50-2746-4c00-9c56-68f9d6215fa4@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Revert a couple more InstanceKlass::casts also to get GHA to restart.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/e8973f59..1060463b

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

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

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

From mbaesken at openjdk.org  Wed Nov 19 13:07:28 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 13:07:28 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <nyDtm2Xmvgx9JjP5M6TKUsIJe_Mw3NW_Kta5zR-576Y=.d65500ff-7823-432f-8460-f09ca5dda703@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <nyDtm2Xmvgx9JjP5M6TKUsIJe_Mw3NW_Kta5zR-576Y=.d65500ff-7823-432f-8460-f09ca5dda703@github.com>
Message-ID: <KWJNMVffhGrSQ_06bDieIjduVv93jn2GOzIPV8ROWdc=.fb4bce8a-41b5-4c4f-9b46-03d20c80f73f@github.com>

On Tue, 18 Nov 2025 23:36:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As usual, maybe it is possible to split this patch between hotspot and the libraries?

For sure we can do this.
But as listed above, we only see  for a few jdk  native libs a good size benefit when using this additional flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552594695

From mbaesken at openjdk.org  Wed Nov 19 13:11:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 13:11:29 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <JjPQmA7hi_vP_slIWRgagQ-WA4jbLSH0ESZaaQWN49Q=.330e3fea-3cd1-4c96-ba04-d192218c9ae7@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <U5v9_rGEaHgAKSvDyOChfJ4Wqr1FbHRfAruQsdPEwyQ=.f0c516d2-ba7f-4415-bb7e-0f5cd6e52f79@github.com>
 <JjPQmA7hi_vP_slIWRgagQ-WA4jbLSH0ESZaaQWN49Q=.330e3fea-3cd1-4c96-ba04-d192218c9ae7@github.com>
Message-ID: <pgYElmtnYvbkOEZjtUnBuUm60z3YT1pxWDIv65djWQs=.43841cb5-96a4-4950-a56f-40eaf9a6d0ea@github.com>

On Tue, 18 Nov 2025 08:55:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Is there is a particular reason to not apply this on x64 as well?
> 
> On macOS x86_64 I saw in our CI those tests failing when enabling the dead_strip feature serviceability/sa/ClhsdbCDSCore.java serviceability/sa/ClhsdbFindPC.jav serviceability/sa/ClhsdbPstack.java
> 
> (and macOS on Intel is not that interesting any more these days)
> 
> For macOS aarch64, the tests in our CI were fine but I see some failures in the GHA in the serviceability area.
> 
> ```
> finding class loader instances ..java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> ```
> 
> Have to check why I do not see those issues in our test infra.


Okay I checked why this is the case.
In our internal test setup we see some serviceability/sa - tests skipped because of  'SA Attach not expected to work. Insufficient privileges' . This can happen in some test setups especially on macOS but is not very helpful to test the influence of the dead_strip flag on the sa tests .

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552605391

From aph at openjdk.org  Wed Nov 19 13:19:16 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 19 Nov 2025 13:19:16 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <qYnJiPSsuMP0GY5SJCXZm6NnO1emPHzbmTCj25md3no=.3e4ce54e-9494-48ec-962d-dd08359961c6@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

I remember s390 used to strip unneeded stuff, and it was very hard to debug anything. Please think about whether you need to do this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552643306

From mbaesken at openjdk.org  Wed Nov 19 13:26:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 13:26:29 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <qYnJiPSsuMP0GY5SJCXZm6NnO1emPHzbmTCj25md3no=.3e4ce54e-9494-48ec-962d-dd08359961c6@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <qYnJiPSsuMP0GY5SJCXZm6NnO1emPHzbmTCj25md3no=.3e4ce54e-9494-48ec-962d-dd08359961c6@github.com>
Message-ID: <MnujiXT-DDxR5wNEDwbzGnLO69L8Q1A2dLIRjbUkC0E=.cf0f21d1-62e1-4302-ac17-a1b2a041f5e3@github.com>

On Wed, 19 Nov 2025 13:14:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I remember s390 used to strip unneeded stuff, and it was very hard to debug anything.

What exactly was hard to debug? 
Did you use (fast)debug or product binaries ?
I do not remember issues like this on s390  but I can ask my (ex)colleagues who dealt more with s390 .

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552676735

From alanb at openjdk.org  Wed Nov 19 13:54:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Nov 2025 13:54:03 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>

On Mon, 17 Nov 2025 20:19:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. An alternative that avoids the extra fence would be to place extra overhead on the thread requesting to disable transitions (e.g. by usi
 ng a safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so I believe this approach is simpler.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and unmount cases, and a...

src/java.base/share/classes/java/lang/VirtualThread.java line 1390:

> 1388:     }
> 1389: 
> 1390:     // -- JVM TI support --

We'll need to update is comment as it no longer only for JVMTI. 

This might be a good place for a block comment to define "transitions" covering the changing of thread identity the continuation mount/unmount, and how the notification to the VM support JVMTI and handshakes.  Maybe I could contribute a block comment to include here?

src/java.base/share/native/libjava/VirtualThread.c line 38:

> 36:     { "startFinalTransition",     "()V",  (void *)&JVM_VirtualThreadEnd },
> 37:     { "startTransition",          "(Z)V", (void *)&JVM_VirtualThreadStartTransition },
> 38:     { "endTransition",            "(Z)V", (void *)&JVM_VirtualThreadEndTransition },

I wonder if JVM_VirtualThreadStart and JVM_VirtualThreadEnd should be renamed to have EndFirstTransition and StartFinalTransaction in the names so it's easy to follow through from the Java code down to MountUnmountDisabler::start_transition/end_transition.

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWhenParking.java line 94:

> 92:                 });
> 93:             }
> 94:             // wait for all virtual threads to start so all have a non-empty stack

This reminds me the loom repo has a small update to to the DumpThreadsWithEliminatedLock.java test to ensure that the virtual thread starts execution before doing the thread dump. This was noticed with test-repeat runs of the new test to ensure it was stable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2542097138
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2542016761
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2542034248

From jsjolen at openjdk.org  Wed Nov 19 14:28:37 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 14:28:37 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v16]
In-Reply-To: <N4u6yCmwx4e1kR7RDL9PBPku50w4urxw73iGk_bY7uo=.ad4721d3-7ea1-43c2-b5d8-000ec2c7c794@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>
 <N4u6yCmwx4e1kR7RDL9PBPku50w4urxw73iGk_bY7uo=.ad4721d3-7ea1-43c2-b5d8-000ec2c7c794@github.com>
Message-ID: <z_L2bq5UHy8U0PxM9sM4RL8LNxbDa_Mwx41KhcWbV-s=.993b6efe-2f40-4a16-b854-12ab84004fba@github.com>

On Wed, 5 Nov 2025 12:42:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into operands-again
>>  - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
>>  - Fix naming
>>  - Serguei comments
>>  - Revert change
>>  - Some nits
>>  - Fix copyright
>>  - Move BSMAttribute BSMAttributeEntries to own header file
>>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/c1908450...57f0093e
>
> src/hotspot/share/oops/bsmAttribute.hpp line 28:
> 
>> 26: #define SHARE_OOPS_BSMATTRIBUTE_HPP
>> 27: 
>> 28: #include "classfile/classLoaderData.hpp"
> 
> I think you can forward declare ClassLoaderData rather than include the whole file here.

Ooh, you're right about that!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2542245468

From jsjolen at openjdk.org  Wed Nov 19 14:33:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 14:33:19 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v17]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <6CQmVFTykatS4KDf9yWPGhLS8a_acPcW9Ds4Y6Utbuw=.4d3d889f-46e9-4766-9680-26b8b162746f@github.com>

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

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

  Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/57f0093e..3686fc34

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

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

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

From jsjolen at openjdk.org  Wed Nov 19 14:33:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 14:33:21 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <8WVVrT5cKKUY1wGnTvxzj-8FFM-dZnYtuActIQRXZUQ=.0f11587c-e06f-47ee-93e4-bd7a5e7fc16f@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
 <8WVVrT5cKKUY1wGnTvxzj-8FFM-dZnYtuActIQRXZUQ=.0f11587c-e06f-47ee-93e4-bd7a5e7fc16f@github.com>
Message-ID: <Wl_3U2WqAXhKj_hQhBd5MaMVwMZ-c7dCC9WHjDynTQ8=.cb711d41-29cc-4e1f-a081-3e6eded277bd@github.com>

On Wed, 5 Nov 2025 12:46:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/bsmAttribute.inline.hpp line 34:
>> 
>>> 32:       _cur_array + BSMAttributeEntry::u2s_required(argc) > insert_into->bootstrap_methods()->length()) {
>>> 33:     return nullptr;
>>> 34:   }
>> 
>> Nit: This check needs a comment. Also, I'd suggest to add a guarantee here instead of returning `nullptr`.
>
> I agree with this comment - is returning null going to crash somewhere down the line?  Is this an overflow?

Returning null generally shouldn't happen. It indicates that we have supplied too little space for the entries. The reason I don't `guarantee` here is because this function doesn't have enough context to output a proper error message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2542253926

From jsjolen at openjdk.org  Wed Nov 19 14:38:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 14:38:56 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v17]
In-Reply-To: <6CQmVFTykatS4KDf9yWPGhLS8a_acPcW9Ds4Y6Utbuw=.4d3d889f-46e9-4766-9680-26b8b162746f@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <6CQmVFTykatS4KDf9yWPGhLS8a_acPcW9Ds4Y6Utbuw=.4d3d889f-46e9-4766-9680-26b8b162746f@github.com>
Message-ID: <YAhLecItfEQTCb_Q_CLiLGc8V6-flsGmINL8d1b9WzE=.30a53b0e-47ed-4a14-bbb9-18844724ba43@github.com>

On Wed, 19 Nov 2025 14:33:19 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

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

Hi!

I'm back. I've done some benchmarking (DaCapo, etc) and found no discernible differences. I've also run Tier1-tier6 with the changes before 'Comments'. A total of 4 test failures, all seems highly unrelated to my changes so I'm not worried. I'd apprecaite a re-approval so I can integrate this :-).

Thank you all for your efforts in making this PR happen.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3553042638

From mbaesken at openjdk.org  Wed Nov 19 15:06:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 15:06:46 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <prNTBf-w5QCFgcW4DJWbBljUN2OIx9VAim7PBOVPDMA=.56c11e51-e0bd-4093-aedc-7a11ef268415@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

Btw on Linux s390x it is the `linktime-gc` , but from what I see this can be disabled by configure if you don't like it 

https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/make/autoconf/jdk-options.m4#L112
https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/make/autoconf/flags-ldflags.m4#L55

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553211601

From mbaesken at openjdk.org  Wed Nov 19 15:22:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 15:22:45 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>
Message-ID: <bl3E2_UszgK2WO3nlL2-ATzQxJSor-m-kN6hLT9Yyw4=.4367a8bc-04b1-4ff9-84c1-0114a9b7854b@github.com>

On Wed, 19 Nov 2025 02:29:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I reproduced the SA issues locally. Not surprisingly almost every SA test failed (I'm not sure why only 3 were listed above). They seemed to all fail trying to get a vtable for a hotspot type. The tests that didn't failed were doing mundane things like testing attaching, hotspot flags, and clhsdb history, but not doing anything with hotspot objects, or at least not with hotspot metadata.
> 
> I was able to confirm the problem is with the Metadata vtable missing. I fixed it by allocating a Metadata instance and assigning it to a global. However, in order to get this to compile I had make Metadata no longer be abstract. All tests passed after I did this. I'm not sure how viable a solution this is. The hotspot team will probably object to the Metadata changes. Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped.

There seem to be attributes for this kind of use case in clang, e.g. retain 
https://reviews.llvm.org/D97447
https://clang.llvm.org/docs/AttributeReference.html#retain
Should we add this to 'class Metadata'  ?
If we can do it with attributes or something similar (and without changing lots of code locations) it sounds better to me than adjusting the coding.
'Pseudo dead' stuff that is used from external tools (so it is not really 'dead' in practise) should be somehow marked to assist the tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553303689

From aph at openjdk.org  Wed Nov 19 15:33:26 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 19 Nov 2025 15:33:26 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <cFnygO0iyq1BgmaQDx35WcBtLbQt-48cst_vAKH9DWo=.72cb6cb7-6655-4177-8122-808fe0f2a829@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

On 19/11/2025 13:22, Matthias B?sken wrote:
> MBaesken left a comment (openjdk/jdk#28319)
> 
>> I remember s390 used to strip unneeded stuff, and it was very hard to debug anything.
> 
> What exactly was hard to debug?
> Did you use (fast)debug or product binaries ?
> I do not remember issues like this on s390  but I can ask my (ex)colleagues who dealt more with s390 .

It was hard to debug hotspot. Helpers such as pp(), back_trace(), and pfl() were missing. 

I think it was a release build, but of course you sometimes have to debug release builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553349390

From aph at openjdk.org  Wed Nov 19 15:39:10 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 19 Nov 2025 15:39:10 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <prNTBf-w5QCFgcW4DJWbBljUN2OIx9VAim7PBOVPDMA=.56c11e51-e0bd-4093-aedc-7a11ef268415@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <prNTBf-w5QCFgcW4DJWbBljUN2OIx9VAim7PBOVPDMA=.56c11e51-e0bd-4093-aedc-7a11ef268415@github.com>
Message-ID: <9IgIs95wIgZ7ph5S69JEqYoKqitRnmg9pptrqzVCGkk=.5477177e-9402-498f-b858-876061977821@github.com>

On Wed, 19 Nov 2025 15:03:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Btw on Linux s390x it is the `linktime-gc` , but from what I see this can be disabled by configure if you don't like it

Yes, it can. Thankfully I don't usually need to debug hotspot in production s390 systems. I do, however, need to debug AArch64 on MacOS. This is a Very Bad Idea, and should not be dome.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553368265

From aartemov at openjdk.org  Wed Nov 19 16:04:51 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 19 Nov 2025 16:04:51 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Refactored tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/8c82d39c..08b481cd

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

  Stats: 388 lines in 5 files changed: 112 ins; 255 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Wed Nov 19 16:04:55 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 19 Nov 2025 16:04:55 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
 <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
Message-ID: <JuQz_Bq3gav3r6pmzdt_DeIY_vZItvsbjqpD0jj2-Ic=.6baf7706-c626-47b6-a693-240078d1c05f@github.com>

On Wed, 19 Nov 2025 04:55:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Added bool arg to notify_contended_enter
>
> Thank you for refactoring the test into several tests which share a common part. It is nice!
> May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

> @sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:
> 
> Master branch, events posted: wait -> waited -> contended enter -> contended entered This PR: events posted: wait -> contended enter -> contended entered -> waited
> 
> I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of `wait` or not?

@sspitsyn could you please comment on the order of events and possible issues we can get if the order is changed?

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 218:
> 
>> 216: 
>> 217:         return 0;
>> 218:     }
> 
> Nit: Launch of `Waiter` and `Resumer`, some testing steps and test shutdown are identical for all 3 tests. So, they can be factored out into separate functions located in the base file.

Thanks, I have applied a bit more refactoring, trying to move common stuff into the base test class.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3553429559
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2542591879

From mbaesken at openjdk.org  Wed Nov 19 16:35:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 16:35:03 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <R8KBiyhp11WUxqrH_bk7KxZm36s7CBzGPGpibBFpWCE=.1af39acc-6b88-44a4-8378-68de488a8911@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

Seems like we should fix the elimination of those debug helpers ; but those are only in the jvm lib. The situation in other libs is different.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553637974

From cjplummer at openjdk.org  Wed Nov 19 16:46:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 16:46:32 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <bl3E2_UszgK2WO3nlL2-ATzQxJSor-m-kN6hLT9Yyw4=.4367a8bc-04b1-4ff9-84c1-0114a9b7854b@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com>
 <bl3E2_UszgK2WO3nlL2-ATzQxJSor-m-kN6hLT9Yyw4=.4367a8bc-04b1-4ff9-84c1-0114a9b7854b@github.com>
Message-ID: <nUAI-rm0HZD9SI5B5d4Je_AyZf7aA5OK7mlFvwno1IQ=.45114244-3172-4634-a832-902f1685550a@github.com>

On Wed, 19 Nov 2025 15:20:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seem to be attributes for this kind of use case in clang, e.g. retain
> https://reviews.llvm.org/D97447
> https://clang.llvm.org/docs/AttributeReference.html#retain
> Should we add this to 'class Metadata' ?
> If we can do it with attributes or something similar (and without changing lots of code locations) it sounds better to me than adjusting the coding.
> 'Pseudo dead' stuff that is used from external tools (so it is not really 'dead' in practise) should be somehow marked to assist the tools.
> There is also an attribute 'used' that looks similar.

I tried the following but it didn't work. Perhaps I don't have the syntax right:


--- a/src/hotspot/share/oops/metadata.hpp
+++ b/src/hotspot/share/oops/metadata.hpp
@@ -30,6 +30,7 @@
 #include "utilities/ostream.hpp"
 
 // This is the base class for an internal Class related metadata
+#pragma retain Metadata
 class Metadata : public MetaspaceObj {
   // Debugging hook to check that the metadata has not been deleted.
   NOT_PRODUCT(int _valid;)


Note `retain` and `used` are listed under function attributes. They probably don't apply to data.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553656342

From cjplummer at openjdk.org  Wed Nov 19 17:30:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 17:30:21 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <SUnXfcniwYs4Xbg8Ch9paFhgOGTYHgEG5rNsuNLLtKA=.7db05e8b-0d8c-4820-b6a1-292e113a6739@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

The following is how you declare a reference to the vtable:

extern "C" void* _ZTV8Metadata[];

If you then reference _ZTV8Metadata from somewhere in a way that does not get dead stripped, that seems to fix the problem. The latter part is definitely very hacky. It would be nice to get a pragma working to keep the symbol from being deadstripped.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553874175

From sspitsyn at openjdk.org  Wed Nov 19 18:12:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 18:12:12 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
Message-ID: <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>

On Wed, 19 Nov 2025 16:04:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Refactored tests.

Thank you for update!

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 141:

> 139: 
> 140: 
> 141: 

Nit: unneeded empty lines

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait2.java line 156:

> 154: 
> 155: 
> 156: 

Nit: unneeded empty lines

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait3.java line 166:

> 164: 
> 165: 
> 166: 

Nit: unneeded empty lines

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3484035013
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543018144
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543018979
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543019514

From cjplummer at openjdk.org  Wed Nov 19 18:57:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 18:57:14 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <bgHvkTns9B2rmngEQgH3jkUWmPweyLABz7Ztcb50mI0=.85f750bd-1f56-4f4f-9e17-1b80804d2bba@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

This seems to work:


extern void* _ZTV8Metadata[];

__attribute__((used))
 void* foo() {
  return _ZTV8Metadata[0];
}


You can put this anywhere since it does not reference any hotspot types. It just needs to be linked in with libjvm. Note I tried putting the "used" attribute on _ZTV8Metadata and getting rid of the foo() part, but I got the following warning and the vtable was dead stripped:

`warning: 'used' attribute ignored on a non-definition declaration [-Wignored-attributes]`

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3554180419

From pchilanomate at openjdk.org  Wed Nov 19 19:06:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 19 Nov 2025 19:06:34 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent [v2]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <vRL-DhckCbjhrOARSxPXVqnvFESnQby4rQphK9VTwZM=.9e2f72d3-2200-4fe1-95d5-33178ce0c65e@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. An alternative that avoids the extra fence would be to place extra overhead on the thread requesting to disable transitions (e.g. by usi
 ng a safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so I believe this approach is simpler.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and unmount cases, and a...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Add fixes to DumpThreadsWithEliminatedLock.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/70f96a7d..976486cd

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

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

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

From pchilanomate at openjdk.org  Wed Nov 19 19:06:37 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 19 Nov 2025 19:06:37 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent [v2]
In-Reply-To: <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
Message-ID: <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>

On Wed, 19 Nov 2025 13:50:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add fixes to DumpThreadsWithEliminatedLock.java
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 1390:
> 
>> 1388:     }
>> 1389: 
>> 1390:     // -- JVM TI support --
> 
> We'll need to update is comment as it no longer only for JVMTI. 
> 
> This might be a good place for a block comment to define "transitions" covering the changing of thread identity the continuation mount/unmount, and how the notification to the VM support JVMTI and handshakes.  Maybe I could contribute a block comment to include here?

That would be great.

> src/java.base/share/native/libjava/VirtualThread.c line 38:
> 
>> 36:     { "startFinalTransition",     "()V",  (void *)&JVM_VirtualThreadEnd },
>> 37:     { "startTransition",          "(Z)V", (void *)&JVM_VirtualThreadStartTransition },
>> 38:     { "endTransition",            "(Z)V", (void *)&JVM_VirtualThreadEndTransition },
> 
> I wonder if JVM_VirtualThreadStart and JVM_VirtualThreadEnd should be renamed to have EndFirstTransition and StartFinalTransaction in the names so it's easy to follow through from the Java code down to MountUnmountDisabler::start_transition/end_transition.

How about removing these methods and just have an extra boolean parameter in `start/endTransition`?
https://github.com/pchilano/jdk/compare/JDK-8364343...pchilano:jdk:startEndTransitionsOnly

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWhenParking.java line 94:
> 
>> 92:                 });
>> 93:             }
>> 94:             // wait for all virtual threads to start so all have a non-empty stack
> 
> This reminds me the loom repo has a small update to to the DumpThreadsWithEliminatedLock.java test to ensure that the virtual thread starts execution before doing the thread dump. This was noticed with test-repeat runs of the new test to ensure it was stable.

Added the fixes to `DumpThreadsWithEliminatedLock.java` from the loom repo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543217770
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543212884
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2543215701

From sspitsyn at openjdk.org  Wed Nov 19 19:11:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 19:11:02 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
 <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
Message-ID: <aup3c3reezY0DRErSMxvq0Gx6BMK5t2-doScxFKCdGs=.8e4529c1-879d-4bb6-8f8f-95e08c422542@github.com>

On Wed, 19 Nov 2025 04:55:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Added bool arg to notify_contended_enter
>
> Thank you for refactoring the test into several tests which share a common part. It is nice!
> May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

> @sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:
> Master branch, events posted: wait -> waited -> contended enter -> contended entered
> This PR: events posted: wait -> contended enter -> contended entered -> waited
> 
> I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of wait or not?

I also do not see anything in the specs (JLS, JVMS and JVMTI) but I feel it is better to keep the original order if possible.
It is going to be an impact/change on the thread state:
  https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

AFAIU, with this change new combinations of thread state bits will be observable:
  `JVMTI_THREAD_STATE_WAITING` + `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`
  + (`JVMTI_THREAD_STATE_WAITING_INDEFINITELY` | `JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT`)

Also, it is a change in behavior with a compatibility risk involved. So, a CSR will be needed for this change.
I'm not sure yet if we need to consult with the JCK team on this if no JCK tests are failed.

What mach5 tests did you run? In this case, it is more safe to run mach5 tiers 1-6.
@dholmes-ora may have some concerns here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3554220528

From aph at openjdk.org  Wed Nov 19 19:11:02 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 19 Nov 2025 19:11:02 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <R8KBiyhp11WUxqrH_bk7KxZm36s7CBzGPGpibBFpWCE=.1af39acc-6b88-44a4-8378-68de488a8911@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <R8KBiyhp11WUxqrH_bk7KxZm36s7CBzGPGpibBFpWCE=.1af39acc-6b88-44a4-8378-68de488a8911@github.com>
Message-ID: <FEcGhBLwmiF-gKX2K8mExoKLfp01LuLgseo5gK7TvJ0=.10ce938e-5cc8-4311-82d3-bab3bba55b16@github.com>

On Wed, 19 Nov 2025 16:31:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems like we should fix the elimination of those debug helpers ; but those are only in the jvm lib. The situation in other libs is different.

Maybe, but it's not just the specific debug helpers. There are many functions in hotspot, and the maintenance programmer (in the case of Mac/AArch64, that's often me) will frequently type stuff like `print a->size()`. 

Linker options that strip "unused" code in binaries have been available for decades, and we haven't much used such options because they're a pain. Debugging on MacOS/AArch64 is a pain as it is, without making it worse.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3554226232

From cjplummer at openjdk.org  Wed Nov 19 20:36:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Nov 2025 20:36:05 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <0TxBLi0V1trfnojqXWHqzvI6CNA1DNPDU3-QVB2UtOU=.a49a0a74-69da-4710-92b2-cca833a392d5@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

stderr: [Exception in thread "main" java.lang.RuntimeException: VM.initialize() was not yet called
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.getVM(VM.java:576)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.generateJavaThreadList(BsdDebuggerLocal.java:248)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach(BsdDebuggerLocal.java:285)
	at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:638)
	at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerDarwin(HotSpotAgent.java:624)
	at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:378)
	at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:343)
	at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:157)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:211)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:70)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:45)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)


VM.initialize() is not triggered until after HotSpotAgent.setupDebugger() returns:


    private void go() {
        setupDebugger();
        setupVM();
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3554527760

From macarte at openjdk.org  Wed Nov 19 22:40:54 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 22:40:54 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
 <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
 <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>
 <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>
 <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com>
Message-ID: <luIvMqTyLXvvRY6j7W_C0b0pBcnZUIImkkQ3U1b1cz0=.2f1fe93d-6956-4136-8cf5-39da78285ef3@github.com>

On Mon, 3 Nov 2025 11:01:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I also removed the nested {@code ..} from within the <pre\></pre\> as that also caused an issue
>
> Good. You can move the example to a snippet too and that will  allow the `<pre>` tags to go away.

In the latest CSR the code snippet was removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2543782660

From macarte at openjdk.org  Wed Nov 19 22:50:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 22:50:02 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>

On Fri, 14 Nov 2025 18:03:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 996:
> 
>> 994:     output()->print_cr("Error! Not a recording run");
>> 995:     return;
>> 996:   }
> 
> First, is `output()` directed to VM's tty or somewhere else?
> 
> Second, I think you need to be more verbose in error. Maybe:
> 
> Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.

There are two cases:

1) When using jcmd the output is piped back from the VM to the jcmd process which in turn outputs the message to tty
2) When invoked using the DiagnosticCommandBean the output is piped back to the bean itself and returned as a string from the invoke method

These two cases are demonstrated in the included tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543798637

From lmesnik at openjdk.org  Wed Nov 19 22:57:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 19 Nov 2025 22:57:48 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
Message-ID: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>

On Wed, 19 Nov 2025 16:04:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Refactored tests.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWaitWorker.java line 42:

> 40: 
> 41:     public void run() {
> 42:         SuspendWithObjectMonitorWait1.logDebug("thread running");

SuspendWithObjectMonitorWaitBase instead of SuspendWithObjectMonitorWait1 here.
There are a lot such places in this file.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3484952328
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543738637

From macarte at openjdk.org  Wed Nov 19 22:58:09 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 22:58:09 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
 <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>
Message-ID: <UM8rgf_uBB8xBLho_IeZycAx7qMhZDir8PMayW_Fy00=.0b84b9f4-ade9-4012-a730-8c10e9b82475@github.com>

On Wed, 19 Nov 2025 22:46:32 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 996:
>> 
>>> 994:     output()->print_cr("Error! Not a recording run");
>>> 995:     return;
>>> 996:   }
>> 
>> First, is `output()` directed to VM's tty or somewhere else?
>> 
>> Second, I think you need to be more verbose in error. Maybe:
>> 
>> Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.
>
> There are two cases:
> 
> 1) When using jcmd the output is piped back from the VM to the jcmd process which in turn outputs the message to tty
> 2) When invoked using the DiagnosticCommandBean the output is piped back to the bean itself and returned as a string from the invoke method
> 
> These two cases are demonstrated in the included tests

Updated the message, following convention and not including "Error! .."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543812881

From macarte at openjdk.org  Wed Nov 19 23:06:00 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 23:06:00 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <Ojzcli84zYO28bOe7qgAv8CIHNhptpcGrP2UzRZMGrQ=.68f2212c-153b-4b84-b738-aff0f3ac7298@github.com>

On Fri, 14 Nov 2025 18:12:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1000:
> 
>> 998:   if (!AOTMetaspace::is_recording_preimage_static_archive()) {
>> 999:     output()->print_cr("Error! Not recording");
>> 1000:     return;
> 
> This check is confusing because your error message is cryptic.
> Actually I think you don't need any message here - it is not error. Use comment instead:
> 
>   // The other thread already initiated end of recording.

I've changed the message to be less cryptic, but the message should still be returned to whoever invoked the command

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543825605

From ysuenaga at openjdk.org  Thu Nov 20 00:07:45 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 20 Nov 2025 00:07:45 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <Oqr27gkBGXroexnaqmSRRhlqZ9pJESRemli5pPwL1s4=.1e38b28e-392e-4814-a671-0854a4a093fd@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

Ok, I confirmed `VM.initialize()` would be called at the end of `setupVM()`. So I updated a patch for `BsdDebuggerLocal` to initialize thread list in lazily. Can you try it again? Sorry for the trouble.


diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
index 10f6881d010..891ebc91f49 100644
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2025, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,9 @@
 package sun.jvm.hotspot.debugger.bsd;

 import java.util.ArrayList;
+import java.util.Collections;
 import java.util.List;
+import java.util.stream.IntStream;

 import sun.jvm.hotspot.debugger.Address;
 import sun.jvm.hotspot.debugger.DebuggerBase;
@@ -75,10 +77,11 @@ public class BsdDebuggerLocal extends DebuggerBase implements BsdDebugger {
     // CDebugger support
     private BsdCDebugger cdbg;

-    // threadList and loadObjectList are filled by attach0 method
-    private List<ThreadProxy> threadList;
+    // loadObjectList are filled by attach0 method
     private List<LoadObject> loadObjectList;

+    private List<JavaThread> javaThreadList;
+
     // called by native method lookupByAddress0
     private ClosestSymbol createClosestSymbol(String name, long offset) {
        return new ClosestSymbol(name, offset);
@@ -241,10 +244,21 @@ private void findABIVersion() throws DebuggerException {
         }
     }

+    private void fillJavaThreadList() {
+      // TODO: thread list on macOS is now supported for corefile only.
+      if (!isCore && isDarwin) {
+          javaThreadList = Collections.emptyList();
+      } else {
+          Threads threads = VM.getVM().getThreads();
+          javaThreadList =  IntStream.range(0, threads.getNumberOfThreads())
+                            .mapToObj(threads::getJavaThreadAt)
+                            .toList();
+      }
+    }
+
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(int processID) throws DebuggerException {
         checkAttached();
-        threadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         class AttachTask implements WorkerThreadTask {
            int pid;
@@ -264,7 +278,6 @@ public void doit(BsdDebuggerLocal debugger) {
     /** From the Debugger interface via JVMDebugger */
     public synchronized void attach(String execName, String coreName) {
         checkAttached();
-        threadList = new ArrayList<>();
         loadObjectList = new ArrayList<>();
         attach0(execName, coreName);
         attached = true;
@@ -278,7 +291,7 @@ public synchronized boolean detach() {
             return false;
         }

-        threadList = null;
+        javaThreadList = null;
         loadObjectList = null;

         if (isCore) {
@@ -492,7 +505,12 @@ public Address newAddress(long value) {
     /** From the BsdCDebugger interface */
     public List<ThreadProxy> getThreadList() {
       requireAttach();
-      return threadList;
+      if (javaThreadList == null) {
+        fillJavaThreadList();
+      }
+      return javaThreadList.stream()
+                           .map(JavaThread::getThreadProxy)
+                           .toList();
     }

     /** From the BsdCDebugger interface */
@@ -561,21 +579,19 @@ public void doit(BsdDebuggerLocal debugger) {
     /** this functions used for core file reading and called from native attach0,
         it returns an array of long integers as
         [thread_id, stack_start, stack_end, thread_id, stack_start, stack_end, ....] for
-        all java threads recorded in Threads. Also adds the ThreadProxy to threadList */
+        all java threads recorded in Threads. */
     public long[] getJavaThreadsInfo() {
         requireAttach();
-        Threads threads = VM.getVM().getThreads();
-        int len = threads.getNumberOfThreads();
-        long[] result = new long[len * 3];    // triple
+        if (javaThreadList == null) {
+            fillJavaThreadList();
+        }
+        long[] result = new long[javaThreadList.size() * 3];    // triple
         long beg, end;
         int i = 0;
-        for (int k = 0; k < threads.getNumberOfThreads(); k++) {
-            JavaThread t = threads.getJavaThreadAt(k);
+        for (var t : javaThreadList) {
             end = t.getStackBaseValue();
             beg = end - t.getStackSize();
-            BsdThread bsdt = (BsdThread)t.getThreadProxy();
-            long uid = bsdt.getUniqueThreadId();
-            if (threadList != null) threadList.add(bsdt);
+            long uid = ((BsdThread)t.getThreadProxy()).getUniqueThreadId();
             result[i] = uid;
             result[i + 1] = beg;
             result[i + 2] = end;

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3555136250

From macarte at openjdk.org  Thu Nov 20 00:46:28 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 00:46:28 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <60ObxggVqKu_dERxlWG1qDSXlvdxTfSFC-iFjpABKi8=.a6add8d8-9dc6-4275-956c-0f6137b0f5a0@github.com>

On Fri, 14 Nov 2025 18:25:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1007:
> 
>> 1005:     output()->print_cr("Recording ended successfully");
>> 1006:     return;
>> 1007:   }
> 
> I think this should be reversed and message replaced with comment.
> 
> if (AOTMetaspace::is_recording_preimage_static_archive()) {
>     // Other thread already dumped archive.
>     return;
> }
> output()->print_cr("AOT recording ended successfully");

I switched the order, but the error condition stands:  we attempted to stop the recording, but the VM believes the recording is still continuing

Please note that the flag indicates that the recording is stopping/stopped but the cache may not have been dumped yet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543974788

From cjplummer at openjdk.org  Thu Nov 20 01:17:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Nov 2025 01:17:22 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
Message-ID: <FH5cbkbvXi_pEG3RgbB4WwPT-XfDXOp8zuPaxUcUJbY=.d58c4d74-dfd8-4ec3-b35c-2cb96007eaeb@github.com>

On Thu, 13 Nov 2025 12:53:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for Linux PPC64 and RISC-V

It's passing now.

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3555309204

From ysuenaga at openjdk.org  Thu Nov 20 01:25:45 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 20 Nov 2025 01:25:45 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v3]
In-Reply-To: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
Message-ID: <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>

> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
> 
> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
> 
> Big thanks to @pchilano for your help!

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix for macOS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28284/files
  - new: https://git.openjdk.org/jdk/pull/28284/files/dfd947ab..bb2fe02f

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

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

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

From ysuenaga at openjdk.org  Thu Nov 20 01:25:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 20 Nov 2025 01:25:47 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v2]
In-Reply-To: <FH5cbkbvXi_pEG3RgbB4WwPT-XfDXOp8zuPaxUcUJbY=.d58c4d74-dfd8-4ec3-b35c-2cb96007eaeb@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <zdjWZhoaEsYVhdhVR0TA1IEMYfWU45sY1bwr9lUiIt0=.1b275b3b-b543-44ca-93c6-81e229ff7cfe@github.com>
 <FH5cbkbvXi_pEG3RgbB4WwPT-XfDXOp8zuPaxUcUJbY=.d58c4d74-dfd8-4ec3-b35c-2cb96007eaeb@github.com>
Message-ID: <hX413VrF__zK2z_Hw7ie3aURk5brivdo9S0hBoBUSak=.9280d833-c0d5-43a7-ac46-a4ae21ec1353@github.com>

On Thu, 20 Nov 2025 01:13:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update for Linux PPC64 and RISC-V
>
> It's passing now.

@plummercj Thanks a lot! I pushed the change to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3555318145

From sspitsyn at openjdk.org  Thu Nov 20 02:31:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 02:31:46 GMT
Subject: RFR: 6960970: Debugger very slow during stepping
Message-ID: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>

This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.

This fix is to avoid enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
The other details will be provided in the first PR request comment.
It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).

Testing:
 - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
 - submitted mach5 tiers 1-6

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

Commit messages:
 - 6960970: Debugger very slow during stepping

Changes: https://git.openjdk.org/jdk/pull/28407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6960970
  Stats: 282 lines in 21 files changed: 200 ins; 57 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

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

From sspitsyn at openjdk.org  Thu Nov 20 04:45:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 04:45:24 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v2]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  cleanup: removed an old code fragment in frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/d31aefb6..b3cffe5a

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

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

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

From sspitsyn at openjdk.org  Thu Nov 20 04:53:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 04:53:52 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v2]
In-Reply-To: <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>
Message-ID: <wwBl8xUKr7_78f_P0xtGSfchZcR63AC8i2ecJd0aa10=.f8ecc4e9-c8fb-4ba5-8ede-e06c929e06cf@github.com>

On Thu, 20 Nov 2025 04:45:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
>> 
>> This fix is to avoid enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
>> The other details will be provided in the first PR request comment.
>> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
>> 
>> Testing:
>>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>>  - submitted mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup: removed an old code fragment in frame.cpp

Change details:
 - platform-dependent `interp_masm*.cpp` and `zero/bytecodeInterpreter.cpp`:
    removed `interp-only` mode check before call to `InterpreterRuntime::post_method_exit()`
 - `interpreterRuntime.cpp`: disallow OSR for frames marked for `FramePop` event notification
 - `jvmtiEnvBase.cpp`:
   - added frame deoptimization logic to JVMTI `NotifyFramePop` implementation
   - added `check_and_clear_vthread_pending_deopts()` calls to JVMTI `ClearAllFramePops` implementation
 - `jvmtiEnvThreadState.cpp`: removed undesired check `!jvmti_thread_state()->is_interp_only_mode()` from `JvmtiEnvThreadState::is_frame_pop()` function
 - `jvmtiEventController.cpp`:
    - `JvmtiEventControllerPrivate::recompute_thread_enabled()`: removed `ets->has_frame_pops()` check when the `interp-only` node is enabled
 - `jvmtiExport.?pp`: 
   - introduced new function `has_frame_pop_for_top_frame()` used to disallow `OSR` for target frame
   - `JvmtiExport::post_method_exit()`: replaced `state->is_interp_only_mode()` check with `current_frame.is_interpreted_frame()`
 - `jvmtiThreadState.?pp`:
   - implementation of `process_vthread_pending_deopts()`logics
   - `JvmtiThreadState::process_pending_interp_only()`: added `MutexLocker mu(JvmtiThreadState_lock)`
   - `JvmtiThreadState::update_for_pop_top_frame()`: removed `is_interp_only_mode()` check
 - `frame.cpp`:
    - fix provided by Patricio (Thank you!): an assert specific to continuation heap frames is fixed
 - `serviceability/jvmti/events/NotifyFramePopStressTest`: minor tweak to help with debugging
 - `serviceability/jvmti/vthread/ThreadStateTest`: added code to provide extra test coverage from JVMTI `FramePop` events

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

PR Comment: https://git.openjdk.org/jdk/pull/28407#issuecomment-3555778224

From dholmes at openjdk.org  Thu Nov 20 05:42:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 05:42:02 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

@lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:

wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor

whereas the new code, if we kept the placement of the event,  would do

wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor

and what the proposed code actually does is

wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 


Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3555943800

From sspitsyn at openjdk.org  Thu Nov 20 07:58:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 07:58:01 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v2]
In-Reply-To: <eABh9Vl7Kz1AfvXBt2GSuNdavNd7E-bU8LG0yD59m2o=.bb5441d8-a8bb-4aa7-9c74-c145e57df55e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <eABh9Vl7Kz1AfvXBt2GSuNdavNd7E-bU8LG0yD59m2o=.bb5441d8-a8bb-4aa7-9c74-c145e57df55e@github.com>
Message-ID: <-AtmLhh2MCQH75PIec18-BOItl1VubNNIMlaYKUGH0g=.d8dc72ff-663f-4023-876a-fd921d7972b0@github.com>

On Tue, 18 Nov 2025 21:51:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment typo

Looks good. Posted one nit suggestion though.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 610:

> 608:         !node->popFrameProceed &&
> 609:         !node->popFrameThread &&
> 610:         node->pendingStop == NULL)

It is tricky to verify this list of checks is complete. :)

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28211#pullrequestreview-3486187361
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2544741007

From sspitsyn at openjdk.org  Thu Nov 20 07:58:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 07:58:01 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v2]
In-Reply-To: <7gBK0x7oqxFNv50kwhyx9kbGZQD6hMxsawxRJY7-h0A=.8ff3fe4c-ebc4-49be-b2dc-3c3ea63bd027@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <bwVEgFzsixp0pyRMj-IhDCJvuXyNBvOXYsP0JvUnxJg=.6576a827-1e11-4533-8b6f-91340ae054e6@github.com>
 <7gBK0x7oqxFNv50kwhyx9kbGZQD6hMxsawxRJY7-h0A=.8ff3fe4c-ebc4-49be-b2dc-3c3ea63bd027@github.com>
Message-ID: <7Ccv6kwEBezTRevXJqOzFSECANVxMlW8kTv5xt3xkPA=.eae80baa-beaf-4769-b235-4e83e8a327c3@github.com>

On Tue, 18 Nov 2025 04:59:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1399:
>> 
>>> 1397:     if (node == NULL) {
>>> 1398:         node = findThread(&otherThreads, thread);
>>> 1399:     }
>> 
>> Q: Could you explain a little bit why this change is needed? Do we need an update of the comment above?
>
> You need to call findRunningThread() to get the ThreadNode created if there isn't already one. findThread() does not create the ThreadNode like findRunningThread() does, so after my changes to free up ThreadNodes, findThread() was returning NULL, which causes a lot of problems here.
> 
> You then need to add the findThread(&otherThreads, thread) call because this is normally done by findThread() but is purposefully not done by findRunningThread(). otherThreads hold threads that have been created but not yet started. It's kind of rare that threads every end up on the list. It means the debugger somehow got hold of a ThreadReferences (such as through a local var) and then called a ThreadReference API with it. The usual way it works is when an event finally comes in on the thread, that is when it gets moved from otherThreads to runningThreads or runningVThreads.

Okay, thanks! It would be nice to add a short comment with a couple of sentences to explain this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2544734427

From jsjolen at openjdk.org  Thu Nov 20 08:36:02 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 20 Nov 2025 08:36:02 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v18]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>

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

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

  IDE doesn't help you with VM structs!

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/3686fc34..b6fe0bd7

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

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

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

From aph at openjdk.org  Thu Nov 20 09:44:45 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 20 Nov 2025 09:44:45 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <wsndSoLL6U9kdITvuzFLmbrpg8G9Ix3qHGVgeszdAfQ=.441e39fc-edc0-4aa5-b5c6-21813ae30270@github.com>

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem. Maybe if we only do this on non-PRODUCT builds it's be OK, but it would require very careful thought and analysis.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3556915717

From aartemov at openjdk.org  Thu Nov 20 09:54:31 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:31 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v14]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <INXjf-VAnwQeVCl0B2--wxt0OI5RJwyPjfw8WMpaFZ4=.c6c23007-7f8d-43a1-b503-3e64c41d7400@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8366659: Fixed tests.
 - 8366659: Fixed tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/08b481cd..5fe2d506

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

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

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

From aartemov at openjdk.org  Thu Nov 20 09:54:34 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:34 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <LCH0r3k_oYZ9aUaicYi0jQfLaZYOvNksUrqQsLPsxtE=.dfa50e6c-ca84-4bb0-a416-5adab07c98e0@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

I think this comment was supposed to be addressed to @sspitsyn

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWaitWorker.java line 42:
> 
>> 40: 
>> 41:     public void run() {
>> 42:         SuspendWithObjectMonitorWait1.logDebug("thread running");
> 
> SuspendWithObjectMonitorWaitBase instead of SuspendWithObjectMonitorWait1 here.
> There are a lot such places in this file.

Thanks for spotting this! Yes, `SuspendWithObjectMonitorWaitWorker` used to live in the same file as the original test and I forgot to update the names. Fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3556945962
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545160721

From aartemov at openjdk.org  Thu Nov 20 09:54:38 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>
Message-ID: <SBoR1d7YHImoV_tfUkVnfW2IXrtOP-_4VYluLTGO0n4=.33977b00-fcf7-4414-a3e5-2f566675f156@github.com>

On Wed, 19 Nov 2025 17:50:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 141:
> 
>> 139: 
>> 140: 
>> 141: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait2.java line 156:
> 
>> 154: 
>> 155: 
>> 156: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait3.java line 166:
> 
>> 164: 
>> 165: 
>> 166: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178592
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178219
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178072

From aartemov at openjdk.org  Thu Nov 20 10:42:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 10:42:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v15]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <uzaJTic7kpw0Aad1jvQZRPRC3R5qtoX_Zx87zhtmtfc=.d032a489-16e3-4182-b59c-d1e0c0596fc0@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed tests.
 - 8366659: Fixed tests.
 - 8366659: Refactored tests.
 - 8366659: Added bool arg to notify_contended_enter
 - 8366659: Refactored the big test into 3 smaller tests.
 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 21 more: https://git.openjdk.org/jdk/compare/ad38a125...9356cd9f

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=14
  Stats: 1238 lines in 9 files changed: 803 ins; 415 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From mbaesken at openjdk.org  Thu Nov 20 14:39:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 14:39:57 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <wsndSoLL6U9kdITvuzFLmbrpg8G9Ix3qHGVgeszdAfQ=.441e39fc-edc0-4aa5-b5c6-21813ae30270@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <wsndSoLL6U9kdITvuzFLmbrpg8G9Ix3qHGVgeszdAfQ=.441e39fc-edc0-4aa5-b5c6-21813ae30270@github.com>
Message-ID: <FtL2dkbKQJJpzqvMSlMY6jAtYJ_-OoKJWyFjIvxgBlg=.eacb786b-c2ae-4d03-86f7-8169fe0e99bd@github.com>

On Thu, 20 Nov 2025 09:42:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem

Thanks for looking into it.  I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558388446

From mbaesken at openjdk.org  Thu Nov 20 14:42:28 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 14:42:28 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <bgHvkTns9B2rmngEQgH3jkUWmPweyLABz7Ztcb50mI0=.85f750bd-1f56-4f4f-9e17-1b80804d2bba@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <bgHvkTns9B2rmngEQgH3jkUWmPweyLABz7Ztcb50mI0=.85f750bd-1f56-4f4f-9e17-1b80804d2bba@github.com>
Message-ID: <YJ7WDW_LUZ52UYLjrotmhbly2BUVBgfNPAUNsrdVMfk=.7e37b258-f3c8-4253-92f7-559bfa4279d2@github.com>

On Wed, 19 Nov 2025 18:53:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This seems to work:
> 
> ```
> extern void* _ZTV8Metadata[];
> 
> __attribute__((used))
>  void* foo() {
>   return _ZTV8Metadata[0];
> }
> ```
> 
> You can put this anywhere since it does not reference any hotspot types. It just needs to be linked in with libjvm. Note I tried putting the "used" attribute on _ZTV8Metadata and getting rid of the foo() part, but I got the following warning and the vtable was dead stripped:
> 
> `warning: 'used' attribute ignored on a non-definition declaration [-Wignored-attributes]`


Thanks for the testing and providing the workaround.  Too bad   that the 'retain' and 'used' are only function attributes, this makes things a bit harder.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558408585

From mbaesken at openjdk.org  Thu Nov 20 14:57:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 14:57:12 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v2]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <P2Ni93rAEQU2b0tEC9yRU4yzcHKhfydc-7eDg5JwuvM=.3997c249-5247-4eff-a5a1-8411c748435e@github.com>

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

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

  _ZTV8Metadata should not be eliminated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/1c5a43f4..07251ffe

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

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

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

From aartemov at openjdk.org  Thu Nov 20 15:17:28 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:17:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v16]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <nivfjqo4sMH29N_I4lddu1-ucNl9Z5BZPE50w3-A4Nk=.a772b055-25c5-4df5-a0bd-5fe93f48732f@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/9356cd9f..301999cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=14-15

  Stats: 74 lines in 6 files changed: 41 ins; 28 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Thu Nov 20 15:31:10 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:31:10 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

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

  8366659: Fixed whitespace error.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/301999cb..322fc0e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=15-16

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

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

From aartemov at openjdk.org  Thu Nov 20 15:31:11 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:31:11 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
 <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
Message-ID: <_-5I-bhvp2aJb6ki9uBaAjYYRBi6EKQVrD4QQHj4Mv4=.8f3da38f-5397-4c86-ad1d-c9bd65b677ed@github.com>

On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:
> 
> ```
> wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor
> ```
> 
> whereas the new code, if we kept the placement of the event, would do
> 
> ```
> wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor
> ```
> 
> and what the proposed code actually does is
> 
> ```
> wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 
> ```
> 
> Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

@dholmes-ora I have done a bit of refactoring and introduced a private method `post_waited_event()`, which we can call in different places depending on the scenario. 

For instance, for the timed-out case, the sequence of events is now unchanged, i.e.:
`wait -> waited -> contended enter -> contended entered`

For notified case, using your extended notation, it is now behaving like this: 
`wait  -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor`

I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits? 
The JVMTI tests pass, the extended testing is in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3558649501

From aph at openjdk.org  Thu Nov 20 15:54:55 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 20 Nov 2025 15:54:55 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <FtL2dkbKQJJpzqvMSlMY6jAtYJ_-OoKJWyFjIvxgBlg=.eacb786b-c2ae-4d03-86f7-8169fe0e99bd@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <wsndSoLL6U9kdITvuzFLmbrpg8G9Ix3qHGVgeszdAfQ=.441e39fc-edc0-4aa5-b5c6-21813ae30270@github.com>
 <FtL2dkbKQJJpzqvMSlMY6jAtYJ_-OoKJWyFjIvxgBlg=.eacb786b-c2ae-4d03-86f7-8169fe0e99bd@github.com>
Message-ID: <kl0mOXkq7SJxMSRf-Kf4HleQzrTFihNDUCUZNNOCi-E=.951dfd28-e2e7-480c-84cd-3dd5ef1abc3b@github.com>

On Thu, 20 Nov 2025 14:36:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem
> 
> Thanks for looking into it. I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers.

Right, but we'll need to make sure we don't remove the non-debug ones. We don't want to exclude stuff in `src/hotspot/share/utilities/debug.cpp` or explicit helpers in the back ends.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558785722

From mbaesken at openjdk.org  Thu Nov 20 16:00:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 16:00:30 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v3]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <qddvIyTbFGbtBHee3IdnLf7bVbB7CDkzlBSYzysKC-s=.68aa94c1-db8e-4663-b1a2-8f909d1f899d@github.com>

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

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

  Fix Windows issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/07251ffe..b41966b8

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

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

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

From macarte at openjdk.org  Thu Nov 20 16:00:52 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:00:52 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v4]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <mnL_C62m-qyvqY_juhpr4DJxNPemgkamteRqXuNViQk=.7f45acbb-10c5-4c6b-a1d4-6beadb977ec9@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8370203
 - Updates based on feedback.  Method name changes; clearer output; commnets on implemenation; remove redundant logic
 - Document use of DiagnosticCommand
 - Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording
 - Switched line endings to unix style LF
 - Removed timing functionality as it's not needed yet
 - Sort headers correctly
 - 8370203 - Adding JCmd AOT.end_recording

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

Changes: https://git.openjdk.org/jdk/pull/27965/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=03
  Stats: 288 lines in 6 files changed: 288 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

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

From macarte at openjdk.org  Thu Nov 20 16:22:29 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:22:29 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
 - Corrected placement of assert and logic test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/0ac132b6..f1f5d77d

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

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

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

From mbaesken at openjdk.org  Thu Nov 20 16:31:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 16:31:25 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v3]
In-Reply-To: <qddvIyTbFGbtBHee3IdnLf7bVbB7CDkzlBSYzysKC-s=.68aa94c1-db8e-4663-b1a2-8f909d1f899d@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <qddvIyTbFGbtBHee3IdnLf7bVbB7CDkzlBSYzysKC-s=.68aa94c1-db8e-4663-b1a2-8f909d1f899d@github.com>
Message-ID: <upzjbDV-aYNDr_OCgt0pYGz533qNmdWLCCC4WyLq-v0=.95dbee35-9613-4cce-a871-57a35e2b1d74@github.com>

On Thu, 20 Nov 2025 16:00:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Windows issues

Interestingly,  we seem to rely already on the 'used' attribute in the OpenJDK codebase at some places, see
https://github.com/search?q=repo%3Aopenjdk%2Fjdk%20ATTRIBUTE_USED&type=code

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558965415

From macarte at openjdk.org  Thu Nov 20 16:33:41 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:33:41 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>
Message-ID: <RZvDQjuYHIsu83R9vRb1g1huEIqslNi-OrQec2RdfZY=.ce651849-5ff9-465b-8fe5-99f193546f4f@github.com>

On Fri, 14 Nov 2025 12:58:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 991:
> 
>> 989: }
>> 990: 
>> 991: #if INCLUDE_CDS
> 
> A simple style nit-pick:  Error!
> The JVM doesn't really dramatize problems like that.  It tells you there was an error, and calmly describes the problem after a colon. "Error: " 8-)
> 
> (There are some "Error!" exclamations in java.xml and one has got into jdk.jfr, but they are unusual.)
> 
> You can tell me that nit-picking is NOT hyphenated if you like.

Thank you, we've removed the "!" from "Error: Failed to end recording" and also removed the "Error! " prefix from the other outputs that weren't internal errors

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2546768475

From mbaesken at openjdk.org  Thu Nov 20 16:44:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 16:44:08 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v3]
In-Reply-To: <qddvIyTbFGbtBHee3IdnLf7bVbB7CDkzlBSYzysKC-s=.68aa94c1-db8e-4663-b1a2-8f909d1f899d@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <qddvIyTbFGbtBHee3IdnLf7bVbB7CDkzlBSYzysKC-s=.68aa94c1-db8e-4663-b1a2-8f909d1f899d@github.com>
Message-ID: <YJiyYyslo1olznjLdgCYw9y2mG9n1AMOTgImNRnzVRE=.ba15bf3a-8f14-4577-8264-8d7b7d2bf6e3@github.com>

On Thu, 20 Nov 2025 16:00:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Windows issues

For the Apple linker there seem to be also a way to mark some sections with `S_ATTR_NO_DEAD_STRIP` to avoid the dead strip operation
https://maskray.me/blog/2021-02-28-linker-garbage-collection
'Sections with the S_ATTR_NO_DEAD_STRIP flag'
But I am not sure how to do this in the HS code directly.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3559017189

From cjplummer at openjdk.org  Thu Nov 20 17:23:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Nov 2025 17:23:47 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <kl0mOXkq7SJxMSRf-Kf4HleQzrTFihNDUCUZNNOCi-E=.951dfd28-e2e7-480c-84cd-3dd5ef1abc3b@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <wsndSoLL6U9kdITvuzFLmbrpg8G9Ix3qHGVgeszdAfQ=.441e39fc-edc0-4aa5-b5c6-21813ae30270@github.com>
 <FtL2dkbKQJJpzqvMSlMY6jAtYJ_-OoKJWyFjIvxgBlg=.eacb786b-c2ae-4d03-86f7-8169fe0e99bd@github.com>
 <kl0mOXkq7SJxMSRf-Kf4HleQzrTFihNDUCUZNNOCi-E=.951dfd28-e2e7-480c-84cd-3dd5ef1abc3b@github.com>
Message-ID: <giem4IptKx9HrDHh9ghIbtm1bi6dXTpovXn9Rn6tf-Y=.328dd2aa-d3c2-405c-a6a5-32e9596f6643@github.com>

On Thu, 20 Nov 2025 15:51:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem
> > 
> > 
> > Thanks for looking into it. I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers.
> 
> Right, but we'll need to make sure we don't remove the non-debug ones. We don't want to exclude stuff in `src/hotspot/share/utilities/debug.cpp` or explicit helpers in the back ends.

Most of the debug.cpp helpers are in product builds now. I think only pns() and pns2() are left out of product builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3559202033

From kvn at openjdk.org  Thu Nov 20 19:49:03 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 19:49:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Looks like you merged your other Mbeans PR changes into this. Which is wrong.

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

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3559758757

From cjplummer at openjdk.org  Thu Nov 20 20:00:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Nov 2025 20:00:14 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v2]
In-Reply-To: <-AtmLhh2MCQH75PIec18-BOItl1VubNNIMlaYKUGH0g=.d8dc72ff-663f-4023-876a-fd921d7972b0@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <eABh9Vl7Kz1AfvXBt2GSuNdavNd7E-bU8LG0yD59m2o=.bb5441d8-a8bb-4aa7-9c74-c145e57df55e@github.com>
 <-AtmLhh2MCQH75PIec18-BOItl1VubNNIMlaYKUGH0g=.d8dc72ff-663f-4023-876a-fd921d7972b0@github.com>
Message-ID: <6h_-TMFn8OgiAKud9ON7bt1HxJa3TtG7ml0xe0qa_Tc=.c24b5511-417c-48e8-bb47-98bc8780fef7@github.com>

On Thu, 20 Nov 2025 07:55:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It is tricky to verify this list of checks is complete. :)

Yes. I did an audit of all the fields. Combined with the testing, I'm pretty certain this is accurate. Eventually I'll be calling this code from more places to be even more aggressive about disposing of ThreadNodes, so that will also help uncover bugs here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2547495170

From cjplummer at openjdk.org  Thu Nov 20 20:12:11 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Nov 2025 20:12:11 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v3]
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <kDTgg2TFC51Cp_74uzT0iD224QBzV-fPqHz_JKeWEqs=.fe153493-ffd1-4337-8433-d550cf699320@github.com>

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  improve comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28211/files
  - new: https://git.openjdk.org/jdk/pull/28211/files/49a358c5..8d397580

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

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

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

From cjplummer at openjdk.org  Thu Nov 20 20:22:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Nov 2025 20:22:06 GMT
Subject: RFR: 8372294: Fix Malformed problem list entry in
 ProblemList-jvmti-stress-agent.txt
Message-ID: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>

ProblemList-jvmti-stress-agent.txt fails to pass verification because it uses a tab character instead of spaces. 

I'd like to push this as a trivial change.

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

Commit messages:
 - get rid of tab char

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

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

From pchilanomate at openjdk.org  Thu Nov 20 20:52:05 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 20:52:05 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent [v3]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable tra
 nsitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and unm...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Add Alan's comment in VirtualThread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/976486cd..205ae77b

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

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

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

From pchilanomate at openjdk.org  Thu Nov 20 20:55:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 20:55:22 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent [v3]
In-Reply-To: <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
Message-ID: <XMpFntsspG7i3aQgWep4IOSHTNgDqXFQY-b4AUv6EZk=.44ee0e11-718f-4434-855c-9fd27fe5f0a8@github.com>

On Wed, 19 Nov 2025 19:03:13 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 1390:
>> 
>>> 1388:     }
>>> 1389: 
>>> 1390:     // -- JVM TI support --
>> 
>> We'll need to update is comment as it no longer only for JVMTI. 
>> 
>> This might be a good place for a block comment to define "transitions" covering the changing of thread identity the continuation mount/unmount, and how the notification to the VM support JVMTI and handshakes.  Maybe I could contribute a block comment to include here?
>
> That would be great.

Thanks, added the suggested comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547640337

From macarte at openjdk.org  Thu Nov 20 22:11:20 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 22:11:20 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>
Message-ID: <yV7NUI80tWOtl07DxWy3DFWw5_GKDrP3rFK-TGE0_VI=.2b637405-3e31-497c-b428-6a727bfbf765@github.com>

On Thu, 20 Nov 2025 19:45:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks like you merged your other Mbeans PR changes into this. Which is wrong.

I resolved a conflict with Ioi's change from yesterday, but I don't see any HotSpotAOTCacheMXBean code.  Is there a specific commit you can reference?

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

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560266811

From dholmes at openjdk.org  Thu Nov 20 22:16:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 22:16:18 GMT
Subject: RFR: 8364343: ThreadSnapshotFactory::get_thread_snapshot() crashes
 without JVMTI agent [v3]
In-Reply-To: <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
Message-ID: <I-tloDi3H3515ePFvI-Wrs5AQwsSUdJQUAxUq1xouOA=.db99feda-f2b9-4962-a6c2-8c5edc44f35f@github.com>

On Thu, 20 Nov 2025 20:52:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Alan's comment in VirtualThread

As this involves a fairly significant design change I suggest updating the JBS issue to have a more informative title e.g. "Virtual Thread transition management needs to be independent of JVM TI"

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3560304232

From pchilanomate at openjdk.org  Thu Nov 20 23:10:48 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:48 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Rename VM methods for endFirstTransition/startFinalTransition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/205ae77b..10534b33

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

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

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

From pchilanomate at openjdk.org  Thu Nov 20 23:10:49 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <I-tloDi3H3515ePFvI-Wrs5AQwsSUdJQUAxUq1xouOA=.db99feda-f2b9-4962-a6c2-8c5edc44f35f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <I-tloDi3H3515ePFvI-Wrs5AQwsSUdJQUAxUq1xouOA=.db99feda-f2b9-4962-a6c2-8c5edc44f35f@github.com>
Message-ID: <l5hBFuBxBDeO5N6tWBQxpFFv_EcxpQivfgd5r94ubbE=.c7f42723-4c4c-48e2-8ced-8595188954f7@github.com>

On Thu, 20 Nov 2025 22:14:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As this involves a fairly significant design change I suggest updating the JBS issue to have a more informative title e.g. "Virtual Thread transition management needs to be independent of JVM TI"
>
Yes, that's better. Updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3560533185

From pchilanomate at openjdk.org  Thu Nov 20 23:10:52 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Nov 2025 23:10:52 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <FPqDAUXw_1ZtwQLFHIgv1HAANXJn4kCHtofPMhG_gmw=.c05ba258-723f-4abc-b35a-ca29f02a4df5@github.com>
 <jFNO_Y3Ag0QIDP4INNnPUNDYjcoGHFZ83C3mebo7o9U=.dc183f1f-5f99-479f-832c-8af9c4fcf72a@github.com>
Message-ID: <nW9xOi2sq3K_3ZpNyvvgzUf2p0roZU8hkKxcEtvK1nI=.03abf855-5f7b-4055-972c-8cff69df3816@github.com>

On Wed, 19 Nov 2025 19:01:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/native/libjava/VirtualThread.c line 38:
>> 
>>> 36:     { "startFinalTransition",     "()V",  (void *)&JVM_VirtualThreadEnd },
>>> 37:     { "startTransition",          "(Z)V", (void *)&JVM_VirtualThreadStartTransition },
>>> 38:     { "endTransition",            "(Z)V", (void *)&JVM_VirtualThreadEndTransition },
>> 
>> I wonder if JVM_VirtualThreadStart and JVM_VirtualThreadEnd should be renamed to have EndFirstTransition and StartFinalTransaction in the names so it's easy to follow through from the Java code down to MountUnmountDisabler::start_transition/end_transition.
>
> How about removing these methods and just have an extra boolean parameter in `start/endTransition`?
> https://github.com/pchilano/jdk/compare/JDK-8364343...pchilano:jdk:startEndTransitionsOnly

I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547987864

From sspitsyn at openjdk.org  Thu Nov 20 23:12:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 23:12:18 GMT
Subject: RFR: 8372294: Fix Malformed problem list entry in
 ProblemList-jvmti-stress-agent.txt
In-Reply-To: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
References: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
Message-ID: <CWGqsS2UfFEKrYRR5loAQVE_USaeYuXVFLm1NRFQ5C8=.d272551e-91a8-4d2e-a74b-2416d2fdf7a7@github.com>

On Thu, 20 Nov 2025 20:14:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ProblemList-jvmti-stress-agent.txt fails to pass verification because it uses a tab character instead of spaces. 
> 
> I'd like to push this as a trivial change.

Good and trivial.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28441#pullrequestreview-3490456587

From sspitsyn at openjdk.org  Thu Nov 20 23:17:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 23:17:36 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v3]
In-Reply-To: <kDTgg2TFC51Cp_74uzT0iD224QBzV-fPqHz_JKeWEqs=.fe153493-ffd1-4337-8433-d550cf699320@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <kDTgg2TFC51Cp_74uzT0iD224QBzV-fPqHz_JKeWEqs=.fe153493-ffd1-4337-8433-d550cf699320@github.com>
Message-ID: <SPDPya6IGK-R80BAxlYT7vn79Gy61NMnnLsPtmM86tw=.81f30f63-9a18-4bf3-92f4-fc22d4796900@github.com>

On Thu, 20 Nov 2025 20:12:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

Still looks good. Thank you for updating comments.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28211#pullrequestreview-3490477704

From kvn at openjdk.org  Thu Nov 20 23:31:19 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 23:31:19 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <YfWWCMGrAgCIqNfAaSsesVDCDjzUV3BOhXRlbCoaKWc=.6f89804a-208d-4a17-8e89-39aac7642597@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

I was confused by this Github warning "This pull request contains merges that bring in commits not present in the target repository. "

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

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560622271

From vlivanov at openjdk.org  Thu Nov 20 23:36:43 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 20 Nov 2025 23:36:43 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v3]
In-Reply-To: <KhHcTXHg33ph1n7IYvbH8t1PnKdiwv21ukgLys6kZrk=.28f59b50-2746-4c00-9c56-68f9d6215fa4@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <KhHcTXHg33ph1n7IYvbH8t1PnKdiwv21ukgLys6kZrk=.28f59b50-2746-4c00-9c56-68f9d6215fa4@github.com>
Message-ID: <_C1_-yzeixcKbR2NfmnM4MEl3InsR6cTTzmoT-vMSBY=.032aae46-e951-4c76-91e6-fc7a8fe8b73c@github.com>

On Wed, 19 Nov 2025 12:34:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert a couple more InstanceKlass::casts also to get GHA to restart.

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

> 1727:       if (flat->offset() == in_bytes(Klass::super_check_offset_offset()))
> 1728:         alias_type(idx)->set_rewritable(false);
> 1729:       if (flat->isa_instklassptr() && flat->offset() == in_bytes(InstanceKlass::access_flags_offset()))

I'd place the check separately. Otherwise, looks good. 

diff --git a/src/hotspot/share/opto/compile.cpp b/src/hotspot/share/opto/compile.cpp
index 6babc13e1b3..9215c0fc03f 100644
--- a/src/hotspot/share/opto/compile.cpp
+++ b/src/hotspot/share/opto/compile.cpp
@@ -1726,8 +1726,6 @@ Compile::AliasType* Compile::find_alias_type(const TypePtr* adr_type, bool no_cr
       }
       if (flat->offset() == in_bytes(Klass::super_check_offset_offset()))
         alias_type(idx)->set_rewritable(false);
-      if (flat->offset() == in_bytes(Klass::access_flags_offset()))
-        alias_type(idx)->set_rewritable(false);
       if (flat->offset() == in_bytes(Klass::misc_flags_offset()))
         alias_type(idx)->set_rewritable(false);
       if (flat->offset() == in_bytes(Klass::java_mirror_offset()))
@@ -1735,6 +1733,11 @@ Compile::AliasType* Compile::find_alias_type(const TypePtr* adr_type, bool no_cr
       if (flat->offset() == in_bytes(Klass::secondary_super_cache_offset()))
         alias_type(idx)->set_rewritable(false);
     }
+    if (flat->isa_instklassptr()) {
+      if (flat->offset() == in_bytes(InstanceKlass::access_flags_offset())) {
+        alias_type(idx)->set_rewritable(false);
+      }
+    }
     // %%% (We would like to finalize JavaThread::threadObj_offset(),
     // but the base pointer type is not distinctive enough to identify
     // references into JavaThread.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2548046511

From kvn at openjdk.org  Thu Nov 20 23:43:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 23:43:58 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Looks good now.

`KAT9180` is not related to your changes. It is new test added today.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3490547075
PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560659510

From duke at openjdk.org  Thu Nov 20 23:56:48 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 20 Nov 2025 23:56:48 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v4]
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

  Refine `first_check_size` definitions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28192/files
  - new: https://git.openjdk.org/jdk/pull/28192/files/3a014376..00ea0e14

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

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

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

From sspitsyn at openjdk.org  Thu Nov 20 23:58:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 23:58:41 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
 <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
Message-ID: <IDJU9QFhmhYcFahIxD8FvcW9UZtVVOrAsFmBHe_HgGs=.115b6b32-cb21-4d51-84e3-ad1199181012@github.com>

On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Changes requested by lmesnik (Reviewer).
>
> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.
> 
> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:
> 
> wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor
> 
> whereas the new code, if we kept the placement of the event,  would do
> 
> wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor
> 
> and what the proposed code actually does is
> 
> wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 
> 
> 
> Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

@dholmes-ora David, thank you for your input!

> @dholmes-ora I have done a bit of refactoring and introduced a private method post_waited_event(), which we can call in different places depending on the scenario.

I like the refactoring.

> For instance, for the timed-out case, the sequence of events is now unchanged, i.e.:
> `wait -> waited -> contended enter -> contended entered`
> 
> For the notified case, using your extended notation, it is now behaving like this:
> `wait  -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor`

My understanding is that we need both timed-out and notified cases to do the same as David suggested above:
  `wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor`
It would give us two advantages:
 - timed-out and notified cases are unified
 - avoid incompatibility risk, e.g.:
   - no new combinations of JVMTI thread state bits are introduced
   - the object monitor events order is kept same as was before (is it true?)

Is there a problem to make it unified?

> I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits?

As I see, this still introduces new combinations of thread state bits for the notified case.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3560695036

From duke at openjdk.org  Fri Nov 21 00:02:37 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 21 Nov 2025 00:02:37 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <yRRZIhvHvqoMZXM_eEKmHmAsCQ7ACGfNapyZYD8zv88=.139da312-e5c0-498b-88d1-462a36540356@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <-h6G9ajUWQwDRcUMOtyI_YCUCkXz3pzRggJk_UaxM-0=.a8c772aa-2f09-48c0-9cfb-17e624393eb0@github.com>
 <Us6SbX-VztiIbBdDMeEvzGAllBgnZSnzCb4B7zpkUrU=.133050a6-fd59-490e-94f3-96280909d6f0@github.com>
 <yRRZIhvHvqoMZXM_eEKmHmAsCQ7ACGfNapyZYD8zv88=.139da312-e5c0-498b-88d1-462a36540356@github.com>
Message-ID: <Km_fVDirXRR6r7Kubu_aPTcQKOg0f8eq-BNDDJNegY4=.48ec53c6-b2cb-45fe-a43a-32aaed07d992@github.com>

On Wed, 19 Nov 2025 04:28:04 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> However, I still have not identified a way to ensure the deopt handler stub ends at a page boundary in a unit test.
>> 
>> The latest update implements an alternative way to detect the failure early during testing - via the newly added assertion in the `emit_deopt_handler`.
>> 
>> @adinn, @dean-long, @TheRealMDoerr, would it be possible for you to review the latest version of the PR?
>> 
>> Is there any additional testing you would recommend to perform before this can be integrated?
>
>> Is there any additional testing you would recommend to perform before this can be integrated?
> 
> Oracle likes to make sure the final version passes in our CI.  I got burned last time testing an earlier version and not the final version.

Thank you for the reviews, @dean-long, @adinn, @TheRealMDoerr.
@dean-long, I've updated the patch according to your suggestions - also applied the same to other `nativeInst_*` files except `nativeInst_x86.hpp` as the instruction size is not fixed in this case.

> the final version passes in our CI

If this version of the patch looks suitable, would it be possible to start the CI testing please?

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3560702086

From sspitsyn at openjdk.org  Fri Nov 21 00:25:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 00:25:04 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <uoo3qc9UX9DOhJD8Lm_KhBdzbvywX1Cl-MMl4jKI688=.92f650ef-9a20-4667-a569-2bcf22b2ef3f@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern.

Yes, JVMTI event posting code performs thread state transitions. But I was talking about the JVMTI thread state bits specified here: https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

> That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself.

Right. We have this oddity.

> Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

Right. There have to be some ways to fix it. Most likely we already have a bug against this issue.


> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the monitor_waited event would be posted whilst the thread is still suspended.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3560750605

From kvn at openjdk.org  Fri Nov 21 00:50:23 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 21 Nov 2025 00:50:23 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>
Message-ID: <0sF4opLAcZ44ZcCa2Kj5pn88ytM7OasvOMHs3LDvwY8=.839b8cf8-c63d-40f1-a660-a938e0d919e0@github.com>

On Thu, 20 Nov 2025 23:40:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `KAT9180` is not related to your changes. It is new test added today.

I mean `KAT9180` test failure in GHA is not related to your changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560825050

From dholmes at openjdk.org  Fri Nov 21 01:00:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:00:58 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
Message-ID: <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

Hi Patricio, this is another significant piece of work. I have taken an initial pass through trying to digest the main parts - can't comment on the C2 code or the Java side. I have made a few minor comments/suggestions.

Thanks

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

> 3666:   if (!DoJVMTIVirtualThreadTransitions) {
> 3667:     assert(!JvmtiExport::can_support_virtual_threads(), "sanity check");
> 3668:     return;

Does this not still need checking somewhere?

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 162:

> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().

Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 277:

> 275: 
> 276:   // Start of the critical region. Prevent future memory
> 277:   // operations to be ordered before we read the transition flag.

Does this refer to `java_lang_Thread::is_in_VTMS_transition(_vthread())`? If so perhaps that should internally perform the `load_acquire`?

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 278:

> 276:   // Start of the critical region. Prevent future memory
> 277:   // operations to be ordered before we read the transition flag.
> 278:   // This matches the release fence in end_transition().

Suggestion:

  // This pairs with the release fence in end_transition().

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 307:

> 305:   // Block while some mount/unmount transitions are in progress.
> 306:   // Debug version fails and prints diagnostic information.
> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {

This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 316:

> 314:   // operations to be ordered before we read the transition flags.
> 315:   // This matches the release fence in end_transition().
> 316:   OrderAccess::acquire();

Surely the use of the iterator already provides the necessary ordering guarantee here as well. ?

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 327:

> 325:   // End of the critical section. Prevent previous memory operations to
> 326:   // be ordered after we clear the clear the disable transition flag.
> 327:   // This matches the equivalent acquire fence in start_transition().

Suggestion:

  // This pairs with the acquire in start_transition().

I just realized you are using "fence" to describe release and acquire memory barrier semantics. Given we have an operation `fence` I find this confusing for the reader - especially when we also have a `release_store_fence` operation which might be confused with "release fence".

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 370:

> 368:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
> 369:   assert(_global_start_transition_disable_count >= 0, "");
> 370:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count + 1);

Suggestion:

  AtomicAccess::inc(&_global_start_transition_disable_count);

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 376:

> 374:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
> 375:   assert(_global_start_transition_disable_count > 0, "");
> 376:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count - 1);

Suggestion:

  AtomicAccess::dec(&_global_start_transition_disable_count);

src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:

> 50:   // parameter is_SR: suspender or resumer
> 51:   MountUnmountDisabler(bool exlusive = false);
> 52:   MountUnmountDisabler(oop thread_oop);

What does the comment mean here?

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3490207826
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547887801
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548145054
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548157390
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548150552
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548160373
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548161340
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548168223
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548169846
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548170787
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548174392

From dholmes at openjdk.org  Fri Nov 21 01:01:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:01:00 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
Message-ID: <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>

On Thu, 20 Nov 2025 20:52:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Alan's comment in VirtualThread

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

> 1755:   jint* addr = java_thread->field_addr<jint>(_VTMS_transition_disable_count_offset);
> 1756:   int val = AtomicAccess::load(addr);
> 1757:   AtomicAccess::store(addr, val + 1);

Suggestion:

  AtomicAccess::inc(addr);

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

> 1762:   jint* addr = java_thread->field_addr<jint>(_VTMS_transition_disable_count_offset);
> 1763:   int val = AtomicAccess::load(addr);
> 1764:   AtomicAccess::store(addr, val - 1);

Suggestion:

  AtomicAccess::dec(addr);

src/hotspot/share/opto/runtime.hpp line 740:

> 738:     return vthread_transition_Type();
> 739:   }
> 740: 

I do not know C2 but this looks really strange - 4 different functions all return the same thing. ???

src/hotspot/share/runtime/handshake.cpp line 374:

> 372:     JavaThread* target = java_lang_Thread::thread(carrier_thread);
> 373:     assert(target != nullptr, "");
> 374:     // Technically there is need for a ThreadsListHandle since the target

Suggestion:

    // Technically there is no need for a ThreadsListHandle since the target

?

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 147:

> 145:       MonitorLocker ml(VTMSTransition_lock);
> 146:       while (is_start_transition_disabled(current, vth())) {
> 147:         ml.wait(200);

I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547864726
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547863852
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547884313
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547900707
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2547963241

From lmesnik at openjdk.org  Fri Nov 21 00:59:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 21 Nov 2025 00:59:52 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Changes requested by lmesnik (Reviewer).

src/hotspot/share/cds/aotMetaspace.cpp line 1062:

> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
> 1062:   return _preimage_static_archive_dumped == 1;

Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?

test/hotspot/jtreg/runtime/cds/appcds/aotCache/DiagnosticCommandMBeanTest.java line 98:

> 96:                     out.shouldContain("Failed to stop recording");
> 97:                 }
> 98:                 out.shouldNotContain("IOException occurred!");

The 'IOException occurred!' is never printed. While there are a lot of other exception print and not checked.

Also makes sense to check exit status.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:

> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
> 30:  * @library /test/lib
> 31:  * @build JcmdAOTEndRecordingTest

No need to build test explicitly, jtreg does it by itself.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:

> 55:             try {
> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
> 57:                 output.shouldContain("AOT.end_recording is unsupported");

A little bit confused.  The check doesn't match test description.

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

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3490649441
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548182449
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548168094
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548140140
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548148536

From dholmes at openjdk.org  Fri Nov 21 01:04:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:04:59 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
Message-ID: <vEnsjdOFfdLuJAFoYWB0zvxd2yLSdIRxAgHT7TRFqJw=.ad5f055e-1488-4def-b448-daf9a2e616c3@github.com>

On Fri, 21 Nov 2025 00:35:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 162:
> 
>> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
>> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
>> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().
> 
> Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?

I also forgot to suggest a wording change: say "pairs with" rather than "matches". Reading back through I realize now I have misunderstood many of these comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2548189421

From dholmes at openjdk.org  Fri Nov 21 01:26:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 01:26:21 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
Message-ID: <kKSy1-kPPOA0WfhdrgotdulXTT4CiBHkHrPdI5NioHQ=.2f8880e8-cf2b-466e-9753-bf48e3bb5655@github.com>

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

> we follow the classic Dekker pattern for the required synchronization. 

My understanding is that Dekker requires a "full fence" between the accesses, not just ordering memory barriers.  The two variables involved must be published to all readers for the algorithm to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3560918527

From amenkov at openjdk.org  Fri Nov 21 02:29:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 21 Nov 2025 02:29:26 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v3]
In-Reply-To: <kDTgg2TFC51Cp_74uzT0iD224QBzV-fPqHz_JKeWEqs=.fe153493-ffd1-4337-8433-d550cf699320@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <kDTgg2TFC51Cp_74uzT0iD224QBzV-fPqHz_JKeWEqs=.fe153493-ffd1-4337-8433-d550cf699320@github.com>
Message-ID: <b91gkgM0DQljjHvEcK-CS3pd6Wo1Vwk5s4kWlpjMMz8=.381e7235-5c24-4316-9ae5-0a116efa61de@github.com>

On Thu, 20 Nov 2025 20:12:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

Looks good to me.
Added some minor notes

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 582:

> 580:         /*
> 581:          * Although at first it might seem that a non-zero suspendCount would require
> 582:          * keeping the node, we don't have too if node->suspendCount == suspendAllCount,

Suggestion:

         * keeping the node, we don't have to if node->suspendCount == suspendAllCount,

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 592:

> 590:     }
> 591: 
> 592:     // All of the following conditions must pass if we are to free this node. Note

Suggestion:

    // All of the following conditions must be met to free this node. Note

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 628:

> 626: 
> 627:     ThreadList *list = &runningVThreads;
> 628:     ThreadNode *node = list->first;

Suggestion:

    ThreadNode *node = runningVThreads.first;

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

PR Review: https://git.openjdk.org/jdk/pull/28211#pullrequestreview-3490828800
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2548270211
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2548280293
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2548283759

From lmesnik at openjdk.org  Fri Nov 21 03:12:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 21 Nov 2025 03:12:45 GMT
Subject: RFR: 8372294: Fix Malformed problem list entry in
 ProblemList-jvmti-stress-agent.txt
In-Reply-To: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
References: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
Message-ID: <qhmvkifIgjqZkwrIQ8lRlQjf7WEMtZXPCav59iex7nU=.1c54c950-3d3a-489d-8a1f-9425e831558e@github.com>

On Thu, 20 Nov 2025 20:14:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ProblemList-jvmti-stress-agent.txt fails to pass verification because it uses a tab character instead of spaces. 
> 
> I'd like to push this as a trivial change.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28441#pullrequestreview-3491010790

From cjplummer at openjdk.org  Fri Nov 21 06:31:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Nov 2025 06:31:56 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v4]
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <KPKlFQfaYuOcKhjPMkOL6vLgbWAnIIRscSj8ctkiL-c=.cc6e537d-d9ea-4adc-9051-03435501643f@github.com>

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix comments. use runningVThreads.first

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28211/files
  - new: https://git.openjdk.org/jdk/pull/28211/files/8d397580..072e7720

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

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

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

From sspitsyn at openjdk.org  Fri Nov 21 07:29:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 07:29:44 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
Message-ID: <0Q_8lJFi3PoCAyh_JkV0qnTox-2Z8qajHHUQHUjyJ7k=.ede07dbf-498e-4ff4-981a-7cd636d1e9a8@github.com>

On Thu, 20 Nov 2025 15:31:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Fixed whitespace error.

I'm reading this bug description in JBS:

> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible in two cases:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and then exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.

I'm not sure the described scenarios above are real deadlocks. The debugger has to be careful with threads suspension and can behave differently. For instance, it can suspend all threads, so no thread can progress with entering OM's. We do not consider it to be a deadlock, right?
In a case just a single thread is being suspended by the debugger, other threads can depend on the suspended thread. But we do not consider it to be a deadlock. It is because everything should come to normal after the debugger resumes the suspended thread.
So, could you, please, explain a little bit more on the deadlocks above? How the described in the bug scenarios are different from just listed ones? Do I miss anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3561786718

From duke at openjdk.org  Fri Nov 21 07:46:22 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Fri, 21 Nov 2025 07:46:22 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v2]
In-Reply-To: <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>
Message-ID: <-6UQvhvzWxm9r6rtvS4EjiVn-to2xAa64MJi-9_-zss=.fe61f491-31d9-4e75-932a-8e9a9f6a45d1@github.com>

On Thu, 20 Nov 2025 04:45:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
>> 
>> This fix is to avoid enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
>> The other details will be provided in the first PR request comment.
>> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
>> 
>> Testing:
>>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>>  - submitted mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup: removed an old code fragment in frame.cpp

test/jdk/com/sun/jdi/EATests.java line 3068:

> 3066:         // frame[4]: EATestsTarget.main(java.lang.String[])
> 3067: 
> 3068:         env.stepOverLine(thread); // needed to keep target thread interp-only, so dontinline_brkpt_iret is not inligned

inligned => inlined

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r2548831869

From sspitsyn at openjdk.org  Fri Nov 21 08:00:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 08:00:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
Message-ID: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>

On Thu, 20 Nov 2025 15:31:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Fixed whitespace error.

I'm looking at the  two new tests scenarios. They look non-real and very artificial because the application plays a role of the debugger at the same time and constructs the artificial deadlocks. The threads sync on an application lock, one of them suspends and another resumes the target thread. These deadlocks are impossible to have with any normal debugger which is decoupled from application it is debugging.
Sorry for saying it but it feels like there is no sense to fix this artificial issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3561858635

From mbaesken at openjdk.org  Fri Nov 21 08:33:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 08:33:24 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <KWJNMVffhGrSQ_06bDieIjduVv93jn2GOzIPV8ROWdc=.fb4bce8a-41b5-4c4f-9b46-03d20c80f73f@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <nyDtm2Xmvgx9JjP5M6TKUsIJe_Mw3NW_Kta5zR-576Y=.d65500ff-7823-432f-8460-f09ca5dda703@github.com>
 <KWJNMVffhGrSQ_06bDieIjduVv93jn2GOzIPV8ROWdc=.fb4bce8a-41b5-4c4f-9b46-03d20c80f73f@github.com>
Message-ID: <woUEqbfMLLvDQqiq4BPt64I53SsTvKQPWfG4hClK8FU=.637b683c-8480-4c20-841f-df1f2b2ba997@github.com>

On Wed, 19 Nov 2025 13:05:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> As usual, maybe it is possible to split this patch between hotspot and the libraries?

Maybe we should for now limit the dead_strip  to the JDK native libs ?

This would avoid the trouble with the HS debug helpers coding and the  serviceability agent  (but in the long run we have this trouble also with linktime-gc and probably LTO which can be enabled by OpenJDK configure, not only with this macOS-linker related flag this PR is about ).

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3561953592

From aartemov at openjdk.org  Fri Nov 21 09:15:40 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 21 Nov 2025 09:15:40 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
Message-ID: <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>

On Fri, 21 Nov 2025 07:56:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Fixed whitespace error.
>
> I'm looking at the  two new tests scenarios. They look non-real and very artificial because the application plays a role of the debugger at the same time and constructs the artificial deadlocks. The threads sync on an application lock, one of them suspends and another resumes the target thread. These deadlocks are impossible to have with any normal debugger which is decoupled from application it is debugging.
> Sorry for saying it but it feels like there is no sense to fix this artificial issue.

Thanks @sspitsyn for diving into the issue. 

With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3562088599

From mdoerr at openjdk.org  Fri Nov 21 09:33:24 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Nov 2025 09:33:24 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v4]
In-Reply-To: <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
Message-ID: <zcgjrks49-Qj3Oyu7Fiha6XExaa5HKzi7-yNMLBcrmU=.e46300c7-448f-4510-bfc7-19af45b424a0@github.com>

On Thu, 20 Nov 2025 23:56:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine `first_check_size` definitions

Still good.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28192#pullrequestreview-3491889191

From alanb at openjdk.org  Fri Nov 21 11:35:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 11:35:57 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
Message-ID: <exRz3HQ-bV93DEgOuUZxw3NRkQlBtxK734A8jTw70i8=.9498a654-570a-4746-a751-f0bc3d58a688@github.com>

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove single whitespace

I went through the plumbing to check the registration with the platform MBeanServer and everything looks okay (and consistent with how the other JDK-specific management interfaces are setup and registered).

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 97:

> 95:    * successfully; {@code false} otherwise.
> 96:    */
> 97:    public boolean endRecording();

Minor nit is that we usually use 4-space rather than 2-space indent in the java sources. You might want to check the /** .. */ comments in a few of the files as they are misaligned in a few places.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3562626766
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549470742

From sspitsyn at openjdk.org  Fri Nov 21 11:42:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 11:42:24 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
Message-ID: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>

On Fri, 21 Nov 2025 09:11:52 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?

It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3562647847

From alanb at openjdk.org  Fri Nov 21 12:04:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Nov 2025 12:04:29 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
Message-ID: <ftPvHBlncWJz1yN6Gjclx4Z-QcgHijYUp2tJ1wQfP8Q=.ebd2ac22-0e3a-4f2f-83aa-4c753b6e806d@github.com>

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove single whitespace

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 31:

> 29:  * @requires vm.cds.write.archived.java.heap
> 30:  * @library /test/jdk/lib/testlibrary /test/lib
> 31:  *          /test/hotspot/jtreg/runtime/cds/appcds/aotCache/test-classes

Is test-classes used?

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 45:

> 43: import jdk.test.lib.process.OutputAnalyzer;
> 44: 
> 45: public class HotSpotAOTCacheMXBeanTest {

In addition to testing the endRecording operation, we also need to test both the direct and indirect access to the MXBean. The test currently obtains a proxy with newPlatformMXBeanProxy (good) but the direct access with ManagementFactory.getPlatformMXBean is not tested right now.

Another thing to test is that getObjectName returns the expected object name.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 92:

> 90:                 }
> 91:                 out.shouldNotContain("HotSpotAOTCacheMXBean is not available");
> 92:                 out.shouldNotContain("IOException occurred!");

Have you considering have the child terminate with an exception so the exit status is non-0. If you get a success status then the output should have the expected strings. A non-0 would failure, and the test fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549496991
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549513596
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2549518555

From coleenp at openjdk.org  Fri Nov 21 14:09:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Nov 2025 14:09:55 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v3]
In-Reply-To: <_C1_-yzeixcKbR2NfmnM4MEl3InsR6cTTzmoT-vMSBY=.032aae46-e951-4c76-91e6-fc7a8fe8b73c@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <KhHcTXHg33ph1n7IYvbH8t1PnKdiwv21ukgLys6kZrk=.28f59b50-2746-4c00-9c56-68f9d6215fa4@github.com>
 <_C1_-yzeixcKbR2NfmnM4MEl3InsR6cTTzmoT-vMSBY=.032aae46-e951-4c76-91e6-fc7a8fe8b73c@github.com>
Message-ID: <_1-urAH6nhGRC5fXZnBvC60QvUAA7KA3ekz5sRD9MpQ=.edd7e8df-5459-4b89-a02d-5da88ce76c59@github.com>

On Thu, 20 Nov 2025 23:33:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert a couple more InstanceKlass::casts also to get GHA to restart.
>
> src/hotspot/share/opto/compile.cpp line 1729:
> 
>> 1727:       if (flat->offset() == in_bytes(Klass::super_check_offset_offset()))
>> 1728:         alias_type(idx)->set_rewritable(false);
>> 1729:       if (flat->isa_instklassptr() && flat->offset() == in_bytes(InstanceKlass::access_flags_offset()))
> 
> I'd place the check separately. Otherwise, looks good. 
> 
> diff --git a/src/hotspot/share/opto/compile.cpp b/src/hotspot/share/opto/compile.cpp
> index 6babc13e1b3..9215c0fc03f 100644
> --- a/src/hotspot/share/opto/compile.cpp
> +++ b/src/hotspot/share/opto/compile.cpp
> @@ -1726,8 +1726,6 @@ Compile::AliasType* Compile::find_alias_type(const TypePtr* adr_type, bool no_cr
>        }
>        if (flat->offset() == in_bytes(Klass::super_check_offset_offset()))
>          alias_type(idx)->set_rewritable(false);
> -      if (flat->offset() == in_bytes(Klass::access_flags_offset()))
> -        alias_type(idx)->set_rewritable(false);
>        if (flat->offset() == in_bytes(Klass::misc_flags_offset()))
>          alias_type(idx)->set_rewritable(false);
>        if (flat->offset() == in_bytes(Klass::java_mirror_offset()))
> @@ -1735,6 +1733,11 @@ Compile::AliasType* Compile::find_alias_type(const TypePtr* adr_type, bool no_cr
>        if (flat->offset() == in_bytes(Klass::secondary_super_cache_offset()))
>          alias_type(idx)->set_rewritable(false);
>      }
> +    if (flat->isa_instklassptr()) {
> +      if (flat->offset() == in_bytes(InstanceKlass::access_flags_offset())) {
> +        alias_type(idx)->set_rewritable(false);
> +      }
> +    }
>      // %%% (We would like to finalize JavaThread::threadObj_offset(),
>      // but the base pointer type is not distinctive enough to identify
>      // references into JavaThread.)

Yes that looks better. There aren't enough {} in that bit of code but I won't add more to existing code.  Thanks for your help with the C2 code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2549873241

From coleenp at openjdk.org  Fri Nov 21 14:53:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Nov 2025 14:53:03 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v4]
In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
Message-ID: <inQ3KgQ96jowq9A3rgrxuEOVtwN2mHGl2QL0vOOHK7Y=.d89c6360-19b1-4df5-8069-a8873f0a6ec8@github.com>

> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
> Tested with tier1-4.  5-7 in progress.

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

  Reformatting compile.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28371/files
  - new: https://git.openjdk.org/jdk/pull/28371/files/1060463b..06d6a186

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

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

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

From cjplummer at openjdk.org  Fri Nov 21 17:32:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Nov 2025 17:32:56 GMT
Subject: Integrated: 8372294: Fix Malformed problem list entry in
 ProblemList-jvmti-stress-agent.txt
In-Reply-To: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
References: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
Message-ID: <Pmn6t3eKWGvsqGfdhSS-9v-dfUqQwM6X59Yb6ko08vI=.ede36bfa-328e-417e-bdb9-de6549fc20aa@github.com>

On Thu, 20 Nov 2025 20:14:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ProblemList-jvmti-stress-agent.txt fails to pass verification because it uses a tab character instead of spaces. 
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: e4b583ab
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4b583ab708eadd526d5cc0c03129a7970e05320
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8372294: Fix Malformed problem list entry in ProblemList-jvmti-stress-agent.txt

Reviewed-by: sspitsyn, lmesnik

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

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

From cjplummer at openjdk.org  Fri Nov 21 17:32:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Nov 2025 17:32:56 GMT
Subject: RFR: 8372294: Fix Malformed problem list entry in
 ProblemList-jvmti-stress-agent.txt
In-Reply-To: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
References: <4dv7jK8fdPgbRDz_3v2wqd9XmHTtpp0T4QSujRYNu6I=.e3f6bec2-f09c-4899-af29-222b06e072bf@github.com>
Message-ID: <bJoGrxyRtOrWTBsx6d7KNcsFD9tr6M5EFFRMiL1ncJQ=.97ad9cc1-ccd9-4128-bcb7-a691da4fd3ae@github.com>

On Thu, 20 Nov 2025 20:14:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ProblemList-jvmti-stress-agent.txt fails to pass verification because it uses a tab character instead of spaces. 
> 
> I'd like to push this as a trivial change.

Thank you for the reviews Serguei and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/28441#issuecomment-3563985673

From amenkov at openjdk.org  Fri Nov 21 18:12:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 21 Nov 2025 18:12:12 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v4]
In-Reply-To: <KPKlFQfaYuOcKhjPMkOL6vLgbWAnIIRscSj8ctkiL-c=.cc6e537d-d9ea-4adc-9051-03435501643f@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <KPKlFQfaYuOcKhjPMkOL6vLgbWAnIIRscSj8ctkiL-c=.cc6e537d-d9ea-4adc-9051-03435501643f@github.com>
Message-ID: <tBdt2B5Q_3a9D9q4BKcUix0MT5dIHbJk9Y8UE9fh5Xg=.a7adf9d8-cb9f-4f4e-9509-3ca267dffb25@github.com>

On Fri, 21 Nov 2025 06:31:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments. use runningVThreads.first

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28211#pullrequestreview-3493860094

From macarte at openjdk.org  Fri Nov 21 18:41:45 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:41:45 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <ncCCIGiscZD6YF01wG_oNV_0Er3hPqf0DkBs2jIL-ug=.74833746-6082-4ea2-92c4-1af51ced1f6c@github.com>

On Fri, 21 Nov 2025 00:37:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:
> 
>> 55:             try {
>> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
>> 57:                 output.shouldContain("AOT.end_recording is unsupported");
> 
> A little bit confused.  The check doesn't match test description.

This test uses Lingered apps (enabling the jcmd connection), however the test framework here doesn't support creating the AOT cache - so I simply check that the connection works and the diagnostic command returns the expected value when you aren't recording a cache

I'm trying to create an additional test that allows jcmd to end training on an AOT recording, but there's some issues merging the jcmd test support and the aot test support;  I will make it clearer in this test about this limitation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550648445

From cjplummer at openjdk.org  Fri Nov 21 18:46:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Nov 2025 18:46:36 GMT
Subject: RFR: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes [v4]
In-Reply-To: <KPKlFQfaYuOcKhjPMkOL6vLgbWAnIIRscSj8ctkiL-c=.cc6e537d-d9ea-4adc-9051-03435501643f@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
 <KPKlFQfaYuOcKhjPMkOL6vLgbWAnIIRscSj8ctkiL-c=.cc6e537d-d9ea-4adc-9051-03435501643f@github.com>
Message-ID: <pbJoIrFmMRuKzhiY1chL0vVv-SYNJISqcoxTL9ihhi4=.1bd2d67f-fc73-4bf9-8601-0a40e6a8684a@github.com>

On Fri, 21 Nov 2025 06:31:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
>> 
>> This PR focuses on purging virtual thread ThreadNodes in two places:
>> 
>> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
>> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
>> 
>> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
>> 
>> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
>> 
>> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
>> 
>> Tested by running all tier2, tier5, and tier6 CI svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments. use runningVThreads.first

Thank you for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/28211#issuecomment-3564212768

From macarte at openjdk.org  Fri Nov 21 18:47:21 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:47:21 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>

On Fri, 21 Nov 2025 00:32:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:
> 
>> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
>> 30:  * @library /test/lib
>> 31:  * @build JcmdAOTEndRecordingTest
> 
> No need to build test explicitly, jtreg does it by itself.

Thank you, I did not know that (copied another test as a template) - I've removed the build step in the header of both tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550662386

From cjplummer at openjdk.org  Fri Nov 21 18:49:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Nov 2025 18:49:37 GMT
Subject: Integrated: 8282441: [LOOM] The debug agent should attempt to free
 vthread ThreadNodes
In-Reply-To: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
References: <3Bj6ezlCUOeiv7OUJsRO2j4krWIeqrnwsIFWZVeBxSk=.0529cb73-de78-4f10-ac7f-420063557d6e@github.com>
Message-ID: <Dpop0nZWiOzFql4VgqeuyL5YQgElJjE9PeyH-ru2k98=.b4ff46e8-dd96-4dba-a944-028e5e4ec805@github.com>

On Mon, 10 Nov 2025 03:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This is first of what will probably be 3 PRs to improve virtual thread ThreadNode handling in the debug agent, with a goal of improving performance and reducing footprint.
> 
> This PR focuses on purging virtual thread ThreadNodes in two places:
> 
> 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual thread.
> 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend all"
> 
> At some point in the future I want to attempt to free the ThreadNodes after performing ThreadReference related commands, which will result in the creation of a ThreadNode if not already created. Another area is in handleReportEventCompositeCommand() when the thread is not null and we are using the SUSPEND_NONE policy. This will get more ThreadNodes freed immediately after handling an event.
> 
> Part of the challenge with this PR is that there are many places in the debug agent that expect a ThreadNode to already have been created for the virtual thread, but now it is common that they have not. The main way this has been addressed is by having findRunningThread() create the ThreadNode if it does not already exist.
> 
> At some point in the future I will probably add logic to only "GC" ThreadNodes after the number reaches some threshold, but right now I want to free them very aggressively so we'll catch any bugs where there debug agent expects a ThreadNode to exist, but possibly now it might not.
> 
> Tested by running all tier2, tier5, and tier6 CI svc tests.

This pull request has now been integrated.

Changeset: 2b5cd14e
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b5cd14ea5c571e0d55df8293e49b9a0db521a46
Stats:     244 lines in 1 file changed: 187 ins; 39 del; 18 mod

8282441: [LOOM] The debug agent should attempt to free vthread ThreadNodes

Reviewed-by: amenkov, sspitsyn

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

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

From macarte at openjdk.org  Fri Nov 21 18:56:57 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:56:57 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>

On Fri, 21 Nov 2025 00:56:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> src/hotspot/share/cds/aotMetaspace.cpp line 1062:
> 
>> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
>> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
>> 1062:   return _preimage_static_archive_dumped == 1;
> 
> Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?

Andrew brought this up also; I'll add but should it be AtomicAccess::load or AtomicAccess::load_acquire?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550681782

From macarte at openjdk.org  Fri Nov 21 19:12:25 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 19:12:25 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <73mIYRuGWI0kSUKqXQdb7MPjZqXwM9s4-EuZw6qeiWo=.8814d782-f332-4033-b43b-7317a82c8650@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <n2LclQT38NOWQE0fymzmKJuHjwMeLrYCqK0xGmzP9TU=.16b3d8f4-fde0-4966-ba0e-1a52f09f605d@github.com>
 <73mIYRuGWI0kSUKqXQdb7MPjZqXwM9s4-EuZw6qeiWo=.8814d782-f332-4033-b43b-7317a82c8650@github.com>
Message-ID: <FCKfnUyVcK9seaHtR0bKACMbElt9_LJuiz2Y5CVOLRE=.f3ec3513-dcaa-4c0d-bd4c-837106ccfc16@github.com>

On Tue, 28 Oct 2025 16:57:43 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMetaspace.cpp line 963:
>> 
>>> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {
>>> 962:   if (CDSConfig::is_dumping_preimage_static_archive()) {
>>> 963:       return _preimage_static_archive_dumped == 0;
>> 
>> Do we need to use an acquiring load here? i.e. can the read here and the cmpxchg below happen in different threads?
>> n.b. I'm not just thinking about the behaviour when this patch makes the DCmd available but also what happens when we supplement it with the MXBean interface to end recordings.
>
> I think it's okay, as ending the recording is controlled by the cmpxchg, even if two threads think the recording is still going on, only one call to end the recording will work, and if the threads both check whether the recording has completed they will both see that it has (regardless of which thread 'won')

Andrew I'm going to add the AtomicAccess::load_acquire, or would AtomicAccess::load be enough

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550719327

From sspitsyn at openjdk.org  Fri Nov 21 19:45:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 19:45:04 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v3]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <ZgAWlFHCFwF8z3BGA6lhGJaYPWoYa5ZfVuAA0neZZp4=.5dfc6ad7-c141-4642-8e72-515b3d31f432@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fix typo in a EATests.java comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/b3cffe5a..5989906c

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

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

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

From sspitsyn at openjdk.org  Fri Nov 21 19:45:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 19:45:08 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v2]
In-Reply-To: <-6UQvhvzWxm9r6rtvS4EjiVn-to2xAa64MJi-9_-zss=.fe61f491-31d9-4e75-932a-8e9a9f6a45d1@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <mot00Dt2O1w9NgvoqOLhmKZSp2ZRwdO0LaEwJnYWSWA=.00de5e39-0295-4618-813f-b90ddc22b1e3@github.com>
 <-6UQvhvzWxm9r6rtvS4EjiVn-to2xAa64MJi-9_-zss=.fe61f491-31d9-4e75-932a-8e9a9f6a45d1@github.com>
Message-ID: <tyyWU2n0p3uLUG_8--deyJsz0etjuBF7lH92Q7qZ3j8=.78e7c299-2bad-4345-97cb-0523030d8253@github.com>

On Fri, 21 Nov 2025 07:43:04 GMT, Jean-No?l Rouvignac <duke at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup: removed an old code fragment in frame.cpp
>
> test/jdk/com/sun/jdi/EATests.java line 3068:
> 
>> 3066:         // frame[4]: EATestsTarget.main(java.lang.String[])
>> 3067: 
>> 3068:         env.stepOverLine(thread); // needed to keep target thread interp-only, so dontinline_brkpt_iret is not inligned
> 
> inligned => inlined

Thank you catching it! Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r2550785711

From mdonovan at openjdk.org  Fri Nov 21 19:51:57 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:57 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
Message-ID: <E8Cv9YJqeMcmIHDtVKWojBGlRp1Jxb-iKxlYOmMasYg=.148a6982-c399-468e-9795-072d01b1c983@github.com>

On Thu, 13 Nov 2025 13:49:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:
> 
>> 34:  * @library /test/lib
>> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
>> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA
> 
> as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

It was suggested to keep test cases for TLS 1.2/MD5 as well as updating for TLS 1.3. If the TLS 1.2/MD5 isn't adding anything here I can remove it.

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:
> 
>> 1: /*
> 
> This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

I compared the two files from before I updated IPIdentities and they are identical. I removed IPIdentities.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550794961
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550797069

From mdonovan at openjdk.org  Fri Nov 21 19:51:58 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:58 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
 <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>
Message-ID: <MyUqaUSXqScHBkvmqAnNyrqyodsf7vHBrFVCteXmgIo=.4a124dc2-e169-43a6-8fb1-4640d1be1b1e@github.com>

On Fri, 14 Nov 2025 10:04:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
>> 
>>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>>> 103:                 .addBasicConstraintsExt(false, false, -1)
>>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
>> 
>> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities
>
> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

Yes, they are overwritten, extensions are stored as a Map between extention id and the extension.

> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

I added the IPV6 loopback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550800219

From dlong at openjdk.org  Fri Nov 21 19:57:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 21 Nov 2025 19:57:58 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v4]
In-Reply-To: <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
Message-ID: <DeMpbXG93GHzU5m-APq2co03uLso4ieqyUkl1U9MfsM=.929741c8-8ee4-4ee6-b2ef-8fb28dd0aa20@github.com>

On Thu, 20 Nov 2025 23:56:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine `first_check_size` definitions

CI testing results are good.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28192#pullrequestreview-3494168899

From mdonovan at openjdk.org  Fri Nov 21 20:14:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 20:14:53 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v6]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Updated SAN methods in CertificateBuilder to take multiple names
 - Merge branch 'master' into update-md5-certs
 - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
 - removed unused keystore files, fixed certificate chain
 - Merge branch 'master' into update-md5-certs
 - changed line wrapping
 - removed unnecessary comment and made getSSLContext(...) private
 - changed tests to use SecurityUtils.removeDisabled*Algs methods
 - fixed indents and copyright year
 - Merge branch 'master' into update-md5-certs
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c70734d2...6579bc79

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/1aaf4247..6579bc79

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

  Stats: 300342 lines in 2569 files changed: 194979 ins; 65676 del; 39687 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From sspitsyn at openjdk.org  Sat Nov 22 09:00:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
Message-ID: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

src/hotspot/share/runtime/javaThread.cpp line 1173:

> 1171: bool JavaThread::java_suspend(bool register_vthread_SR) {
> 1172: #if INCLUDE_JVMTI
> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.

Q: I wonder if the `#if INCLUDE_JVMTI` and `#endif` can be removed here.

src/hotspot/share/runtime/mountUnmountDisabler.cpp line 126:

> 124:          || global_start_transition_disable_count() > base_disable_count
> 125:          JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()));
> 126: }

I like this approach with the JVMTIStartTransition and JVMTIEndTransition helper classes. It is a nice way to decouple the JVMTI part of the protocol. Introducing the `is_start_transition_disabled()` function was also long desired. Also, I like the functions `start_transition()` and `end_transition()` became pretty simple and clean!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552502964
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552624330

From sspitsyn at openjdk.org  Sat Nov 22 09:00:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:50 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
Message-ID: <N56aqwKR83cEj5538zkeZV3PLlTQ3L4zQDeIJ_zA38M=.276aa97f-91eb-444b-9ec8-60ab3521bed2@github.com>

On Thu, 20 Nov 2025 22:55:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Alan's comment in VirtualThread
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 147:
> 
>> 145:       MonitorLocker ml(VTMSTransition_lock);
>> 146:       while (is_start_transition_disabled(current, vth())) {
>> 147:         ml.wait(200);
> 
> I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.

The timeouts are for reliability purposes only. Technically, they are not needed and can be removed after this code becomes stable. The `wait()` calls are inside while loop which rechecks the loop-ending conditions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552610777

From sspitsyn at openjdk.org  Sat Nov 22 09:00:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:00:52 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
Message-ID: <TKTJ-m3HWmLF_KxPhg2jfA5t4L8jAsTNEy7VZ_Y3QWE=.24244ebe-228d-4f9e-a135-29570178c63f@github.com>

On Fri, 21 Nov 2025 00:52:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:
> 
>> 50:   // parameter is_SR: suspender or resumer
>> 51:   MountUnmountDisabler(bool exlusive = false);
>> 52:   MountUnmountDisabler(oop thread_oop);
> 
> What does the comment mean here?

This comment is stale now and must be removed. The parameter `is_SR` is being replaced with the `exclusive`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552577039

From sspitsyn at openjdk.org  Sat Nov 22 09:15:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Nov 2025 09:15:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
Message-ID: <IOXHWtz5n6n0xKQraas83nCXPav_BUrsbkXAL1gK_Cw=.75b563f5-aec0-4851-9ff0-9d091a4f7bcb@github.com>

On Thu, 20 Nov 2025 23:10:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename VM methods for endFirstTransition/startFinalTransition

I've completed my first pass trough this update, and it looks pretty solid in general.
I'm going to make another pass next week.

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

> 3680: JVM_ENTRY(void, JVM_VirtualThreadEndTransition(JNIEnv* env, jobject vthread, jboolean is_mount))
> 3681:   oop vt = JNIHandles::resolve_external_guard(vthread);
> 3682:   MountUnmountDisabler::end_transition(thread, vt, is_mount, false /*is_thread_start*/);

The `JVM_VirtualThread*` functions have been nicely simplified.

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

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3496249775
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2552682664

From duke at openjdk.org  Sun Nov 23 17:56:48 2025
From: duke at openjdk.org (duke)
Date: Sun, 23 Nov 2025 17:56:48 GMT
Subject: Withdrawn: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods
 should be obsoleted then expired
In-Reply-To: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <S0Jrq9FcriXN-b4QKEezTF8lD8JLZh14flv-0H_VDz0=.95771afc-9efc-49e4-a0f7-5a066ac41e72@github.com>

On Thu, 10 Jul 2025 01:12:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27.
> 
> TBD: Need to submit a related CSR.
> 
> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams:
>  - Class redefinition/retransformation can impact lambda expressions which are supported with private methods
>  - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now).
>  
> Testing:
>  - mach5 tiers 1-6 are good
>  - may need to run mach5 tiers > 6

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Mon Nov 24 01:34:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Nov 2025 01:34:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
 <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
Message-ID: <AVT1wREU7BFMhtmv1zulfmbPlmPURe4qfcehfMILeDY=.d4cdcaa7-9726-48f6-8730-7f5b0dc57532@github.com>

On Fri, 21 Nov 2025 11:38:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @sspitsyn for diving into the issue. 
>> 
>> With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?
>
>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?
> 
> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

@sspitsyn  so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes?

We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing. The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress.

Agreed the tests are completely artificial but there is no way to test this other than to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3568649410

From duke at openjdk.org  Mon Nov 24 09:45:02 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 24 Nov 2025 09:45:02 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v4]
In-Reply-To: <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
Message-ID: <jQSXCV8wDzqE_C0ax9EYDjBtaqmvM8JlWMg7Wc8IoPw=.30e48f3e-98bb-4e03-add6-c95041bebc56@github.com>

On Thu, 20 Nov 2025 23:56:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine `first_check_size` definitions

Thank you both. I am planning to submit the `/integrate` request in a few hours.

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

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3569791332

From sspitsyn at openjdk.org  Mon Nov 24 10:24:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 24 Nov 2025 10:24:17 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
 <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
Message-ID: <bjrf0R5x_-JR_SdTJ2jgCnecDktYX3EgPU2PYTdrpSs=.abff2290-0fad-4aba-871a-efd9f99d15fb@github.com>

On Fri, 21 Nov 2025 11:38:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @sspitsyn for diving into the issue. 
>> 
>> With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?
>
>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?
> 
> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

> @sspitsyn so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes?

Suspend/Resume is a debugging feature and normally used in a debugging session and expected to cause a slow down. 
Also, it is known to be somewhat risky to use. So, my answer is yes. Slow down time does not matter much as it depends on a suspension time.

> We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing.

Agreed

> The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress.

You, most likely right that the current problem is a variant of that. But I disagree to qualify this issue as a deadlock.
The thread was picked as a successor and then suspended. It feels like it has to be qualified same as a thread owns the monitor and suspended. The issue is that the OM real state and the JVMTI state bits do to reflect this.
I feel that changing the order of JVMTI OM events and giving up the symmetry between `timed-wait` and `notified-wait` is risky and may cause more problems than this bug is trying to solve. I'm thinking if there is a way the tread could give up
being the OM successor.

> Agreed the tests are completely artificial but there is no way to test this other than to do that.

Agree with this. But the deadlock is in the new tests, not in the OM implementation. And yes, constructing a deadlock was needed to demonstrate the problem. It is confusing. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3569971399

From adinn at openjdk.org  Mon Nov 24 10:33:30 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 24 Nov 2025 10:33:30 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
 <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>
Message-ID: <NSQttx89qZk8QWFFxQDWGJs026b_otfYokwQDuptyYw=.5ea4b608-135c-4bd7-a012-f9a0a62784cd@github.com>

On Fri, 21 Nov 2025 18:53:17 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMetaspace.cpp line 1062:
>> 
>>> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
>>> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
>>> 1062:   return _preimage_static_archive_dumped == 1;
>> 
>> Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?
>
> Andrew brought this up also; I'll add but should it be AtomicAccess::load or AtomicAccess::load_acquire?

Just in case this might be called from a different thread to the one which is executing the `cmpxchg` you should really be using `AtomicAccess::load_acquire(&_preimage_static_archive_dumped)` here
You also need acquire-release semantics for the comparison below which you get as the default from your current use of `cmpxchg` below.

    if (AtomicAccess::cmpxchg(&_preimage_static_archive_dumped, 0, 1) != 0) {

Depending on the implementation that might be more heavyweight than you really need. e.g. given that the change is idempotent you could rely on a bare `xchg` with acq_rel semantics

    if (AtomicAccess::xchg(&_preimage_static_archive_dumped, 1, atomic_memory_order::memory_order_acq_rel) != 0) {

However, it's not going to matter very much since these are low-frequency operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2555662830

From djelinski at openjdk.org  Mon Nov 24 12:23:31 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 12:23:31 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v6]
In-Reply-To: <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>
Message-ID: <8bHfiZThBv6oNAn_y-trnWR-LqxZRAXgDdHEbdtOQ4E=.7527f68f-9a7a-4140-b4fb-2bdb0e2573fd@github.com>

On Fri, 21 Nov 2025 20:14:53 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Updated SAN methods in CertificateBuilder to take multiple names
>  - Merge branch 'master' into update-md5-certs
>  - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
>  - removed unused keystore files, fixed certificate chain
>  - Merge branch 'master' into update-md5-certs
>  - changed line wrapping
>  - removed unnecessary comment and made getSSLContext(...) private
>  - changed tests to use SecurityUtils.removeDisabled*Algs methods
>  - fixed indents and copyright year
>  - Merge branch 'master' into update-md5-certs
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/904578e0...6579bc79

Please convert the IPAddressDNSIdentities test as well. It's expecting a handshake failure, but now it's passing for the wrong reasons. Other than that, LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3570521948

From mbaesken at openjdk.org  Mon Nov 24 14:53:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Nov 2025 14:53:33 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

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

  Set the -dead_strip linker option only for the JDK libs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/b41966b8..b63b9ca8

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

  Stats: 13 lines in 2 files changed: 2 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319

PR: https://git.openjdk.org/jdk/pull/28319

From mbaesken at openjdk.org  Mon Nov 24 15:01:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Nov 2025 15:01:56 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: <woUEqbfMLLvDQqiq4BPt64I53SsTvKQPWfG4hClK8FU=.637b683c-8480-4c20-841f-df1f2b2ba997@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <nyDtm2Xmvgx9JjP5M6TKUsIJe_Mw3NW_Kta5zR-576Y=.d65500ff-7823-432f-8460-f09ca5dda703@github.com>
 <KWJNMVffhGrSQ_06bDieIjduVv93jn2GOzIPV8ROWdc=.fb4bce8a-41b5-4c4f-9b46-03d20c80f73f@github.com>
 <woUEqbfMLLvDQqiq4BPt64I53SsTvKQPWfG4hClK8FU=.637b683c-8480-4c20-841f-df1f2b2ba997@github.com>
Message-ID: <xnGM7Yjj_NxF3e1tnuwGw4Elvu8AzbtmppCgNMu5qAw=.9a0eeb38-308f-44c0-9639-ce07e0816a56@github.com>

On Fri, 21 Nov 2025 08:27:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Maybe we should for now limit the dead_strip to the JDK native libs ?

Done; additionally I set the dead_strip flag only for release builds (for (fast)debug builds we most likely are totally fine with larger binaries and debuginfo files) .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3571211348

From duke at openjdk.org  Mon Nov 24 16:50:40 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Nov 2025 16:50:40 GMT
Subject: RFR: 8371458: [REDO] Remove exception handler stub code in C2 [v4]
In-Reply-To: <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
 <R36a3XBDzqwx5zL2vD3KvZzmKq14zD5pLzQKC2pscNc=.375745f1-e9b3-4156-a8eb-c4f0c8a0d743@github.com>
Message-ID: <9kFgZAXhct0uyRPPomMDRX4VXd2Xd2GhosMyIuDb4qM=.d6caf7cd-8360-4aef-90ee-0029c12f0f32@github.com>

On Thu, 20 Nov 2025 23:56:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
>> 
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine `first_check_size` definitions

@ruben-arm 
Your change (at version 00ea0e143da03016531e301db673b1893cf9be64) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3571760781

From duke at openjdk.org  Mon Nov 24 17:02:07 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 24 Nov 2025 17:02:07 GMT
Subject: Integrated: 8371458: [REDO] Remove exception handler stub code in C2
In-Reply-To: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
References: <h0WKNTxJccZEtqBLt1ezA5rPzOFDRrW8p7E-LqZvPUw=.51a83e8f-cd83-4037-8b56-115ebc5b5ffe@github.com>
Message-ID: <4DuLwlcmvr3XcIxJnZPbuDumV2OiLwGZzM3N-zkS5-E=.16a23abc-f041-4321-8638-ee18429573c2@github.com>

On Fri, 7 Nov 2025 11:07:40 GMT, Ruben <duke at openjdk.org> wrote:

> The original fix [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) was backed out by [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388), this is the REDO.
> 
> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

This pull request has now been integrated.

Changeset: 21772600
Author:    Ruben Ayrapetyan <ruben.ayrapetyan at arm.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/217726009492af5a1143c98b97cc39b580850c5d
Stats:     640 lines in 46 files changed: 334 ins; 218 del; 88 mod

8371458: [REDO] Remove exception handler stub code in C2

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, dlong

-------------

PR: https://git.openjdk.org/jdk/pull/28192

From mdonovan at openjdk.org  Mon Nov 24 17:22:39 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Nov 2025 17:22:39 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v7]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan 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:

 - Updated IPAddressDNSIdentities and confirmed test fails for correct reason
 - Merge branch 'master' into update-md5-certs
 - Updated SAN methods in CertificateBuilder to take multiple names
 - Merge branch 'master' into update-md5-certs
 - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
 - removed unused keystore files, fixed certificate chain
 - Merge branch 'master' into update-md5-certs
 - changed line wrapping
 - removed unnecessary comment and made getSSLContext(...) private
 - changed tests to use SecurityUtils.removeDisabled*Algs methods
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cd9e5e5a...ea9c2dce

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/6579bc79..ea9c2dce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=05-06

  Stats: 1138 lines in 16 files changed: 412 ins; 630 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From coleenp at openjdk.org  Mon Nov 24 19:04:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Nov 2025 19:04:42 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v18]
In-Reply-To: <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
Message-ID: <Lmr81OEQ2eRmFcsnH1w8ibKMPuvDToBVDio-bsqDnzY=.09ed311b-6344-4649-90f0-a4c16ef925b3@github.com>

On Thu, 20 Nov 2025 08:36:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IDE doesn't help you with VM structs!

Looks good!  This is great work.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3501798483

From dfuchs at openjdk.org  Mon Nov 24 19:29:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 19:29:15 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
Message-ID: <_SMDMjDoXuDI_Sujt62HD_YewzTQQlvqMSkpffJKq3A=.64a03981-30d1-48e5-a767-d4121c617296@github.com>

On Thu, 13 Nov 2025 09:27:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > Some quick comments.
>>> > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>>> > 
>>> > 
>>> > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>>> 
>>> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
>
>> > > > Some quick comments.
>> > > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>> > > 
>> > > 
>> > > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>> > 
>> > 
>> > There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
> 
> This looks good, since all these are concrete vector classes not exposed to users.

@jatin-bhateja it looks like you should be merging latest changes from master; Some changes shown in the diff obviously do not belong to this fix:
https://github.com/openjdk/jdk/pull/28002/files#diff-7798f606ce2bbf96fd99999c8c0ef9a4bb0455c128dd7e1249dea8db23d35402
Hopefully merging latest changes from master will make them go away?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3571013379

From jbhateja at openjdk.org  Mon Nov 24 19:29:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:14 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <6ma1bZs5YmEe_PtNmR69pVoJ_YAWy5fUQrsnnk8nH9M=.0594b623-f494-4af3-8e1c-f88120c53aca@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - Fix some JTREG failures
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Revamped JTreg test generation and bug fixes
 - Cleanups
 - Removing redundant warmup constraint
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8bafc2f0...f34d324f

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 509516 lines in 232 files changed: 281237 ins; 226539 del; 1740 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From jbhateja at openjdk.org  Mon Nov 24 19:29:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:17 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
Message-ID: <ej2VU_26IZZBDgiGvry6djiDTMbjxH6XdqfgC0uuggc=.3e410400-d552-4721-8277-60eda5db7524@github.com>

On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>
>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
> 
> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

Hi @PaulSandoz, I have addressed your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3572377706

From vlivanov at openjdk.org  Mon Nov 24 22:59:36 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 24 Nov 2025 22:59:36 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v4]
In-Reply-To: <inQ3KgQ96jowq9A3rgrxuEOVtwN2mHGl2QL0vOOHK7Y=.d89c6360-19b1-4df5-8069-a8873f0a6ec8@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <inQ3KgQ96jowq9A3rgrxuEOVtwN2mHGl2QL0vOOHK7Y=.d89c6360-19b1-4df5-8069-a8873f0a6ec8@github.com>
Message-ID: <i-vxT3Hxwk2QG_yEvi9KiuMFHIw4Xxb8Qhgxd8IsR8k=.e0d1bc04-491a-4e58-83de-a9e5412de208@github.com>

On Fri, 21 Nov 2025 14:53:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> ArrayKlass doesn't set AccessFlags so don't look for them there.  See CR for details.
>> Fixed SA and jvmci.  @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
>> Tested with tier1-4.  5-7 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformatting compile.cpp

src/hotspot/share/opto/library_call.cpp line 4100:

> 4098:     // Other types can report the actual _super.
> 4099:     // (To verify this code sequence, check the asserts in JVM_IsInterface.)
> 4100:     if (generate_interface_guard(kls, region) != nullptr)

BTW why did you decide to change the order of the checks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2557971918

From macarte at openjdk.org  Tue Nov 25 00:58:06 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 00:58:06 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v6]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <PrfhvGt_sEZgS7ml8X2iOb7LJKAFP-zIMAeXk6AJXeg=.354be362-8be8-404b-a45a-452436de0969@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Added acquire_load and improved tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/f1f5d77d..2223870c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=04-05

  Stats: 30 lines in 3 files changed: 24 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

PR: https://git.openjdk.org/jdk/pull/27965

From macarte at openjdk.org  Tue Nov 25 00:58:12 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 00:58:12 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
 <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>
Message-ID: <2faJMusAYCjby-CJDGEQOkBywiV8yw-pGNqYzlJy2Mg=.48cebdc2-9f95-4e59-a228-e4e0a803fd40@github.com>

On Fri, 21 Nov 2025 18:43:44 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:
>> 
>>> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
>>> 30:  * @library /test/lib
>>> 31:  * @build JcmdAOTEndRecordingTest
>> 
>> No need to build test explicitly, jtreg does it by itself.
>
> Thank you, I did not know that (copied another test as a template) - I've removed the build step in the header of both tests

I tried this and it seemed to work until I modified the test then the app.jar failed to build.

>> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:
>> 
>>> 55:             try {
>>> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
>>> 57:                 output.shouldContain("AOT.end_recording is unsupported");
>> 
>> A little bit confused.  The check doesn't match test description.
>
> This test uses Lingered apps (enabling the jcmd connection), however the test framework here doesn't support creating the AOT cache - so I simply check that the connection works and the diagnostic command returns the expected value when you aren't recording a cache
> 
> I'm trying to create an additional test that allows jcmd to end training on an AOT recording, but there's some issues merging the jcmd test support and the aot test support;  I will make it clearer in this test about this limitation

Updated the test now, it runs twice, once in training mode and once not.  And checks the appropriate response from the diagnostic command

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2558149696
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2558153818

From macarte at openjdk.org  Tue Nov 25 01:01:19 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 01:01:19 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Check exit value in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/2223870c..dae85272

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=05-06

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

PR: https://git.openjdk.org/jdk/pull/27965

From macarte at openjdk.org  Tue Nov 25 01:04:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 01:04:37 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <RNZzi6MSztflQxxrsQaHlPmRGLtr85_bSsSlOCz7S9w=.a3c23612-b237-40a5-b033-c556c8c98a6c@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
 <RNZzi6MSztflQxxrsQaHlPmRGLtr85_bSsSlOCz7S9w=.a3c23612-b237-40a5-b033-c556c8c98a6c@github.com>
Message-ID: <CC_7Xq_RHo6jH_0ezBU-cvkDpri5yMiL1ckUoysV-jc=.52b606da-c676-489b-bcc7-d84d58087f58@github.com>

On Wed, 5 Nov 2025 21:48:41 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:
> 
>> 76:        *  specification of the corresponding JVM command-line options, please refer
>> 77:        * to https://openjdk.org/jeps/483 and https://openjdk.org/jeps/514.
>> 78:        *
> 
> Please don't use bare URLs. Change these to
> 
> ... please refer to JEPs <a href="https://openjdk.org/jeps/483">483</a> and
> <a href="https://openjdk.org/jeps/514">514</a>.

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2558167839

From dlong at openjdk.org  Tue Nov 25 01:05:01 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 25 Nov 2025 01:05:01 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v4]
In-Reply-To: <i-vxT3Hxwk2QG_yEvi9KiuMFHIw4Xxb8Qhgxd8IsR8k=.e0d1bc04-491a-4e58-83de-a9e5412de208@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <inQ3KgQ96jowq9A3rgrxuEOVtwN2mHGl2QL0vOOHK7Y=.d89c6360-19b1-4df5-8069-a8873f0a6ec8@github.com>
 <i-vxT3Hxwk2QG_yEvi9KiuMFHIw4Xxb8Qhgxd8IsR8k=.e0d1bc04-491a-4e58-83de-a9e5412de208@github.com>
Message-ID: <IxdQa7yMI0ZYWemRBIEQH3LOLcaNMKkM9TjvPJR4yR4=.4f47fe4f-9f2b-4bfd-a155-1ba16e0069ad@github.com>

On Mon, 24 Nov 2025 22:57:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reformatting compile.cpp
>
> src/hotspot/share/opto/library_call.cpp line 4100:
> 
>> 4098:     // Other types can report the actual _super.
>> 4099:     // (To verify this code sequence, check the asserts in JVM_IsInterface.)
>> 4100:     if (generate_interface_guard(kls, region) != nullptr)
> 
> BTW why did you decide to change the order of the checks?

I noticed that too.  It is necessary for correctness now.  It is incorrect and unsafe to use generate_interface_guard() on array after this change, because an array klass is not an InstanceKlass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2558168496

From vlivanov at openjdk.org  Tue Nov 25 01:28:47 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Nov 2025 01:28:47 GMT
Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v4]
In-Reply-To: <IxdQa7yMI0ZYWemRBIEQH3LOLcaNMKkM9TjvPJR4yR4=.4f47fe4f-9f2b-4bfd-a155-1ba16e0069ad@github.com>
References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com>
 <inQ3KgQ96jowq9A3rgrxuEOVtwN2mHGl2QL0vOOHK7Y=.d89c6360-19b1-4df5-8069-a8873f0a6ec8@github.com>
 <i-vxT3Hxwk2QG_yEvi9KiuMFHIw4Xxb8Qhgxd8IsR8k=.e0d1bc04-491a-4e58-83de-a9e5412de208@github.com>
 <IxdQa7yMI0ZYWemRBIEQH3LOLcaNMKkM9TjvPJR4yR4=.4f47fe4f-9f2b-4bfd-a155-1ba16e0069ad@github.com>
Message-ID: <dD9DzyyJmHqbh7aVx3206csPZR4agLFXlNhkoxnjWKo=.1c2d4f7d-564e-40eb-92f0-94d90195a35f@github.com>

On Tue, 25 Nov 2025 01:01:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 4100:
>> 
>>> 4098:     // Other types can report the actual _super.
>>> 4099:     // (To verify this code sequence, check the asserts in JVM_IsInterface.)
>>> 4100:     if (generate_interface_guard(kls, region) != nullptr)
>> 
>> BTW why did you decide to change the order of the checks?
>
> I noticed that too.  It is necessary for correctness now.  It is incorrect and unsafe to use generate_interface_guard() on array after this change, because an array klass is not an InstanceKlass.

Oh, that's subtle... It deserves a comment at least.

We could also change `LibraryCallKit::generate_interface_guard()` to require `kls` to be of type `TypeInstKlassPtr`, but then we would need a cast before calling it from `LibraryCallKit::inline_native_Class_query()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2558217038

From cjplummer at openjdk.org  Tue Nov 25 02:48:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 02:48:50 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
Message-ID: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>

Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.

With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.

Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

-------------

Commit messages:
 - fix whitespace
 - disable VIRTUAL_THREAD_START adn VIRTUAL_THREAD_END unless needed

Changes: https://git.openjdk.org/jdk/pull/28485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28485&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371380
  Stats: 328 lines in 7 files changed: 263 ins; 37 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/28485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28485/head:pull/28485

PR: https://git.openjdk.org/jdk/pull/28485

From cjplummer at openjdk.org  Tue Nov 25 02:48:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 02:48:51 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <fMUSqMwgH1IH9t8XkYNsmNw0C8KFhFNXYw9-03YXHOE=.cbe962d9-96d6-4ead-8302-50133aa1871d@github.com>

On Tue, 25 Nov 2025 02:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

The debug agent always enables VIRTUAL_THREAD_START/END. This is very detrimental to performance with apps that create a lot of virtual therads. The flood of events bogs down the debug agent, and also slows down JVMTI which needs to create a jvmtiThreadState for each thread just to deliver the event to the debug agent. 

If the debug agent includevirtualthreads option is not set to 'y' (it is 'n' by default), then it is possible for the debug agent to start up without enabling VIRTUAL_THREAD_START/END events (currently it always enables them). However, they need to be enabled if the debugger creates any ThreadStartRequests or ThreadDeathRequests and do not include the PlatformThreadsOnly filter. Given that by default jdb and mainstream debuggers all seem to add this filter, this is unlikely to be an issue.

The changes in this PR make it so the debug agent no longer automatically enables all VIRTUAL_THREAD_START/END (unless VIRTUAL_THREAD_START=y), and instead only enables them based on to the presence of ThreadStartRequests or ThreadDeathRequests that don't set the PlatformThreadsOnly filter.

Also, for ThreadDeathRequests that don't set the PlatformThreadsOnly filter but do set the thread filter, VIRTUAL_THREAD_END events are only enabled for the thread that is being filtered on. This is important for debuggers (like jdb) that register a ThreadDeathRequest for any ThreadReference the debugger is tracking, and want to stop tracking once the thread exits.

One challenge with these changes was getting the event enabling/disabling right in eventFilter.c. Disabling was especially tricky because when removing an event request, all other event requests (of the same kind) have to be examined to see if any still require the event to be enabled. If there is a filter thread, that also needs to be considered.

The other challenge was dealing with the fact that without VIRTUAL_THREAD_END events, you can end up with terminated threads on the runningVThreads list. There were a few places that had to be special cased to deal with this.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1640:

> 1638: 
> 1639:         if (gdata->vthreadsSupported) {
> 1640:             // Now is a good time to garbage collect vthread nodes.

The original comment at one point was true while I was working on the previous PR that introduced it. However, I later added a check for (node->suspendCount == suspendAllCount) to freeUnusedVThreadNode(). If true, then we can free the ThreadNode even though it has a non-zero suspendCount. If the ThreadNode is recreated at some point in the future, it will get suspendAllCount assigned to node->suspendCount.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28485#issuecomment-3573531199
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2558355260

From jbhateja at openjdk.org  Tue Nov 25 09:05:54 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 25 Nov 2025 09:05:54 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v4]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <xSJ5MrtvVXuL5uGL22XIAp1drhp9o11Ou8ebWjMJTC4=.5875165a-8929-4f07-b7ca-129f758709d5@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing jtreg test in CI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/f34d324f..aca6cc5d

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From mbaesken at openjdk.org  Tue Nov 25 09:08:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 09:08:30 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
Message-ID: <RCrJ4ot2NHZ8oN8_xAC1q0gc7ylVUMyuRE7mqBVcIKc=.406b7576-bac1-4ed2-91f2-b1f22efc0a04@github.com>

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Any comments on the recent version ? 
The dead_strip option seems to the rather similar to the link time gc option we support for gcc currently and offer this configure flag 

make/autoconf/jdk-options.m4


112   UTIL_ARG_ENABLE(NAME: linktime-gc, DEFAULT: $LINKTIME_GC_DEFAULT,
113       DEFAULT_DESC: [auto], RESULT: ENABLE_LINKTIME_GC,
114       DESC: [use link time gc on unused code sections in the JDK build],
115       CHECKING_MSG: [if linker should clean out unused code (linktime-gc)])
116   AC_SUBST(ENABLE_LINKTIME_GC)



Should we also put the dead_strip behind this configure flag and rephrase the description above a little bit , e.g.
`114       DESC: [use link time gc or similar features on unused code sections in the JDK build],`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3574548509

From sspitsyn at openjdk.org  Tue Nov 25 09:13:57 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Nov 2025 09:13:57 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>

On Tue, 25 Nov 2025 02:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1444:

> 1442:                 } else {
> 1443:                     error = threadControl_setEventMode(JVMTI_DISABLE, EI_VIRTUAL_THREAD_END, thread);
> 1444:                 }

Q: Why is the `THREAD_START` event disabled globally (for all threads) but the `THREAD_END` event is disabled for specific thread?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2559181531

From sspitsyn at openjdk.org  Tue Nov 25 09:16:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Nov 2025 09:16:06 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v18]
In-Reply-To: <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
Message-ID: <amwAODlTXvtQkOAbKQol__vYT7HwJUcOkfDk_Kvb8QA=.ea57503a-6d1e-45c2-b34a-c6f446cc50fd@github.com>

On Thu, 20 Nov 2025 08:36:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IDE doesn't help you with VM structs!

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3504064826

From mbaesken at openjdk.org  Tue Nov 25 09:26:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 09:26:11 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
Message-ID: <StB3Nf1Xy9tMx5HJjg9RXnJkhmfEDnC5-zIEeji0U2U=.9ebfe19f-749d-443a-adae-0271574dac12@github.com>

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Here are some current values  (build from last evening 24th Nov.) for JDK native libs where I see a noticeable effect in size reduction with this PR (values in K without `->` with the flag , product build, XCode 15 used)

1216 ->  1188    /jdk/lib/libawt_lwawt.dylib
1348 ->  1036    /jdk/lib/libfontmanager.dylib
636	 ->  620     /jdk/lib/libfreetype.dylib
264  ->  248     /jdk/lib/libjavajpeg.dylib
312	 ->  292     /jdk/lib/libjdwp.dylib
152 -> 132       /jdk/lib/libjli.dylib
388 -> 296       /jdk/lib/liblcms.dylib
500 -> 484     /jdk/lib/libmlib_image.dylib
164 -> 128     /jdk/lib/libzip.dylib

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3574624069

From ysuenaga at openjdk.org  Tue Nov 25 11:45:20 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 25 Nov 2025 11:45:20 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v3]
In-Reply-To: <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
Message-ID: <Bvma6gov3OZAcOwRHOL2BbTEWQZg-wfF9JV3VgAlYHM=.e5c01b91-a54d-46f4-a5e8-24a260d8b131@github.com>

On Thu, 20 Nov 2025 01:25:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've fixed mixed mode jstack for the debuggee running with `-Xcomp` in [JDK-8370176](https://bugs.openjdk.org/browse/JDK-8370176), but it was not enough. We need to handle like unifying `CFrame` and `Frame` in stack unwinding as possible, and need to change how to get caller SP/FP from stack.
>> 
>> This PR works fine on both Linux AMD64 and Linux AArch64. All of `hotspot/jtreg/serviceability/sa` tests have been passed on both platforms.
>> 
>> Big thanks to @pchilano for your help!
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for macOS

PING: could you review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3575231530

From kevinw at openjdk.org  Tue Nov 25 12:07:18 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 12:07:18 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
Message-ID: <I1o_izIRQOd-WOJwYcfIBtzD3E4jKTqUWwZjXnhyA-Y=.1c36d4fe-5335-47fa-a0e8-344eeefbc255@github.com>

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove single whitespace

src/jdk.management/share/classes/com/sun/management/internal/HotSpotAOTCacheImpl.java line 48:

> 46:     }
> 47: 
> 48:     public boolean endRecording(){

trivial missing space nit (){

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2559745591

From kevinw at openjdk.org  Tue Nov 25 12:13:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 12:13:41 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
Message-ID: <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>

On Thu, 13 Nov 2025 19:55:24 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove single whitespace

src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:

> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
> 191:                 if (impl == null) {
> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());

This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
	
..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2559762899

From alanb at openjdk.org  Tue Nov 25 12:26:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Nov 2025 12:26:32 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>
Message-ID: <tyqT3zZc_ZeRjh5gmNfzlrTbdOdWUdR08YK5yVgbPaI=.7c427f7f-9bb0-4f1a-a599-bac438cb0768@github.com>

On Tue, 25 Nov 2025 12:10:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove single whitespace
>
> src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:
> 
>> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
>> 191:                 if (impl == null) {
>> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());
> 
> This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
> 	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
> 	
> ..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.

I don't see a correctly issue with this. Maybe in the future we will be able to use LazyConstant here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2559800006

From mbaesken at openjdk.org  Tue Nov 25 13:12:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 13:12:06 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v5]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Use dead_strip on macOS arrch64 AND x86_64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/b63b9ca8..c158747f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319

PR: https://git.openjdk.org/jdk/pull/28319

From mbaesken at openjdk.org  Tue Nov 25 13:12:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 13:12:08 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <O8MtweM7uLMNdF7Z5vjHQXMmWu_IeIL2ERD5kx9L8o8=.8d9eead6-9215-44f3-a8c9-435ed671a101@github.com>
Message-ID: <5_ovGdYHonxBCe-7ftDT2kErYBHe-8HPv0cwme_2Mj8=.1479051a-0fa5-455f-89c3-1312f2d16017@github.com>

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Now we only set the flag for the JDK native libs, so I enabled it also for macOS x86_64 .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3575562810

From kevinw at openjdk.org  Tue Nov 25 13:16:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 13:16:15 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <ClN6KLNjUKLfedhkfopFfCRowAHkgqJkI_xShcwaDDs=.6b6ee5ca-0a2b-4027-bba4-fb212293d4f9@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

test/hotspot/jtreg/runtime/cds/appcds/aotCache/DiagnosticCommandMBeanTest.java line 152:

> 150:                 System.out.println("Failed to stop recording");
> 151:             }
> 152:         } catch (MBeanException e) {

Can we catch Exception here generally, and print the stacktrace so we can see what happened if there are failures?

Then print the "Exception occurred!" so it's seen by the caller and the test fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2559943955

From kevinw at openjdk.org  Tue Nov 25 13:30:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 13:30:23 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <bZkoUANvHq2iBsBARB1HKX3qAbYHpB-3veq4R7H-zM8=.958c0dfb-7f07-469c-9bf2-66036ceab6c0@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Looking good I think.

A possible general issue is that the AOT implementation of the dumping may write mesages on tty-> but they are not captured by the jcmd.  Not too much of an issue for a training run as presumably the app is being monitored by whoever asks for the endRecording() to happen.  I think the plan for now would be: should the jcmd fail, you check the app output for possibly more detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3575650962

From jsjolen at openjdk.org  Tue Nov 25 13:43:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 25 Nov 2025 13:43:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v18]
In-Reply-To: <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <G2mRQ39ufDFQfyqQGniWZxpybmg74stu2c1DKyogRR4=.563aea64-44f9-4742-b7c4-fb439439d734@github.com>
Message-ID: <b9U6x3It_p7zuIkQPktpL_Rrgog0X-1vQGA4heol3Pg=.626d36f1-99d8-4236-a211-d2b94b9dc258@github.com>

On Thu, 20 Nov 2025 08:36:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IDE doesn't help you with VM structs!

Thank you all for your reviews :-).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3575718289

From jsjolen at openjdk.org  Tue Nov 25 13:46:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 25 Nov 2025 13:46:41 GMT
Subject: Integrated: 8367656: Refactor Constantpool's operand array into two
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <ZO9SNY23fyCZYwYJ-D9-Z6iQsBoOCnJ_89MTr-MwMXE=.412dc0d7-f979-462a-9295-3caf7a061884@github.com>

On Wed, 10 Sep 2025 16:19:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

This pull request has now been integrated.

Changeset: d94c52cc
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d94c52ccf2fed3fc66d25a34254c9b581c175fa1
Stats:     895 lines in 12 files changed: 436 ins; 282 del; 177 mod

8367656: Refactor Constantpool's operand array into two

Reviewed-by: coleenp, sspitsyn, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/27198

From erikj at openjdk.org  Tue Nov 25 14:03:31 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 14:03:31 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <nsw1J1lPTHEU4cc3_UlmE9zj2FwTtS2kNRl8hWY9Mqs=.c0f09a8b-928e-475c-9136-07bcb687b443@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3505215274

From cjplummer at openjdk.org  Tue Nov 25 16:35:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 16:35:50 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
Message-ID: <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>

On Tue, 25 Nov 2025 09:09:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
>> 
>> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
>> 
>> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).
>
> src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1444:
> 
>> 1442:                 } else {
>> 1443:                     error = threadControl_setEventMode(JVMTI_DISABLE, EI_VIRTUAL_THREAD_END, thread);
>> 1444:                 }
> 
> Q: Why is the `THREAD_START` event disabled globally (for all threads) but the `THREAD_END` event is disabled for specific thread?

THREAD_START can't have a thread filter. THREAD_END can. "thread" == requestThread(node) == the thread filter if there is one, so when disabling THREAD_START it could be an actual thread or it could just be NULL. For THREAD_START "thread" should always be NULL, so I suppose I could have just asserted that and used "thread" as the argument instead of "NULL".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2560664560

From cjplummer at openjdk.org  Tue Nov 25 17:36:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 17:36:21 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
 <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>
Message-ID: <UbRwR_MlVjDzHuBMH-sA7g-f4gpJ-OsxjUAJz_O-P7E=.a8241adb-2d87-4283-9432-ecba479a7c68@github.com>

On Tue, 25 Nov 2025 16:32:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1444:
>> 
>>> 1442:                 } else {
>>> 1443:                     error = threadControl_setEventMode(JVMTI_DISABLE, EI_VIRTUAL_THREAD_END, thread);
>>> 1444:                 }
>> 
>> Q: Why is the `THREAD_START` event disabled globally (for all threads) but the `THREAD_END` event is disabled for specific thread?
>
> THREAD_START can't have a thread filter. THREAD_END can. "thread" == requestThread(node) == the thread filter if there is one, so when disabling THREAD_START it could be an actual thread or it could just be NULL. For THREAD_START "thread" should always be NULL, so I suppose I could have just asserted that and used "thread" as the argument instead of "NULL".

Actually it appears that JDWP THREAD_START can have a filter but JVMTI THREAD_START does not allow you to set the thread to enable the events on. That means when JDWP THREAD_START events are requested and a thread filter is provided, JVMTI THREAD_START needs to be enabled for all threads. That's actually how it is working now. I tried adding the assert and it was triggered. So that means passing "thread" instead of NULL would sometimes end up passing an actual thread to JVMTI and it would produce a [JVMTI_ERROR_ILLEGAL_ARGUMENT in that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2560862724

From lmesnik at openjdk.org  Tue Nov 25 17:41:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Nov 2025 17:41:33 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 =?UTF-8?B?bnNrX2p2bXRpX3NldEZhaWxTdOKApg==?=
Message-ID: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>

Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().

I run jvmti tests with different options and probelmlisted the only failing tests.


The previous attempt uncover a lot of problems related to the 
[JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
The events might be generated after VM_DEATH event

-------------

Commit messages:
 - 8352654: [REDO] nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called

Changes: https://git.openjdk.org/jdk/pull/28404/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352654
  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28404/head:pull/28404

PR: https://git.openjdk.org/jdk/pull/28404

From cjplummer at openjdk.org  Tue Nov 25 19:16:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 19:16:36 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <UbRwR_MlVjDzHuBMH-sA7g-f4gpJ-OsxjUAJz_O-P7E=.a8241adb-2d87-4283-9432-ecba479a7c68@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
 <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>
 <UbRwR_MlVjDzHuBMH-sA7g-f4gpJ-OsxjUAJz_O-P7E=.a8241adb-2d87-4283-9432-ecba479a7c68@github.com>
Message-ID: <JI_GbLo65Tp3JkOUTkCaiQNJsW8LMNSI8-fp__5aV4g=.d0b96f3f-ada0-4495-933d-32bfe29f3899@github.com>

On Tue, 25 Nov 2025 17:33:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> THREAD_START can't have a thread filter. THREAD_END can. "thread" == requestThread(node) == the thread filter if there is one, so when disabling THREAD_START it could be an actual thread or it could just be NULL. For THREAD_START "thread" should always be NULL, so I suppose I could have just asserted that and used "thread" as the argument instead of "NULL".
>
> Actually it appears that JDWP THREAD_START can have a filter but JVMTI THREAD_START does not allow you to set the thread to enable the events on. That means when JDWP THREAD_START events are requested and a thread filter is provided, JVMTI THREAD_START needs to be enabled for all threads. That's actually how it is working now. I tried adding the assert and it was triggered. So that means passing "thread" instead of NULL would sometimes end up passing an actual thread to JVMTI and it would produce a [JVMTI_ERROR_ILLEGAL_ARGUMENT in that case.

There  is a bug in the call to eventHandlerRestricted_iterator() at line 1436. For VIRTUAL_THREAD_START I should be explicitly passing in NULL for the thread. Otherwise it will consider the thread when deciding if other event handlers are a match to this one, and I don't think we want that. It could lead to disabling VIRTUAL_THREAD_START events when we shouldn't. Seems we don't have any tests for this but I modified an existing test and got a failure. The test creates a ThreadStartRequest with a thread filter and expects that to trigger a ThreadStartEvent for the filter thread. If I create a second ThreadStartRequest with a filter on a different thread, enable it, and then disable it, that ends up disabling all VIRTUAL_THREAD_START events, and the expected event never arrives. Passing NULL fixes the problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561121225

From pchilanomate at openjdk.org  Tue Nov 25 19:58:40 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:40 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
Message-ID: <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>

On Thu, 20 Nov 2025 22:17:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Alan's comment in VirtualThread
>
> src/hotspot/share/classfile/javaClasses.cpp line 1757:
> 
>> 1755:   jint* addr = java_thread->field_addr<jint>(_VTMS_transition_disable_count_offset);
>> 1756:   int val = AtomicAccess::load(addr);
>> 1757:   AtomicAccess::store(addr, val + 1);
> 
> Suggestion:
> 
>   AtomicAccess::inc(addr);

Same here.

> src/hotspot/share/classfile/javaClasses.cpp line 1764:
> 
>> 1762:   jint* addr = java_thread->field_addr<jint>(_VTMS_transition_disable_count_offset);
>> 1763:   int val = AtomicAccess::load(addr);
>> 1764:   AtomicAccess::store(addr, val - 1);
> 
> Suggestion:
> 
>   AtomicAccess::dec(addr);

I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

> src/hotspot/share/opto/runtime.hpp line 740:
> 
>> 738:     return vthread_transition_Type();
>> 739:   }
>> 740: 
> 
> I do not know C2 but this looks really strange - 4 different functions all return the same thing. ???

We need to define them because the `GEN_C2_STUB` macro will look for the type of the C function based on its name (`C2_STUB_TYPEFUNC(name)`), otherwise we get a compilation failure. The four C functions have the same type though so they all return `_vthread_transition_Type`.

> src/hotspot/share/runtime/handshake.cpp line 374:
> 
>> 372:     JavaThread* target = java_lang_Thread::thread(carrier_thread);
>> 373:     assert(target != nullptr, "");
>> 374:     // Technically there is need for a ThreadsListHandle since the target
> 
> Suggestion:
> 
>     // Technically there is no need for a ThreadsListHandle since the target
> 
> ?

Yes, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561198741
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561198549
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561200538
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561202212

From pchilanomate at openjdk.org  Tue Nov 25 19:58:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:34 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v5]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <8QdmTglMpQwGWG0QeQLbeduPrF1qZkah-9RzQwSOQuY=.fa030def-7674-48e3-bc25-23358009ed87@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  David's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/10534b33..b54594c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=03-04

  Stats: 46 lines in 4 files changed: 18 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

PR: https://git.openjdk.org/jdk/pull/28361

From pchilanomate at openjdk.org  Tue Nov 25 19:58:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:43 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v5]
In-Reply-To: <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
Message-ID: <PGS-qho_YM25_jUIrL20wFoCR55uQhFJ__kH6LQ__V8=.38fc9ad6-48be-4bff-a68b-4410ec7c846f@github.com>

On Thu, 20 Nov 2025 22:26:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   David's comments
>
> src/hotspot/share/prims/jvm.cpp line 3668:
> 
>> 3666:   if (!DoJVMTIVirtualThreadTransitions) {
>> 3667:     assert(!JvmtiExport::can_support_virtual_threads(), "sanity check");
>> 3668:     return;
> 
> Does this not still need checking somewhere?

The check for `DoJVMTIVirtualThreadTransitions` was moved to the `JVMTIStartTransition\JVMTIEndTransition` classes, but I guess you refer to the assert: I missed to move it. Added now too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561201839

From pchilanomate at openjdk.org  Tue Nov 25 19:58:45 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:45 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <N56aqwKR83cEj5538zkeZV3PLlTQ3L4zQDeIJ_zA38M=.276aa97f-91eb-444b-9ec8-60ab3521bed2@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
 <N56aqwKR83cEj5538zkeZV3PLlTQ3L4zQDeIJ_zA38M=.276aa97f-91eb-444b-9ec8-60ab3521bed2@github.com>
Message-ID: <j4Tkz0dH8FklF8jjU2StqSyk7Q7Ty_oDet_hMY5o5F4=.af147be6-1af8-4e4a-96b6-6c35184d4522@github.com>

On Sat, 22 Nov 2025 08:37:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 147:
>> 
>>> 145:       MonitorLocker ml(VTMSTransition_lock);
>>> 146:       while (is_start_transition_disabled(current, vth())) {
>>> 147:         ml.wait(200);
>> 
>> I see a lot of timed-waits throughout this code. Is that because we poll rather than synchronizing properly? All this potential busy-waiting is surely going to cause performance glitches.
>
> The timeouts are for reliability purposes only. Technically, they are not needed and can be removed after this code becomes stable. The `wait()` calls are inside while loop which rechecks the loop-ending conditions.

I tried to minimize the changes with respect to the current code so I kept the timed-waits. As Serguei points out we should be able to remove this particular one. As for the ones executed by the disablers, we could make them poll for the transition bits in a loop with backoff, similar to how we do it in safepoint and handshake cases. But I agree with Serguei we should do it in a separate bug once the code is stable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561204423

From pchilanomate at openjdk.org  Tue Nov 25 19:58:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:47 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <vEnsjdOFfdLuJAFoYWB0zvxd2yLSdIRxAgHT7TRFqJw=.ad5f055e-1488-4def-b448-daf9a2e616c3@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <vEnsjdOFfdLuJAFoYWB0zvxd2yLSdIRxAgHT7TRFqJw=.ad5f055e-1488-4def-b448-daf9a2e616c3@github.com>
Message-ID: <w82F8U6iK9OAqdFU2CQnszn4mznpWEQS1Qoj5V9l520=.af555ea0-a4b1-40f7-bfe7-4e260ea3abd9@github.com>

On Fri, 21 Nov 2025 01:01:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 162:
>> 
>>> 160:   // be executed once we go back to Java. If this is an unmount, the handshake that the
>>> 161:   // disabler executed against this carrier thread already provided the needed synchronization.
>>> 162:   // This matches the release fence in xx_enable_for_one()/xx_enable_for_all().
>> 
>> Subtle. Do we have comments where the fences are to ensure people realize the fence is serving this purpose?
>
> I also forgot to suggest a wording change: say "pairs with" rather than "matches". Reading back through I realize now I have misunderstood many of these comments.

Changed to `pairs with`. I rewrote the comments so hopefully?they are more clear now. I also added a comment in `VirtualThread.mount/unmount` where the memory barriers should be.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561205763

From pchilanomate at openjdk.org  Tue Nov 25 19:58:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:58:53 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
Message-ID: <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>

On Fri, 21 Nov 2025 00:42:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 277:
> 
>> 275: 
>> 276:   // Start of the critical region. Prevent future memory
>> 277:   // operations to be ordered before we read the transition flag.
> 
> Does this refer to `java_lang_Thread::is_in_VTMS_transition(_vthread())`? If so perhaps that should internally perform the `load_acquire`?

Yes, but that would also call for doing the same with `JavaThread::_is_in_VTMS_transition` for the `VTMS_transition_disable_for_all` case, and also have the pairing release stores by the virtual thread in `end_transition` on those same addresses, otherwise it would be confusing. And same with the other side, i.e doing load_acquire by the virtual thread of `_VTMS_transition_disable_count` and `_global_start_transition_disable_count` on `start_transition` and release store by the disabler when enabling transitions again. But I wanted to avoid unnecessary barriers in the virtual thread transition side, so I kept them as plain load/stores with separate memory barriers when necessary.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 307:
> 
>> 305:   // Block while some mount/unmount transitions are in progress.
>> 306:   // Debug version fails and prints diagnostic information.
>> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {
> 
> This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.

Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 316:
> 
>> 314:   // operations to be ordered before we read the transition flags.
>> 315:   // This matches the release fence in end_transition().
>> 316:   OrderAccess::acquire();
> 
> Surely the use of the iterator already provides the necessary ordering guarantee here as well. ?

We still need it because we need to prevent reordering of loads from the critical section with loads of `jt->is_in_VTMS_transition()`.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 327:
> 
>> 325:   // End of the critical section. Prevent previous memory operations to
>> 326:   // be ordered after we clear the clear the disable transition flag.
>> 327:   // This matches the equivalent acquire fence in start_transition().
> 
> Suggestion:
> 
>   // This pairs with the acquire in start_transition().
> 
> I just realized you are using "fence" to describe release and acquire memory barrier semantics. Given we have an operation `fence` I find this confusing for the reader - especially when we also have a `release_store_fence` operation which might be confused with "release fence".

Right, I changed it now to use the terms acquire and release barrier respectively.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 370:
> 
>> 368:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
>> 369:   assert(_global_start_transition_disable_count >= 0, "");
>> 370:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count + 1);
> 
> Suggestion:
> 
>   AtomicAccess::inc(&_global_start_transition_disable_count);

I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 376:
> 
>> 374:   assert(VTMSTransition_lock->owned_by_self() || SafepointSynchronize::is_at_safepoint(), "Must be locked");
>> 375:   assert(_global_start_transition_disable_count > 0, "");
>> 376:   AtomicAccess::store(&_global_start_transition_disable_count, _global_start_transition_disable_count - 1);
> 
> Suggestion:
> 
>   AtomicAccess::dec(&_global_start_transition_disable_count);

Same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561208616
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561210899
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561216984
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561219344
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561219842
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561220292

From pchilanomate at openjdk.org  Tue Nov 25 19:59:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 19:59:38 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <kKSy1-kPPOA0WfhdrgotdulXTT4CiBHkHrPdI5NioHQ=.2f8880e8-cf2b-466e-9753-bf48e3bb5655@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <kKSy1-kPPOA0WfhdrgotdulXTT4CiBHkHrPdI5NioHQ=.2f8880e8-cf2b-466e-9753-bf48e3bb5655@github.com>
Message-ID: <eUSsCOl20vy0nlfE4Mr4gos40j4GY_ELEve_ps1zqf8=.cf011fe7-4a46-4674-84ea-7027ab55e855@github.com>

On Fri, 21 Nov 2025 01:23:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > we follow the classic Dekker pattern for the required synchronization.
> 
> My understanding is that Dekker requires a "full fence" between the accesses, not just ordering memory barriers. The two variables involved must be published to all readers for the algorithm to work.
>
No need to argue too much about this one because `StoreLoad` is implemented as a full fence so we can easily change it, but from reading the definitions in `OrderAccess` my understanding was that technically it should be enough. The `StoreStore` comment clarifies the meaning of word `completes` (used later in `StoreLoad`) as `the effect on memory of Store1 is made visible to other processors`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3577347289

From pchilanomate at openjdk.org  Tue Nov 25 20:10:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:10:56 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v6]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <d04l2qfZFLRC5e5xjgJNoTepCoDXyhOQ7LFumeHwppI=.c98729f0-716f-42d0-b3e5-a7d23183dcf0@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Remove INCLUDE_JVMTI macro

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/b54594c4..4c598ad4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

PR: https://git.openjdk.org/jdk/pull/28361

From pchilanomate at openjdk.org  Tue Nov 25 20:11:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:11:00 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
Message-ID: <MOn89wmjQOY810ISXdV50gVD7tl2HbLbRkSlwr8p99s=.ed872f32-9525-44c1-8ca9-a84b6f7a3fe6@github.com>

On Sat, 22 Nov 2025 07:52:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/javaThread.cpp line 1173:
> 
>> 1171: bool JavaThread::java_suspend(bool register_vthread_SR) {
>> 1172: #if INCLUDE_JVMTI
>> 1173:   // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks.
> 
> Q: I wonder if the `#if INCLUDE_JVMTI` and `#endif` can be removed here.

Yes, removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561254972

From pchilanomate at openjdk.org  Tue Nov 25 20:11:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 20:11:03 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <TKTJ-m3HWmLF_KxPhg2jfA5t4L8jAsTNEy7VZ_Y3QWE=.24244ebe-228d-4f9e-a135-29570178c63f@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <TKTJ-m3HWmLF_KxPhg2jfA5t4L8jAsTNEy7VZ_Y3QWE=.24244ebe-228d-4f9e-a135-29570178c63f@github.com>
Message-ID: <bT9FZIxYJvpmDcDPGo5NJTWBIYjCVZ5ozpjwp964Mb0=.7d5ab663-1aad-44f2-b271-2e84380041e3@github.com>

On Sat, 22 Nov 2025 08:22:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 52:
>> 
>>> 50:   // parameter is_SR: suspender or resumer
>>> 51:   MountUnmountDisabler(bool exlusive = false);
>>> 52:   MountUnmountDisabler(oop thread_oop);
>> 
>> What does the comment mean here?
>
> This comment is stale now and must be removed. The parameter `is_SR` is being replaced with the `exclusive`.

Right, removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561250374

From amenkov at openjdk.org  Tue Nov 25 20:36:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 25 Nov 2025 20:36:15 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v3]
In-Reply-To: <ZgAWlFHCFwF8z3BGA6lhGJaYPWoYa5ZfVuAA0neZZp4=.5dfc6ad7-c141-4642-8e72-515b3d31f432@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <ZgAWlFHCFwF8z3BGA6lhGJaYPWoYa5ZfVuAA0neZZp4=.5dfc6ad7-c141-4642-8e72-515b3d31f432@github.com>
Message-ID: <rXzMh-KNCoRyCXd_5Y0daQQ76LQTPF0Yy_T2JzEk0GE=.1ea3c8b2-3c63-4dc4-b476-95037163d608@github.com>

On Fri, 21 Nov 2025 19:45:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
>> 
>> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
>> The other details will be provided in the first PR request comment.
>> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
>> 
>> Testing:
>>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>>  - submitted mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fix typo in a EATests.java comment

src/hotspot/share/prims/jvmtiThreadState.cpp line 707:

> 705:   for (int idx = 0; idx  < deopts->length(); idx++) {
> 706:     int frame_number = deopts->at(idx);
> 707:     deopts->remove_at(idx);

The code forward iterates the array removing the entries? it will skip every other element (indexes change after removal)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r2561326190

From cjplummer at openjdk.org  Tue Nov 25 20:49:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Nov 2025 20:49:53 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <JI_GbLo65Tp3JkOUTkCaiQNJsW8LMNSI8-fp__5aV4g=.d0b96f3f-ada0-4495-933d-32bfe29f3899@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
 <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>
 <UbRwR_MlVjDzHuBMH-sA7g-f4gpJ-OsxjUAJz_O-P7E=.a8241adb-2d87-4283-9432-ecba479a7c68@github.com>
 <JI_GbLo65Tp3JkOUTkCaiQNJsW8LMNSI8-fp__5aV4g=.d0b96f3f-ada0-4495-933d-32bfe29f3899@github.com>
Message-ID: <qLdoI6mTJt9H2oD_NENHL7vi0ji3ukArM-rERH0l0Qw=.7cff5e5e-74ea-48d4-a7cb-13125808f1a2@github.com>

On Tue, 25 Nov 2025 19:13:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Actually it appears that JDWP THREAD_START can have a filter but JVMTI THREAD_START does not allow you to set the thread to enable the events on. That means when JDWP THREAD_START events are requested and a thread filter is provided, JVMTI THREAD_START needs to be enabled for all threads. That's actually how it is working now. I tried adding the assert and it was triggered. So that means passing "thread" instead of NULL would sometimes end up passing an actual thread to JVMTI and it would produce a [JVMTI_ERROR_ILLEGAL_ARGUMENT in that case.
>
> There  is a bug in the call to eventHandlerRestricted_iterator() at line 1436. For VIRTUAL_THREAD_START I should be explicitly passing in NULL for the thread. Otherwise it will consider the thread when deciding if other event handlers are a match to this one, and I don't think we want that. It could lead to disabling VIRTUAL_THREAD_START events when we shouldn't. Seems we don't have any tests for this but I modified an existing test and got a failure. The test creates a ThreadStartRequest with a thread filter and expects that to trigger a ThreadStartEvent for the filter thread. If I create a second ThreadStartRequest with a filter on a different thread, enable it, and then disable it, that ends up disabling all VIRTUAL_THREAD_START events, and the expected event never arrives. Passing NULL fixes the problem.

Ok, the last problem I pointed out is fixed now. The fix was done in matchHasNoPlatformThreadsOnlyFilter(). I was going to pass NULL for "thread" when ei == EI_THREAD_START, but this turned out not to be enough and changes were also needed in matchHasNoPlatformThreadsOnlyFilter(). Once those changes were in place there was no longer a need to pass NULL for "thread".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561360150

From amenkov at openjdk.org  Tue Nov 25 21:20:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 25 Nov 2025 21:20:14 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
Message-ID: <A0KnwLbOsOkgLnQcWX99PYsf1BSD_cxG2qjqHmBMrhk=.0651a229-da1e-4e76-bbf9-5069c3ae617f@github.com>

On Wed, 19 Nov 2025 23:45:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
> 
> I run jvmti tests with different options and probelmlisted the only failing tests.
> 
> 
> The previous attempt uncover a lot of problems related to the 
> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
> The events might be generated after VM_DEATH event

Need to update copyright yer in agent_tools.cpp
Did you tested it with tiers5-7?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28404#issuecomment-3577626376

From sspitsyn at openjdk.org  Tue Nov 25 22:33:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Nov 2025 22:33:20 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <qLdoI6mTJt9H2oD_NENHL7vi0ji3ukArM-rERH0l0Qw=.7cff5e5e-74ea-48d4-a7cb-13125808f1a2@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <H15KUz37tG_R3nEPfWor5UHqhs430gGse6mIFcW_JVg=.c8593d60-c44b-46ed-8231-a573113c96db@github.com>
 <TNgkOXO--q1wy6pIXg0DkdgerUOlX2lgwiauCaTo0Kw=.ee072957-fad2-4f53-97ee-02a0f518493b@github.com>
 <UbRwR_MlVjDzHuBMH-sA7g-f4gpJ-OsxjUAJz_O-P7E=.a8241adb-2d87-4283-9432-ecba479a7c68@github.com>
 <JI_GbLo65Tp3JkOUTkCaiQNJsW8LMNSI8-fp__5aV4g=.d0b96f3f-ada0-4495-933d-32bfe29f3899@github.com>
 <qLdoI6mTJt9H2oD_NENHL7vi0ji3ukArM-rERH0l0Qw=.7cff5e5e-74ea-48d4-a7cb-13125808f1a2@github.com>
Message-ID: <B9Uj1aBAhIq8gcxggFE0XEPbLfs3Vo3ItrTYmL63ihY=.988d46f9-4b8d-42ef-9b62-f6eb4e28b898@github.com>

On Tue, 25 Nov 2025 20:47:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There  is a bug in the call to eventHandlerRestricted_iterator() at line 1436. For VIRTUAL_THREAD_START I should be explicitly passing in NULL for the thread. Otherwise it will consider the thread when deciding if other event handlers are a match to this one, and I don't think we want that. It could lead to disabling VIRTUAL_THREAD_START events when we shouldn't. Seems we don't have any tests for this but I modified an existing test and got a failure. The test creates a ThreadStartRequest with a thread filter and expects that to trigger a ThreadStartEvent for the filter thread. If I create a second ThreadStartRequest with a filter on a different thread, enable it, and then disable it, that ends up disabling all VIRTUAL_THREAD_START events, and the expected event never arrives. Passing NULL fixes the problem.
>
> Ok, the last problem I pointed out is fixed now. The fix was done in matchHasNoPlatformThreadsOnlyFilter(). I was going to pass NULL for "thread" when ei == EI_THREAD_START, but this turned out not to be enough and changes were also needed in matchHasNoPlatformThreadsOnlyFilter(). Once those changes were in place there was no longer a need to pass NULL for "thread".

Sorry, I know that but keep forgetting that `ThreadStart` can not be thread-filtered. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561717917

From vlivanov at openjdk.org  Tue Nov 25 22:40:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Nov 2025 22:40:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <XTu2dZVoppoRUs-oJ971if55BZ7NONUOKXaum1rAfkw=.9d895fa5-3812-4638-b2f4-68ddcf954978@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3507176880

From sspitsyn at openjdk.org  Tue Nov 25 22:57:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Nov 2025 22:57:29 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v4]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <BN_d5xK1W2g36Ee59r59fgvLo4mx6m2SbrIfVnB0OOU=.d0814b73-794d-412a-9da0-29f326ba74c7@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fix iteration order in process_vthread_pending_deopts as it uses remove_at(idx)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/5989906c..1224d1e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

PR: https://git.openjdk.org/jdk/pull/28407

From sspitsyn at openjdk.org  Tue Nov 25 22:57:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Nov 2025 22:57:32 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v3]
In-Reply-To: <rXzMh-KNCoRyCXd_5Y0daQQ76LQTPF0Yy_T2JzEk0GE=.1ea3c8b2-3c63-4dc4-b476-95037163d608@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <ZgAWlFHCFwF8z3BGA6lhGJaYPWoYa5ZfVuAA0neZZp4=.5dfc6ad7-c141-4642-8e72-515b3d31f432@github.com>
 <rXzMh-KNCoRyCXd_5Y0daQQ76LQTPF0Yy_T2JzEk0GE=.1ea3c8b2-3c63-4dc4-b476-95037163d608@github.com>
Message-ID: <1_e88Ls6a_9rmKaG2GzfU25i0IibBZrWVKILTznSLdI=.ad699183-7c78-4110-9212-7e11bdfa1332@github.com>

On Tue, 25 Nov 2025 20:33:48 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: fix typo in a EATests.java comment
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 707:
> 
>> 705:   for (int idx = 0; idx  < deopts->length(); idx++) {
>> 706:     int frame_number = deopts->at(idx);
>> 707:     deopts->remove_at(idx);
> 
> The code forward iterates the array removing the entries? it will skip every other element (indexes change after removal)

Nice catch, thanks! It is easy to forget about it. Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r2561806700

From pchilanomate at openjdk.org  Tue Nov 25 22:59:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 25 Nov 2025 22:59:59 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  keep preexisting rebind order for mount

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/4c598ad4..dee2b843

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=05-06

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

PR: https://git.openjdk.org/jdk/pull/28361

From duke at openjdk.org  Tue Nov 25 23:10:50 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Nov 2025 23:10:50 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <hOMCRoG0fBNP0LVW9nGwtV13DJskDck_d1pOYeG86cA=.f7332335-e7c6-45f1-8a40-066eafd460be@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

@macarte 
Your change (at version dae852720f1bb1fba43462e1459bada2fd12ef5d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3577970106

From coleenp at openjdk.org  Wed Nov 26 00:01:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:00 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
Message-ID: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>

On Tue, 25 Nov 2025 22:59:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep preexisting rebind order for mount

First read through, mostly questions and plea for comments.    This is a nice refactoring and cleanup of some very difficult code.  You don't have to do the renaming that I requested now if you don't want to.

src/hotspot/share/classfile/javaClasses.cpp line 1688:

> 1686: int java_lang_Thread::_jvmti_thread_state_offset;
> 1687: int java_lang_Thread::_VTMS_transition_disable_count_offset;
> 1688: int java_lang_Thread::_is_in_VTMS_transition_offset;

Since you're renaming these anyway, can we drop the VTMS part?  Just call it vthread_transition_disable_count_offset and is_in_vthread_transition_offset?  There are other VTMS named things that aren't these flags but they can stay.  Maybe migrate other names at some future point.

src/hotspot/share/opto/library_call.cpp line 3046:

> 3044: }
> 3045: 
> 3046: bool LibraryCallKit::inline_native_vthread_start_transition(address funcAddr, const char* funcName, bool is_final_transition) {

Would it be helpful to add a comment above this to say what this does? This is supposed to match some non-intrinsic code and might be helpful if you referenced that here.

src/hotspot/share/prims/jvm.cpp line 3671:

> 3669: 
> 3670: JVM_ENTRY(void, JVM_VirtualThreadStartFinalTransition(JNIEnv* env, jobject vthread))
> 3671:   oop vt = JNIHandles::resolve_external_guard(vthread);

Why do the opto runtime versions set is_in_VTMTS_transition in both the java.lang.Thread and JavaThread and these don't?

src/hotspot/share/prims/jvmtiEnv.cpp line 1827:

> 1825: JvmtiEnv::ClearAllFramePops(jthread thread) {
> 1826:   ResourceMark rm;
> 1827:   MountUnmountDisabler disabler(thread);

Not for this change but I thought JVMTI had some xml code that generated prefixes for these functions.  This seems like something that could be unified somewhere tbd.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1772:

> 1770: 
> 1771:   assert(java_thread != nullptr, "sanity check");
> 1772:   assert(!java_thread->is_in_VTMS_transition(), "sanity check");

Why don't you need these asserts anymore?

src/hotspot/share/runtime/javaThread.cpp line 1152:

> 1150: bool JavaThread::is_in_VTMS_transition() const {
> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
> 1152: }

Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?

src/hotspot/share/runtime/mountUnmountDisabler.hpp line 34:

> 32: 
> 33: class MountUnmountDisabler : public AnyObj {
> 34:   static volatile int _global_start_transition_disable_count;

Can you describe this variable - when is it set and why is there a global disabler? What does it mean to have 'n' active disablers?

A comment at the beginning of MountUnmountDisabler to say something of the effect that during virtual thread mounting and unmounting, JVMTI and operations that need to examine thread state need to be disabled.  Or is it the converse?  During JVMTI and operations that examine the state of threads, virtual thread mounting and unmounting must wait until these operations are complete.  This class is for the latter right?

src/hotspot/share/runtime/mutexLocker.cpp line 52:

> 50: Mutex*   JvmtiThreadState_lock        = nullptr;
> 51: Monitor* EscapeBarrier_lock           = nullptr;
> 52: Monitor* VTMSTransition_lock          = nullptr;

oh you could drop the name VTMS and call it VThreadTransitionLock can't you?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3507302896
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561864174
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561876549
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561897865
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561904709
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561910057
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561926510
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561943253
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561945493

From coleenp at openjdk.org  Wed Nov 26 00:01:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:01 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>

On Tue, 25 Nov 2025 23:32:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep preexisting rebind order for mount
>
> src/hotspot/share/runtime/javaThread.cpp line 1152:
> 
>> 1150: bool JavaThread::is_in_VTMS_transition() const {
>> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
>> 1152: }
> 
> Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?

Why is there the same flag with the same name in both the Java class and C++ JavaThread?  Might be an efficient cache, so something should say that (if true).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561962218

From coleenp at openjdk.org  Wed Nov 26 00:01:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:03 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com>
Message-ID: <G8Y1SK9ja-KTRTf8ZjkrTpP9-BuGT3EE_XR_gNKOgmo=.2fbf4064-83a8-4466-963e-0638e4953b76@github.com>

On Sat, 22 Nov 2025 08:43:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename VM methods for endFirstTransition/startFinalTransition
>
> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 126:
> 
>> 124:          || global_start_transition_disable_count() > base_disable_count
>> 125:          JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended()));
>> 126: }
> 
> I like this approach with the JVMTIStartTransition and JVMTIEndTransition helper classes. It is a nice way to decouple the JVMTI part of the protocol. Introducing the `is_start_transition_disabled()` function was also long desired. Also, I like the functions `start_transition()` and `end_transition()` became pretty simple and clean!

This is the function that needs a comment why you're testing all these things (and why base_disable_count is one for JVMTI). It's nice as a function that tests all the different values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561977191

From coleenp at openjdk.org  Wed Nov 26 00:01:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 00:01:06 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>
Message-ID: <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>

On Tue, 25 Nov 2025 19:50:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 307:
>> 
>>> 305:   // Block while some mount/unmount transitions are in progress.
>>> 306:   // Debug version fails and prints diagnostic information.
>>> 307:   for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) {
>> 
>> This looks very odd, having an assignment in the loop condition check and no actual loop-update expression.
>
> Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)

This could be a simple cleanup of all these occurrences later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2561991623

From vlivanov at openjdk.org  Wed Nov 26 02:05:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Nov 2025 02:05:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <PVq1YxgqFYXhiQ7oZRGOyC06VNJ5XmcnZiHAM-GwoWk=.f8bf35f2-9b1b-4f98-9006-2d3c8787249c@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Test results (hs-tier1 - hs-tier4) are clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3578502574

From macarte at openjdk.org  Wed Nov 26 02:05:07 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 02:05:07 GMT
Subject: Integrated: 8370203 - Add jcmd AOT.end_recording diagnostic command
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <4fjwkhgP8pCO4kV1ZVMlwQ5iGkGsuh79xWZG6ltm_wk=.9d410872-f6b7-48d3-8d83-360a61782827@github.com>

On Thu, 23 Oct 2025 23:57:21 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

This pull request has now been integrated.

Changeset: 65f1ad61
Author:    Mat Carter <macarte at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65f1ad616977428fcb498479132086777dc929cb
Stats:     312 lines in 6 files changed: 312 ins; 0 del; 0 mod

8370203: Add jcmd AOT.end_recording diagnostic command

Reviewed-by: vlivanov, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/27965

From lmesnik at openjdk.org  Wed Nov 26 04:48:17 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Nov 2025 04:48:17 GMT
Subject: RFR: 8372552: unhandled oop in the
 JvmtiEventController::set_user_enabled
Message-ID: <S98YSOSlUjnt1BmanVNsSKreo7inwhlfM-hEJo_lErU=.1c4e3603-0b92-4604-8da6-507afe9252c7@github.com>

The issue reproduced by running test 
vmTestbase/nsk/jvmti/AttachOnDemand/attach022[1]/TestDescription.java
with `-XX:+CheckUnhandledOops`.

No need to flush object free events during VM init. So it is fine to move it after handling the oop.

Testing with tier1-5.

-------------

Commit messages:
 - fixed handling

Changes: https://git.openjdk.org/jdk/pull/28500/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372552
  Stats: 10 lines in 1 file changed: 5 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28500/head:pull/28500

PR: https://git.openjdk.org/jdk/pull/28500

From sspitsyn at openjdk.org  Wed Nov 26 05:05:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Nov 2025 05:05:35 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v5]
In-Reply-To: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
Message-ID: <5i03hZ66IqItuQfklwFP7CxI-LiKvLJ8iOTSLoIhrbo=.02aa02b4-99f3-49f1-976b-2c89781e9199@github.com>

> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
> 
> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
> The other details will be provided in the first PR request comment.
> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
> 
> Testing:
>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>  - submitted mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28407/files
  - new: https://git.openjdk.org/jdk/pull/28407/files/1224d1e2..d82e4efe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=03-04

  Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407

PR: https://git.openjdk.org/jdk/pull/28407

From sspitsyn at openjdk.org  Wed Nov 26 05:30:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Nov 2025 05:30:49 GMT
Subject: RFR: 6960970: Debugger very slow during stepping [v5]
In-Reply-To: <5i03hZ66IqItuQfklwFP7CxI-LiKvLJ8iOTSLoIhrbo=.02aa02b4-99f3-49f1-976b-2c89781e9199@github.com>
References: <gFgkgW9blz_tD337KoxIvOECPeJaQ-LfhifJiaosDjw=.11fda5cd-baae-48bb-a12e-4018eeb5cd15@github.com>
 <5i03hZ66IqItuQfklwFP7CxI-LiKvLJ8iOTSLoIhrbo=.02aa02b4-99f3-49f1-976b-2c89781e9199@github.com>
Message-ID: <2fv251w2Pu7JpU4LNTMbqqNKVf2RL7q-_bJv7eiWMOU=.3f57aac0-58dc-4f1d-9e65-d13b448e58b8@github.com>

On Wed, 26 Nov 2025 05:05:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This change fixes a long standing performance issue related to the debugger single stepping that is using JVMTI `FramePop` events as a part of step over handling. The performance issue is that the target thread continues its execution in very slow `interp-only` mode in a context of frame marked for `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other method calls recursively upon a return from the frame.
>> 
>> This fix is to avoid enforcing the `interp-only` execution mode for threads when `FramePop` events are enabled with the JVMTI `SetEventNotificationMode()`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` optimization by the function `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to @fisk for this suggestion!) Additionally, some tweaks are applied in several places where the `java_thread->is_interp_only_mode()` is checked.
>> The other details will be provided in the first PR request comment.
>> It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed).
>> 
>> Testing:
>>  - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage
>>  - submitted mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: renamed two functions; FRAME_POP_BIT removed from INTERP_EVENT_BITS

We had a walk through the changes with @alexmenkov , @plummercj and @lmesnik and identified several issues:
 - New function `JvmtiExport::has_frame_pop_for_top_frame()` needs a minor performance tweak
 - The changes in `post_method_exit()` are not as precise and correct as needed:
   - call to `get_jvmti_thread_state()` may create a `JvmtiThreadState` object in a case when it is not needed
   - there can be some unreasonable performance overhead
   - there is a concern about possible incorrect handling of the `cur_stack_depth` (need to double check)
- Need to remove the `FRAME_POP_BIT` from the`INTERP_EVENT_BITS` bit mask (**DONE**)
- Decided to rename a couple of new functions (**DONE**):
   - s/`check_and_clear_vthread_pending_deopts`/`clear_vthread_pending_deopts`/g
   - s/`get_vthread_pending_deopts`/`vthread_pending_deopts`/g
- Need some additional test coverage:
   - for multiple `FramePop` requests handled by `process_vthread_pending_deopts()`
   - a test showing a performance improvement with this PR update

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28407#issuecomment-3579240863

From lmesnik at openjdk.org  Wed Nov 26 07:03:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Nov 2025 07:03:31 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
Message-ID: <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>

> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
> 
> I run jvmti tests with different options and probelmlisted the only failing tests.
> 
> 
> The previous attempt uncover a lot of problems related to the 
> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
> The events might be generated after VM_DEATH event

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  copyrightsfixed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28404/files
  - new: https://git.openjdk.org/jdk/pull/28404/files/e4994574..cc51aef8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28404&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28404&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28404/head:pull/28404

PR: https://git.openjdk.org/jdk/pull/28404

From lmesnik at openjdk.org  Wed Nov 26 07:03:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Nov 2025 07:03:31 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <A0KnwLbOsOkgLnQcWX99PYsf1BSD_cxG2qjqHmBMrhk=.0651a229-da1e-4e76-bbf9-5069c3ae617f@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
 <A0KnwLbOsOkgLnQcWX99PYsf1BSD_cxG2qjqHmBMrhk=.0651a229-da1e-4e76-bbf9-5069c3ae617f@github.com>
Message-ID: <BLP7Z0OR9i6azRhbVQSdkn03i9n-kT0CFDdP8QP9jo4=.b4b45adf-1ea9-4572-aca0-0d779c172a70@github.com>

On Tue, 25 Nov 2025 21:17:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Need to update copyright yer in agent_tools.cpp Did you tested it with tiers5-7?

It looks too much overhead to run whole tier5-7 for test fix. So I run nsk/jvmti tests with options from our CI. I grabbed all possible VM flags, hope that I didn't missed anything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28404#issuecomment-3579640195

From dholmes at openjdk.org  Wed Nov 26 07:32:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 07:32:52 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
 <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
Message-ID: <ABARyGqT_r59WYTQ-oyoV0VuXalRJudga_Ft-9lCJ1E=.72b4c700-df57-4f75-a236-4e92b88e0a53@github.com>

On Tue, 25 Nov 2025 19:45:08 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1764:
>> 
>>> 1762:   jint* addr = java_thread->field_addr<jint>(_VTMS_transition_disable_count_offset);
>>> 1763:   int val = AtomicAccess::load(addr);
>>> 1764:   AtomicAccess::store(addr, val - 1);
>> 
>> Suggestion:
>> 
>>   AtomicAccess::dec(addr);
>
> I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.

But it isn't then an atomic update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2563699480

From dholmes at openjdk.org  Wed Nov 26 07:35:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 07:35:49 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v4]
In-Reply-To: <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <vhTZAlugNRnwLQ1m96RLTUp7VJJcIVGA3Z7I6BV2s3A=.9d218187-19a1-49c9-b2de-5014d5a5930f@github.com>
 <wBmoDBE-uYTn5O-_DiDaru-MJcVNxroeRUQuy-wgQ2k=.f288a304-1406-4427-b396-e1f20bf77edb@github.com>
 <WGM9jKBLVj7jzMHIx6DlWSJLBnRd8-AmaVYSf4AbPpM=.c992b90b-8a1b-4d4f-b2bd-9682a9ad3025@github.com>
 <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com>
Message-ID: <dILqkj4lXJ4BFqiA_1bQoNKzH2HGfJkhCgpvrioOI2o=.d1cc45e7-e881-46f1-8174-ce5a4758e3e9@github.com>

On Tue, 25 Nov 2025 23:53:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, from what I see this same construct is used in many places. Seems this is valid because a pointer used in a boolean context evaluates to false if nullptr and true if non-null. :)
>
> This could be a simple cleanup of all these occurrences later.

Yes this is terribly obscure (doing the assignment in the loop condition check - surprised that is even allowed) and also violates the style-guide in relation to implicit booleans. But frankly it is an awful use of a for-loop in my opinion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2563714065

From mbaesken at openjdk.org  Wed Nov 26 10:08:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 10:08:54 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <Siyy3gKJv8ZrULphCk2o1gIpuvr2XR9OkxQyHadSAKw=.9fee039d-cc2b-4652-82e1-8a759869c117@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

For macOS x86_64 it works too at least for some of the libs. See the size without and with dead_strip 


1200 -> 1164    /jdk/lib/libawt_lwawt.dylib
1364 -> 1048    /jdk/lib/libfontmanager.dylib
636  -> 632     /jdk/lib/libfreetype.dylib
240  -> 236     /jdk/lib/libjavajpeg.dylib
280  -> 276     jdk/lib/libjdwp.dylib
92   -> 92      /jdk/lib/libjli.dylib
428  -> 320     /jdk/lib/liblcms.dylib
716  -> 688     /jdk/lib/libmlib_image.dylib
60   -> 60      /jdk/lib/libzip.dylib


For some strange reasons, it does not help on libzip and libjli .
But those are smaller anyway compared to aarch64.  (it is a bit surprising that libzip is twice as large on aarch64 !)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580564402

From serb at openjdk.org  Wed Nov 26 11:03:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Nov 2025 11:03:49 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

I'll run UI the tests for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580783766

From mbaesken at openjdk.org  Wed Nov 26 11:20:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 11:20:52 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
Message-ID: <kfLZ6HfvR5BCrqUZ9UwU4fa9ty3oFTh8Lk1DqtLtqJI=.d2b1a347-0806-497a-92a5-a3ce154d1df9@github.com>

On Wed, 26 Nov 2025 11:01:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I'll run UI the tests for this.

Great, thanks !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580838458

From jbhateja at openjdk.org  Wed Nov 26 11:34:11 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 26 Nov 2025 11:34:11 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v5]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <Vqu9FE4SgvqWFWn0U9718IDFzJviLpKyRyfYc7qrrZ0=.04845f2a-e4f5-4bb5-8f8f-d6bb001ca9c3@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/aca6cc5d..756a0d0c

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=03-04

  Stats: 26 lines in 9 files changed: 5 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From kevinw at openjdk.org  Wed Nov 26 12:04:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Nov 2025 12:04:49 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <tyqT3zZc_ZeRjh5gmNfzlrTbdOdWUdR08YK5yVgbPaI=.7c427f7f-9bb0-4f1a-a599-bac438cb0768@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>
 <tyqT3zZc_ZeRjh5gmNfzlrTbdOdWUdR08YK5yVgbPaI=.7c427f7f-9bb0-4f1a-a599-bac438cb0768@github.com>
Message-ID: <ato8EYQEE-A73tt8Qz0ykCGAVwfY04sQjktivlZftck=.f5e8f85e-af9a-43c8-9c91-c16117f16887@github.com>

On Tue, 25 Nov 2025 12:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java line 192:
>> 
>>> 190:                 HotSpotAOTCacheMXBean impl = this.impl;
>>> 191:                 if (impl == null) {
>>> 192:                     this.impl = impl = new HotSpotAOTCacheImpl(ManagementFactoryHelper.getVMManagement());
>> 
>> This assignment is unusual.  Are we trying to avoid a synchronized block? Other nameToMBeanMap() methods are like:
>> 	return Collections.singletonMap(ManagementFactory.MEMORY_MXBEAN_NAME, ManagementFactoryHelper.getMemoryMXBean());
>> 	
>> ..where the ManagementFactoryHelper.getMemoryMXBean() method is synchronized and creates the impl if needed.
>
> I don't see a correctly issue with this. Maybe in the future we will be able to use LazyConstant here.

Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.

The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.

Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2564720463

From alanb at openjdk.org  Wed Nov 26 12:25:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Nov 2025 12:25:53 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <ato8EYQEE-A73tt8Qz0ykCGAVwfY04sQjktivlZftck=.f5e8f85e-af9a-43c8-9c91-c16117f16887@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>
 <tyqT3zZc_ZeRjh5gmNfzlrTbdOdWUdR08YK5yVgbPaI=.7c427f7f-9bb0-4f1a-a599-bac438cb0768@github.com>
 <ato8EYQEE-A73tt8Qz0ykCGAVwfY04sQjktivlZftck=.f5e8f85e-af9a-43c8-9c91-c16117f16887@github.com>
Message-ID: <UySPCB_21OVz4h7cs8ybBzOoq2wcxfAVvDA2mjkcqAs=.b39d3efa-7983-4ac3-a975-c95673a947ed@github.com>

On Wed, 26 Nov 2025 12:01:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I don't see a correctness issue with this. Maybe in the future we will be able to use LazyConstant here.
>
> Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
> OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.
> 
> The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.
> 
> Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.

The older code pre-dates unmodifiable maps (JEP 269), it could be modernized some time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2564793415

From lucy at openjdk.org  Wed Nov 26 12:42:56 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 26 Nov 2025 12:42:56 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 <AGacEUKglaOEHAh2He4z3f3sXfJjimF8q-2yzLRnlhM=.c14c4fce-8f81-4eb0-8be3-c87caab5f74a@github.com>
Message-ID: <MX59DmwDyi84OR1UlWP5xVnpgTEpuLC-YzGdJ24_diU=.2989a7c3-40f9-44c7-b6bb-5b2c96a4de93@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Looks good, finally. 
Lots of discussion for such a tiny change... :-)

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3510772202

From kevinw at openjdk.org  Wed Nov 26 12:54:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Nov 2025 12:54:50 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v8]
In-Reply-To: <UySPCB_21OVz4h7cs8ybBzOoq2wcxfAVvDA2mjkcqAs=.b39d3efa-7983-4ac3-a975-c95673a947ed@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Tr-Hep5GKs8WK18D22iF09MA78Yf-AqmDN7lnXj7Lzs=.35a44c9a-6bce-4c9a-aa7f-e14051a1d2ec@github.com>
 <gnd9Sv2GjSjugQMEWW5FoKXIg0ibEBDHN33MH3MxHIs=.13b8eda1-50b4-4849-b12c-e65b13800c30@github.com>
 <tyqT3zZc_ZeRjh5gmNfzlrTbdOdWUdR08YK5yVgbPaI=.7c427f7f-9bb0-4f1a-a599-bac438cb0768@github.com>
 <ato8EYQEE-A73tt8Qz0ykCGAVwfY04sQjktivlZftck=.f5e8f85e-af9a-43c8-9c91-c16117f16887@github.com>
 <UySPCB_21OVz4h7cs8ybBzOoq2wcxfAVvDA2mjkcqAs=.b39d3efa-7983-4ac3-a975-c95673a947ed@github.com>
Message-ID: <9nPLu2Fgp-9WizodN4foJP6NA0IvpQGyghqUI-LlzYI=.6560feb6-3c80-4e87-9e85-8c66de78df02@github.com>

On Wed, 26 Nov 2025 12:23:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sure, I'm just pointing out that we have a load of existing nameToMBeanMap() methods that do things differently.
>> OK I now see this one is doing what the new VirtualThreadSchedulerMXBean did.
>> 
>> The others are different: commonly the nameToMBeanMap() methods in PlatformMBeanProviderImpl.java are synchronized, or they call a getXXMXBean() method which is synchronized.
>> 
>> Maybe these old methods don't need to be synchronized, if this all gets done at startup in PlatformMBeanProviderImpl init(), the mbeans will always be created once.
>
> The older code pre-dates unmodifiable maps (JEP 269), it could be modernized some time.

Thanks yes would be good to do that some time.
It looks like an effort with the older accesors to enforce that they are singletons.  That may not be important for all the mxbeans.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2564893489

From macarte at openjdk.org  Wed Nov 26 16:26:04 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 16:26:04 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v9]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <Q_0Zh2DT3wtqNM9_2wCcmIs7zSDUaj-i8qP3SjrNJmI=.6505e456-833a-46b0-b000-8d9968043bf8@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8369736
 - Remove single whitespace
 - Incorporate changes from the CSR
 - Revert "Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording"
   Commit was intended for parent branch (that this branch is based on)
   
   This reverts commit bff7cb7408554232c13a57bba10b67a9fd19b811.
 - Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording
 - Updated test based on comments
 - Merge branch 'JDK-8369736' of https://github.com/macarte/jdk into JDK-8369736
 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga <dan.heidinga at oracle.com>
 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga <dan.heidinga at oracle.com>
 - Wording and format changes
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c028369d...a12bfa03

-------------

Changes: https://git.openjdk.org/jdk/pull/28010/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=08
  Stats: 433 lines in 11 files changed: 338 ins; 0 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From macarte at openjdk.org  Wed Nov 26 20:30:12 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 20:30:12 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v10]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <4yg-7y-d9fzKeFZwZm1KNF6xn2tXGk8y8QaUCk6ly0w=.d0a6ba6b-81a6-482c-9af6-fe3584f2de1d@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate changes to aotMetaspace from dependent commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/a12bfa03..576418a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From macarte at openjdk.org  Wed Nov 26 20:35:11 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 20:35:11 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v11]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <dGQiREV1bRcNuIAhjHDSSsR6369oD24FlT7Ud1U2_ok=.8aa2ac09-dc96-48b0-8de2-e3ca6457386f@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Fixed spaces and CRLF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/576418a6..0086e0ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=09-10

  Stats: 93 lines in 2 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From amenkov at openjdk.org  Wed Nov 26 21:45:46 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 26 Nov 2025 21:45:46 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
 <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
Message-ID: <4LQWpzaYOPCHumgVQTllPpq1KCK5bLqSdNtqGKIwOZ0=.293424ba-427e-4453-a5e7-8955c4c3b5d4@github.com>

On Wed, 26 Nov 2025 07:03:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
>> 
>> I run jvmti tests with different options and probelmlisted the only failing tests.
>> 
>> 
>> The previous attempt uncover a lot of problems related to the 
>> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
>> The events might be generated after VM_DEATH event
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrightsfixed

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28404#pullrequestreview-3512828661

From sspitsyn at openjdk.org  Wed Nov 26 21:45:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Nov 2025 21:45:47 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
 <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
Message-ID: <fJF_ZTru5CbVTTfComEwiTOiAy0QO_wJBd_9f_j9oS0=.14444e00-9622-446f-abf6-f3c3be1e918c@github.com>

On Wed, 26 Nov 2025 07:03:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
>> 
>> I run jvmti tests with different options and probelmlisted the only failing tests.
>> 
>> 
>> The previous attempt uncover a lot of problems related to the 
>> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
>> The events might be generated after VM_DEATH event
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrightsfixed

> It looks too much overhead to run whole tier5-7 for test fix. I grabbed all possible VM flags, hope that I didn't missed anything.

It feels that it would be more safe to run mach5 tiers 1-6. It is not that big overhead for avoiding risk of regressions, especially at this phase of development.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28404#issuecomment-3583294627

From sspitsyn at openjdk.org  Wed Nov 26 22:09:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Nov 2025 22:09:47 GMT
Subject: RFR: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
 <j7Q_g2jp95cOMwQHcqRDJkm_Q1d-4Nikgc8j-ZRJrQo=.a231333d-7226-485d-81f3-5825b89eb187@github.com>
Message-ID: <algMuvGdZV42Z8Q95-lRBhTjW-P055dF_IW_BSMGt1Y=.b9efda42-9e67-44a7-9db8-2624c766e7a5@github.com>

On Wed, 26 Nov 2025 07:03:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
>> 
>> I run jvmti tests with different options and probelmlisted the only failing tests.
>> 
>> 
>> The previous attempt uncover a lot of problems related to the 
>> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
>> The events might be generated after VM_DEATH event
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrightsfixed

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28404#pullrequestreview-3512885811

From lmesnik at openjdk.org  Wed Nov 26 22:19:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Nov 2025 22:19:58 GMT
Subject: Integrated: 8352654: [REDO] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
References: <AUeJqckIh8PeIUYhstgaO9V6WoBSnFP8wwQeyvkNx80=.ea2f7125-255a-45fa-8916-8547fdb78cd0@github.com>
Message-ID: <1noWeDrsHZSXJ06X-8-1qsau_9XHcgzl2a_k5rMcfSE=.12968c19-076a-464e-acc2-cd01a0b8c728@github.com>

On Wed, 19 Nov 2025 23:45:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review second attempt to fail tests right in the nsk_jvmti_setFailStatus().
> 
> I run jvmti tests with different options and probelmlisted the only failing tests.
> 
> 
> The previous attempt uncover a lot of problems related to the 
> [JDK-8355631](https://bugs.openjdk.org/browse/JDK-8355631)
> The events might be generated after VM_DEATH event

This pull request has now been integrated.

Changeset: 847fbab7
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/847fbab7924848e0e88d112db1d5d0b71372d597
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8352654: [REDO] nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/28404

From pchilanomate at openjdk.org  Wed Nov 26 22:34:37 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:34:37 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v8]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <eQ8kVbK9shpQbYTmwml7ANBnaO22l0FNTBVacEuEm64=.9647843c-4dc6-444b-996f-66feda9569b5@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - More changes from Coleen's review
 - Drop VTMS from names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/dee2b843..623bc518

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=06-07

  Stats: 203 lines in 16 files changed: 41 ins; 0 del; 162 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

PR: https://git.openjdk.org/jdk/pull/28361

From pchilanomate at openjdk.org  Wed Nov 26 22:44:17 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:44:17 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
Message-ID: <kETUsDmqtkS5KD5Mqw0DWHtkT3QNXgyusThNkiJeDmY=.653bd243-ef55-4d9c-81f5-4fc9828f28a3@github.com>

> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
> 
> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
> 
> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
> 
> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
> 
> - The code was previously structured in terms of mount and un...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  missing to initialize _is_disabler_at_start

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28361/files
  - new: https://git.openjdk.org/jdk/pull/28361/files/623bc518..7aa02a46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361

PR: https://git.openjdk.org/jdk/pull/28361

From pchilanomate at openjdk.org  Wed Nov 26 22:44:18 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:44:18 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v3]
In-Reply-To: <ABARyGqT_r59WYTQ-oyoV0VuXalRJudga_Ft-9lCJ1E=.72b4c700-df57-4f75-a236-4e92b88e0a53@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <BTGy10eCFCyuEIOZ0AVe96DqzM8gbhTE3yp8w6wHhuc=.bc4f9357-b149-468e-a969-6fcd7982db9e@github.com>
 <r3sF-H1pysREBrzjFGj4GXYqCHrSx9rdqAuITo88mfI=.ee8e8b54-dfe1-40ed-b1ba-7599d4bf920a@github.com>
 <-MtOiSQVDvlQD7sbfeBiqF00_ZN9_aNt3zd2LZLljyo=.eeabb717-359d-4420-89aa-ed1b305beee5@github.com>
 <ABARyGqT_r59WYTQ-oyoV0VuXalRJudga_Ft-9lCJ1E=.72b4c700-df57-4f75-a236-4e92b88e0a53@github.com>
Message-ID: <vXiMHLWWCe77pMKnJu17eQqB5ftkAck6MEgIECJfk2M=.547a9b1e-0ec0-4107-b25c-30d2786ab9ee@github.com>

On Wed, 26 Nov 2025 07:29:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I?d prefer to leave it as a plain store to avoid the unnecessary extra fence.
>
> But it isn't then an atomic update.

Only the disablers write to this counter while holding `VThreadTransition_lock` (verified in the assert above). But we still need to use `AtomicAccess` for the store because it can be concurrently read by the virtual thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566654448

From amenkov at openjdk.org  Wed Nov 26 22:48:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 26 Nov 2025 22:48:52 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>

On Tue, 25 Nov 2025 02:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1296:

> 1294: {
> 1295:     jvmtiError error = JVMTI_ERROR_NONE;
> 1296:     int ei = NODE_EI(node);

Suggestion:

    EventIndex ei = NODE_EI(node);

src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1394:

> 1392:     jvmtiError error2 = JVMTI_ERROR_NONE;
> 1393:     jthread thread;
> 1394:     int ei = NODE_EI(node);

Suggestion:

    EventIndex ei = NODE_EI(node);

src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1691:

> 1689:      * a deferred event request.
> 1690:      */
> 1691:     if (gdata->virtualThreadStartEventsPermanentlyEnabled) {

Looks like this block can disable VITRUAL_THREAD_START when `rememberVThreadsWhenDisconnected` is set.

src/jdk.jdwp.agent/share/native/libjdwp/util.h line 90:

> 88:     jboolean includeVThreads;   /* If true, VM.AllThreads includes vthreads. */
> 89:     jboolean rememberVThreadsWhenDisconnected;
> 90:     jboolean virtualThreadStartEventsPermanentlyEnabled;

Could you please add description for this 2 flags (and maybe `vthreadsSupported` description also can be enhanced to see relations between the flags)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561596843
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561664461
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566654961
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566662313

From pchilanomate at openjdk.org  Wed Nov 26 22:51:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:55 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: <nkiv-uD161ABXR446aJmfavXlgpGUkSoUn7ciurOUL4=.a7b1d499-b363-4ae2-ab7d-77507b890a0f@github.com>

On Tue, 25 Nov 2025 23:10:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep preexisting rebind order for mount
>
> src/hotspot/share/classfile/javaClasses.cpp line 1688:
> 
>> 1686: int java_lang_Thread::_jvmti_thread_state_offset;
>> 1687: int java_lang_Thread::_VTMS_transition_disable_count_offset;
>> 1688: int java_lang_Thread::_is_in_VTMS_transition_offset;
> 
> Since you're renaming these anyway, can we drop the VTMS part?  Just call it vthread_transition_disable_count_offset and is_in_vthread_transition_offset?  There are other VTMS named things that aren't these flags but they can stay.  Maybe migrate other names at some future point.

I dropped VTMS from all names.

> src/hotspot/share/opto/library_call.cpp line 3046:
> 
>> 3044: }
>> 3045: 
>> 3046: bool LibraryCallKit::inline_native_vthread_start_transition(address funcAddr, const char* funcName, bool is_final_transition) {
> 
> Would it be helpful to add a comment above this to say what this does? This is supposed to match some non-intrinsic code and might be helpful if you referenced that here.

Added a comment.

> src/hotspot/share/prims/jvm.cpp line 3671:
> 
>> 3669: 
>> 3670: JVM_ENTRY(void, JVM_VirtualThreadStartFinalTransition(JNIEnv* env, jobject vthread))
>> 3671:   oop vt = JNIHandles::resolve_external_guard(vthread);
> 
> Why do the opto runtime versions set is_in_VTMTS_transition in both the java.lang.Thread and JavaThread and these don't?

Because we set them in the intrinsic when trying to start the transition. Method `MountUnmountDisabler::start_transition` expects them to be false so we need to clear them in the opto versions.

> src/hotspot/share/runtime/mountUnmountDisabler.hpp line 34:
> 
>> 32: 
>> 33: class MountUnmountDisabler : public AnyObj {
>> 34:   static volatile int _global_start_transition_disable_count;
> 
> Can you describe this variable - when is it set and why is there a global disabler? What does it mean to have 'n' active disablers?
> 
> A comment at the beginning of MountUnmountDisabler to say something of the effect that during virtual thread mounting and unmounting, JVMTI and operations that need to examine thread state need to be disabled.  Or is it the converse?  During JVMTI and operations that examine the state of threads, virtual thread mounting and unmounting must wait until these operations are complete.  This class is for the latter right?

Added a comment for the class and this counter.

> src/hotspot/share/runtime/mutexLocker.cpp line 52:
> 
>> 50: Mutex*   JvmtiThreadState_lock        = nullptr;
>> 51: Monitor* EscapeBarrier_lock           = nullptr;
>> 52: Monitor* VTMSTransition_lock          = nullptr;
> 
> oh you could drop the name VTMS and call it VThreadTransitionLock can't you?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566661560
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566662105
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566663466
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566666104
PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566666238

From pchilanomate at openjdk.org  Wed Nov 26 22:51:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:58 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v9]
In-Reply-To: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
Message-ID: <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com>

On Tue, 25 Nov 2025 23:27:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missing to initialize _is_disabler_at_start
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1772:
> 
>> 1770: 
>> 1771:   assert(java_thread != nullptr, "sanity check");
>> 1772:   assert(!java_thread->is_in_VTMS_transition(), "sanity check");
> 
> Why don't you need these asserts anymore?

We can?t assert this because it could be temporarily set by the target while trying to transition. Previously we had two fields in JavaThread, `_VTMS_transition_mark` and `_is_in_VTMS_transition`. `_VTMS_transition_mark` was set first (checked by the disabler), and if transitions were disabled we waited. Once the transition could start we set `_is_in_VTMS_transition`. 
Going over the changes I see I removed one assert in `JvmtiEnvBase::get_vthread_jvf` that should be okay to keep, so I restored it. Also added an assert in `JavaThread::is_in_VTMS_transition()` (now `is_in_vthread_transition`) to verify that if it?s accessed from another thread then it has to be done from a safe context where the value will not change?right after checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566664593

From pchilanomate at openjdk.org  Wed Nov 26 22:51:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 26 Nov 2025 22:51:59 GMT
Subject: RFR: 8364343: Virtual Thread transition management needs to be
 independent of JVM TI [v7]
In-Reply-To: <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <TrGjnbnsryaOcjBTDsAaFD5fZFjMNN0hoX0ARhwz-ME=.210bff76-1605-4e9a-8007-1861b5571894@github.com>
 <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com>
 <zc0-WUDsL6ALYMT-NQD9hMHFy4ZRH6fq7Tr2sD2sK5g=.d15dc9c7-ed0d-4c2f-95c2-7ca0758fde0a@github.com>
Message-ID: <r3l9SBPtgjuunDBP1ao1yUkNBZw2kfca5Nrn3QjiVHY=.2542c262-3bdf-471e-9dab-838b91c18590@github.com>

On Tue, 25 Nov 2025 23:45:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1152:
>> 
>>> 1150: bool JavaThread::is_in_VTMS_transition() const {
>>> 1151:   return AtomicAccess::load(&_is_in_VTMS_transition);
>>> 1152: }
>> 
>> Is the JavaThread version always the same as the java_lang_Thread::is_in_VTMS_transition(threadOop()) value?
>
> Why is there the same flag with the same name in both the Java class and C++ JavaThread?  Might be an efficient cache, so something should say that (if true).

The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2566665257

From cjplummer at openjdk.org  Thu Nov 27 01:06:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Nov 2025 01:06:54 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible
In-Reply-To: <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>
Message-ID: <N7b7ttWwmLt8bJ1vNYujmYfFopZssgyB55FNoO5DbuY=.93a7d7d4-88d7-4632-b9ae-2a429936eec3@github.com>

On Tue, 25 Nov 2025 21:56:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
>> 
>> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
>> 
>> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).
>
> src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1296:
> 
>> 1294: {
>> 1295:     jvmtiError error = JVMTI_ERROR_NONE;
>> 1296:     int ei = NODE_EI(node);
> 
> Suggestion:
> 
>     EventIndex ei = NODE_EI(node);

ok

> src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c line 1394:
> 
>> 1392:     jvmtiError error2 = JVMTI_ERROR_NONE;
>> 1393:     jthread thread;
>> 1394:     int ei = NODE_EI(node);
> 
> Suggestion:
> 
>     EventIndex ei = NODE_EI(node);

ok

> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1691:
> 
>> 1689:      * a deferred event request.
>> 1690:      */
>> 1691:     if (gdata->virtualThreadStartEventsPermanentlyEnabled) {
> 
> Looks like this block can disable VITRUAL_THREAD_START when `rememberVThreadsWhenDisconnected` is set.

virtualThreadStartEventsPermanentlyEnabled is only set true if includeVThreads is false, which means rememberVThreadsWhenDisconnected is also false (they are always set the same, as I discuss in my new comment below).

virtualThreadStartEventsPermanentlyEnabled could use a better name because it means "permanently enabled for handling deferred event enabling", whereas if includeVThreads is true, VITRUAL_THREAD_START events are always permanently enabled, but virtualThreadStartEventsPermanentlyEnabled will never be set true.

> src/jdk.jdwp.agent/share/native/libjdwp/util.h line 90:
> 
>> 88:     jboolean includeVThreads;   /* If true, VM.AllThreads includes vthreads. */
>> 89:     jboolean rememberVThreadsWhenDisconnected;
>> 90:     jboolean virtualThreadStartEventsPermanentlyEnabled;
> 
> Could you please add description for this 2 flags (and maybe `vthreadsSupported` description also can be enhanced to see relations between the flags)

I'm going to get rid of rememberVThreadsWhenDisconnected and just replace references to it with includeVThreads. Right now they are always set the same. I was considering someday making it a flag that could be set on the command line, but I don't seen a need for that anymore. I'd like to get rid of includeVThreads too, but some tests still rely on it. I'll files a CR for all this work soon.

I also plan on getting rid of vthreadsSupported. I doubt setting it to false even works. It's just a remnant from the early days of development of vthread support. It should just always be assumed true now. I'll file a CR for this also.

I'll add some comments for virtualThreadStartEventsPermanentlyEnabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566838053
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566838574
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566837301
PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566825506

From cjplummer at openjdk.org  Thu Nov 27 01:36:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Nov 2025 01:36:25 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v2]
In-Reply-To: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
Message-ID: <QU2EH_9bwcW2X6BvdnsRL6APgfON7tX-0ZvIz_v0bN8=.748c2f13-a232-4fb9-8502-32debd4f14e5@github.com>

> Don't enabled VIRTUAL_THREAD_START/END events unless absolutely necessary. Solves performance issues when trying to debug apps that create a lot of virtual threads. Details in first comment.
> 
> With these changes the Skynet benchmark no longer shows any slowdown when launching with debugging enabled or when attaching the debugger.
> 
> Tested with all tier2, tier3, tier5, and tier6 CI testing (with filters to only run svc tests).

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  use EventIndex type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28485/files
  - new: https://git.openjdk.org/jdk/pull/28485/files/e8b21dba..24010875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28485&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28485&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28485/head:pull/28485

PR: https://git.openjdk.org/jdk/pull/28485

From cjplummer at openjdk.org  Thu Nov 27 01:36:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Nov 2025 01:36:25 GMT
Subject: RFR: 8371380: [LOOM] The debug agent should avoid enabling
 VIRTUAL_THREAD_START/END events when possible [v2]
In-Reply-To: <N7b7ttWwmLt8bJ1vNYujmYfFopZssgyB55FNoO5DbuY=.93a7d7d4-88d7-4632-b9ae-2a429936eec3@github.com>
References: <AWSEdZGXuRJXU41hlG-jy5T4qXBj2s1Vt2yY3KS2uWA=.2d688da5-64b8-48ee-9aff-09dbda4b94aa@github.com>
 <Y39JyZpp2hNEy8G8OPZxYDTSgxAae42Jl55_rOrAB_M=.6d0d280f-1687-4bf5-b2b2-156dac17c37c@github.com>
 <N7b7ttWwmLt8bJ1vNYujmYfFopZssgyB55FNoO5DbuY=.93a7d7d4-88d7-4632-b9ae-2a429936eec3@github.com>
Message-ID: <wuqaPXbGCCYwSv051DmgZ3hHozeIvMgj1yN8a91y378=.b2670ffd-9b81-4320-be80-592fb8272b38@github.com>

On Thu, 27 Nov 2025 00:59:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1691:
>> 
>>> 1689:      * a deferred event request.
>>> 1690:      */
>>> 1691:     if (gdata->virtualThreadStartEventsPermanentlyEnabled) {
>> 
>> Looks like this block can disable VITRUAL_THREAD_START when `rememberVThreadsWhenDisconnected` is set.
>
> virtualThreadStartEventsPermanentlyEnabled is only set true if includeVThreads is false, which means rememberVThreadsWhenDisconnected is also false (they are always set the same, as I discuss in my new comment below).
> 
> virtualThreadStartEventsPermanentlyEnabled could use a better name because it means "permanently enabled for handling deferred event enabling", whereas if includeVThreads is true, VITRUAL_THREAD_START events are always permanently enabled, but virtualThreadStartEventsPermanentlyEnabled will never be set true.

How about virtualThreadStartEventsEnabledForDeferredEventMode?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2566914246

From cjplummer at openjdk.org  Thu Nov 27 06:54:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Nov 2025 06:54:47 GMT
Subject: RFR: 8371194: serviceability/sa/TestJhsdbJstackMixedWithXComp.java
 failing [v3]
In-Reply-To: <Bvma6gov3OZAcOwRHOL2BbTEWQZg-wfF9JV3VgAlYHM=.e5c01b91-a54d-46f4-a5e8-24a260d8b131@github.com>
References: <41mFEzxTY4NaRhF6tQU1o-pDe1eZOkQjiDxpwJSKbOE=.2eb30661-6152-4b27-863c-f97629a464b1@github.com>
 <kdbzxmrJoSRp4IHEa4bdRlXmme-Xdq7cQgtAyKj7WK0=.1f1e93a6-daed-4216-a7d0-04cbb3f123a5@github.com>
 <Bvma6gov3OZAcOwRHOL2BbTEWQZg-wfF9JV3VgAlYHM=.e5c01b91-a54d-46f4-a5e8-24a260d8b131@github.com>
Message-ID: <MXVcTR32JNs8mFf3fk5qXMMG9WQQCiphv0o2Jqse024=.c47dbf6d-4df3-4857-820c-10cccd48d57a@github.com>

On Tue, 25 Nov 2025 11:41:34 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> PING: could you review this?

Sorry I didn't have a chance to get to this yet. I'm on holiday the rest of the week. I should be able to look at it on Monday. I did run your changes through most of our relevant CI testing, and everything passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28284#issuecomment-3584433776

From lmesnik at openjdk.org  Thu Nov 27 20:17:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Nov 2025 20:17:58 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled
Message-ID: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>

The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 

I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 

The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java

Note: 
I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

-------------

Commit messages:
 - 8372039: post_sampled_object_alloc is called while lock is handled

Changes: https://git.openjdk.org/jdk/pull/28544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372039
  Stats: 49 lines in 5 files changed: 8 ins; 30 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28544/head:pull/28544

PR: https://git.openjdk.org/jdk/pull/28544

From lmesnik at openjdk.org  Thu Nov 27 20:53:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 27 Nov 2025 20:53:32 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v2]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <KFmUqx1QPbwWz0r58ET_9ECGgG76o22Fu4092RuQwFw=.08382819-8f24-472e-bb69-a3e59cbd0ff5@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Added regression test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/7662d282..67bcdf11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=00-01

  Stats: 120 lines in 2 files changed: 120 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28544/head:pull/28544

PR: https://git.openjdk.org/jdk/pull/28544

From jnorlinder at openjdk.org  Thu Nov 27 22:01:59 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 22:01:59 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
Message-ID: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>

getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).

The specification for this methods states that only user-level CPU time would ever be returned on success.

-------------

Commit messages:
 - Remove debug pritn
 - Revert to old behaviour

Changes: https://git.openjdk.org/jdk/pull/28545/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372704
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28545/head:pull/28545

PR: https://git.openjdk.org/jdk/pull/28545

From dholmes at openjdk.org  Fri Nov 28 02:50:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Nov 2025 02:50:48 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
In-Reply-To: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
Message-ID: <ICosLkAUS0i9ybYTKvsrvRGOuo2MYCBf8SnAHNYi3sE=.da6516f3-ffc1-4dba-bd89-14484c5e7ad8@github.com>

On Thu, 27 Nov 2025 21:55:10 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
> 
> The specification for this methods states that only user-level CPU time would ever be returned on success.

Good catch on the bug introduced by JDK-8303242! Looks good.

Copyright year needs updating. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28545#pullrequestreview-3517316099

From alanb at openjdk.org  Fri Nov 28 07:40:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 07:40:46 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
In-Reply-To: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
Message-ID: <uKmxfCwU089flGaUHEgkHAhJ2FTUl7npHbU4tGWofIs=.f91f29f7-5234-495f-ba05-44997cd99524@github.com>

On Thu, 27 Nov 2025 21:55:10 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
> 
> The specification for this methods states that only user-level CPU time would ever be returned on success.

Well spotted. We had to make significant changes to this code in JDK 21 with JDK-8303242 and it seems to have crept in then.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28545#pullrequestreview-3517789481

From jnorlinder at openjdk.org  Fri Nov 28 08:42:24 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 08:42:24 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
 [v2]
In-Reply-To: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
Message-ID: <GSGVN36Mz-1BbA67oudatl92VVHZVkfqMWLLanlr8z8=.8fa3ac0e-35f9-4842-88c4-db2c188ac5cc@github.com>

> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
> 
> The specification for this methods states that only user-level CPU time would ever be returned on success.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28545/files
  - new: https://git.openjdk.org/jdk/pull/28545/files/4fdfbaf6..3d541253

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28545&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28545&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28545/head:pull/28545

PR: https://git.openjdk.org/jdk/pull/28545

From kevinw at openjdk.org  Fri Nov 28 08:59:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Nov 2025 08:59:59 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
 [v2]
In-Reply-To: <GSGVN36Mz-1BbA67oudatl92VVHZVkfqMWLLanlr8z8=.8fa3ac0e-35f9-4842-88c4-db2c188ac5cc@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
 <GSGVN36Mz-1BbA67oudatl92VVHZVkfqMWLLanlr8z8=.8fa3ac0e-35f9-4842-88c4-db2c188ac5cc@github.com>
Message-ID: <3n31GMENZUt__tAKCIjKFCfkyt-YO1qUPFiGbi85Nhg=.9ec5f3f5-f130-40b9-bbe0-b28249e4d81a@github.com>

On Fri, 28 Nov 2025 08:42:24 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
>> 
>> The specification for this methods states that only user-level CPU time would ever be returned on success.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28545#pullrequestreview-3517985724

From alanb at openjdk.org  Fri Nov 28 08:59:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 08:59:59 GMT
Subject: RFR: 8372704: ThreadMXBean.getThreadUserTime may return total time
 [v2]
In-Reply-To: <GSGVN36Mz-1BbA67oudatl92VVHZVkfqMWLLanlr8z8=.8fa3ac0e-35f9-4842-88c4-db2c188ac5cc@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
 <GSGVN36Mz-1BbA67oudatl92VVHZVkfqMWLLanlr8z8=.8fa3ac0e-35f9-4842-88c4-db2c188ac5cc@github.com>
Message-ID: <g8ua9jXZY_3HSDgKGIfTquyaTvfBTHJwo1x1gTLrraU=.64fc9fba-49ca-4cd9-9e5c-fb5e85be1475@github.com>

On Fri, 28 Nov 2025 08:42:24 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
>> 
>> The specification for this methods states that only user-level CPU time would ever be returned on success.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28545#pullrequestreview-3517992668

From jnorlinder at openjdk.org  Fri Nov 28 09:00:00 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 09:00:00 GMT
Subject: Integrated: 8372704: ThreadMXBean.getThreadUserTime may return total
 time
In-Reply-To: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
References: <EGNS7J4tP634fWx2NLye0SE0ndWWIHqm5umwghuISag=.66c920cc-d420-4a0e-a733-0217c07a66e5@github.com>
Message-ID: <5o3_tBeSh_i-BrVjhdSej4wzmekb3c6TmQxd_xPuZNs=.f3223ec1-7ecd-46d9-a83b-48368f29f219@github.com>

On Thu, 27 Nov 2025 21:55:10 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> getThreadUserTime will return total (system + user) time if called with e.g. ManagementFactory.getThreadMXBean().getThreadUserTime(Thread.currentThread().threadId()).
> 
> The specification for this methods states that only user-level CPU time would ever be returned on success.

This pull request has now been integrated.

Changeset: 08c16c38
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08c16c384ac9dac22da960ad718ceb95b41ca660
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8372704: ThreadMXBean.getThreadUserTime may return total time

Reviewed-by: alanb, kevinw, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/28545

From mbaesken at openjdk.org  Fri Nov 28 10:31:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Nov 2025 10:31:19 GMT
Subject: RFR: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
Message-ID: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>

In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

-------------

Commit messages:
 - JDK-8372588

Changes: https://git.openjdk.org/jdk/pull/28552/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372588
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28552.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28552/head:pull/28552

PR: https://git.openjdk.org/jdk/pull/28552

From stuefe at openjdk.org  Fri Nov 28 11:51:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 28 Nov 2025 11:51:45 GMT
Subject: RFR: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
In-Reply-To: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
References: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
Message-ID: <185T3PymftcInuQ2LQxry4ly8y_kWvWNJY-glAuEZgA=.18021f9c-dbd0-4187-8a15-8a2aa41b72e4@github.com>

On Fri, 28 Nov 2025 10:23:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

Okay

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28552#pullrequestreview-3518659090

From eosterlund at openjdk.org  Fri Nov 28 13:12:54 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Nov 2025 13:12:54 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v2]
In-Reply-To: <KFmUqx1QPbwWz0r58ET_9ECGgG76o22Fu4092RuQwFw=.08382819-8f24-472e-bb69-a3e59cbd0ff5@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <KFmUqx1QPbwWz0r58ET_9ECGgG76o22Fu4092RuQwFw=.08382819-8f24-472e-bb69-a3e59cbd0ff5@github.com>
Message-ID: <P3qp38XH7vPTY-MrUgxcqgB7V8AHVTSF4LC9pN36xuE=.16156891-1e10-485e-b313-e9588c61dfad@github.com>

On Thu, 27 Nov 2025 20:53:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added regression test

This is good, but we also use the _is_disable_suspend flag to disable JVMTI events for similar reasons, but only from the AOT thread. Now that we have a better more explicit boolean for disabling JVMTI events, perhaps we should stop toggling the _is_disable_suspend flag on the AOT thread, in favour of using this new more explicit mechanism.

Having said that, if we do, then the disabling mechanism needs to be able to cope with nesting. If you agree, then I don't mind if we want to do that refactoring separately from this fix though. The fix looks good otherwise.

-------------

Changes requested by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3518962513

From azeller at openjdk.org  Fri Nov 28 14:12:49 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 28 Nov 2025 14:12:49 GMT
Subject: RFR: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
In-Reply-To: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
References: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
Message-ID: <QvHM6a3BqjFVuq29ICs09elRaakHmoUUM8IF2cdngPI=.62717186-c38b-4375-afe3-dc37a2c1d355@github.com>

On Fri, 28 Nov 2025 10:23:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

Marked as reviewed by azeller (Author).

Looks good to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28552#pullrequestreview-3519141750
PR Comment: https://git.openjdk.org/jdk/pull/28552#issuecomment-3589483266

From cnorrbin at openjdk.org  Fri Nov 28 15:11:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 28 Nov 2025 15:11:00 GMT
Subject: RFR: 8372615: Many container tests fail when running rootless on
 cgroup v1
Message-ID: <vMiWENH7dMmRw5miQHPYNnETLlwMgklDZyGxk_JCPu4=.a98f9e35-3bb4-4aaf-b89b-a2547c4e6f29@github.com>

Hi everyone,

Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`.

To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime).

To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits.

Testing:
* Oracle tiers 1-5
* Local testing:
  - `hotspot/jtreg/containers/` 
  - `jdk/jdk/internal/platform/docker/`
on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations

-------------

Commit messages:
 - resource limit availability checks on container tests

Changes: https://git.openjdk.org/jdk/pull/28557/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372615
  Stats: 63 lines in 21 files changed: 32 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28557.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28557/head:pull/28557

PR: https://git.openjdk.org/jdk/pull/28557

From lmesnik at openjdk.org  Fri Nov 28 20:50:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Nov 2025 20:50:32 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v3]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <fT37Clffh15O_8FUHyL9NRbH59KN4uJ1VXHeoeLxPIs=.1fa2578d-8878-48c1-bde0-d130ed8081f7@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  update jvmti disabling in the AOT thread

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/67bcdf11..1c070dc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28544/head:pull/28544

PR: https://git.openjdk.org/jdk/pull/28544

From lmesnik at openjdk.org  Fri Nov 28 21:09:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Nov 2025 21:09:24 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
Message-ID: <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>

> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
> 
> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
> 
> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
> 
> Note: 
> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  made jvmti_events_disalber as counter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28544/files
  - new: https://git.openjdk.org/jdk/pull/28544/files/1c070dc7..f7e869b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28544&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28544/head:pull/28544

PR: https://git.openjdk.org/jdk/pull/28544

From lucy at openjdk.org  Fri Nov 28 21:44:45 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 28 Nov 2025 21:44:45 GMT
Subject: RFR: 8372588: [asan] serviceability/sa/TestJmapCore.java and
 TestJmapCoreMetaspace.java fail after recent improvements
In-Reply-To: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
References: <QO3gAKCuvuuIO-Um590XSAX8bd1oHFegZrnL-iwe_dk=.14716201-211a-4dbf-bd54-8af1c0ec4dcd@github.com>
Message-ID: <d4LOPh6CZ0G_vB30GHftFQJOxVeWX9rXbYg07cEFvY0=.fe5bcc09-ef5c-4720-9759-3e7b3a78ad67@github.com>

On Fri, 28 Nov 2025 10:23:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the 2 core related tests TestJmapCore.java and TestJmapCoreMetaspace.java we run into the errors below when using asan-enabled binaries. This is most likely because we do not write cores any more with asan; seems to be related to [JDK-8368365](https://bugs.openjdk.org/browse/JDK-8368365) .

Looks good.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28552#pullrequestreview-3520113492

From eosterlund at openjdk.org  Fri Nov 28 22:50:48 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Nov 2025 22:50:48 GMT
Subject: RFR: 8372039: post_sampled_object_alloc is called while lock is
 handled [v4]
In-Reply-To: <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
References: <UmK9h-k8eDPiD32Xg16Oy5LKZ3v53L0saObiSLVT01M=.6f40435f-205f-4309-b610-04110571f3a3@github.com>
 <UvDf93Ksz_ykKylF7FKC2O7xHi8zw9HKSD1xaoL360g=.dee4b184-5fc4-477a-906a-b9762d9c6ff7@github.com>
Message-ID: <pZ9i5b1FUOCZkZY-gn97BhwvAWetUBbAMe7lHYA8uRY=.e8292b29-a6c1-492e-85a5-911288e12cd5@github.com>

On Fri, 28 Nov 2025 21:09:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The AOT allocates objects while holding lock. The jvmti events can't be posted in such case. The allocation sampling might be just temporary disabled while AOT objects are allocated. 
>> 
>> I prefer to disable jvmti events for allocation only, not for AOT globally. If there are more events should be generated during AOT initialization, we might want to preserve them and post after initialization is completed. 
>> 
>> The existing failure could be reproduced by running tests with jvmti stress agent and ZGC enabled. Like
>> make run-test JTREG_JVMTI_STRESS_AGENT=debugger=true TEST=gc/z/TestGarbageCollectorMXBean.java
>> 
>> Note: 
>> I prelaced NoJvmtiVMObjectAllocMark, it was not used. Also it was incorrect. The 
>> NoJvmtiEventsMark should be set even if jvmti events are not enable for this thread. Since jvmti events might be enabled just in the middle of the mark.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made jvmti_events_disalber as counter

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28544#pullrequestreview-3520191286