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