From dholmes at openjdk.org  Mon Feb  2 02:14:06 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Feb 2026 02:14:06 GMT
Subject: RFR: 8373367: interp-only mechanism fails to work for carrier
 threads in a corner case [v3]
In-Reply-To: <vhbGSOm1m9j1cm-FxG3Hv_QW8mpVw_T8SWflx-6HxT0=.52b8a864-86f8-41b3-965c-f7dfdccaa721@github.com>
References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com>
 <vhbGSOm1m9j1cm-FxG3Hv_QW8mpVw_T8SWflx-6HxT0=.52b8a864-86f8-41b3-965c-f7dfdccaa721@github.com>
Message-ID: <rp_LdS9tesqo6LnrBY7w-b6Jk7hu9kXEBtrOkIZA3M0=.b869aeca-5af5-42e1-9a05-ec0878f11d59@github.com>

On Fri, 30 Jan 2026 07:45:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant.
>> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the  `JvmtiThreadState` ctor.
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved and extended comment in JvmtiThreadState ctor

I appreciate the expanded comments but I still don't fully understand what `_thread` and `_saved_thread` point to at different times. The lifecycle of these fields really needs to be clearly described somewhere.

A couple of typos are present - see below. Thanks

src/hotspot/share/prims/jvmtiThreadState.cpp line 61:

> 59: 
> 60:   // The _thread field is a link to the JavaThread associated with JvmtiThreadState.
> 61:   // The _thread_saved field is used for carrier threads only when a virtual thread,

Suggestion:

  // The _thread_saved field is used for carrier threads only when a virtual thread

src/hotspot/share/prims/jvmtiThreadState.cpp line 65:

> 63:   // Carrier and virtual threads can temporarily share same JavaThread. In such a case,
> 64:   // only virtual _thread should have a link from JvmtiThreadState to JavaThread.
> 65:   // The carrier thread _thread filed is set to nullptr if a virtual thread is monted.

Suggestion:

  // The carrier thread _thread field is set to nullptr if a virtual thread is mounted.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29436#pullrequestreview-3737008826
PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2752276119
PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2752275470

From ysuenaga at openjdk.org  Mon Feb  2 06:40:06 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 2 Feb 2026 06:40:06 GMT
Subject: RFR: 8374469: Mixed jstack does not work on Windows [v8]
In-Reply-To: <3N5B8NlV17gaWQIOfbZpzkRxDIwUUZALIxr-hv1L-v0=.b9838ea3-3106-48b2-9889-87acb667c4d0@github.com>
References: <SOyGfX2suuLSAVSlMVmvC2avS1GK9NljSh8Q8whG7zw=.3abf46ad-aa7d-4cf7-b3e8-dc3c0cd968ca@github.com>
 <3N5B8NlV17gaWQIOfbZpzkRxDIwUUZALIxr-hv1L-v0=.b9838ea3-3106-48b2-9889-87acb667c4d0@github.com>
Message-ID: <9BW5aJ3kV4PbAesRg90DZw1-Ze3Iiy_7dGKE54UjrVc=.7bd0665d-9ea6-4453-9e07-f779ec3a3abb@github.com>

On Fri, 23 Jan 2026 03:06:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> When we run `jhsdb jstack --mixed` on Windows, we can see top of call frames only as following:
>> 
>> 
>> ----------------- 4 -----------------
>> "main" #3 prio=5 tid=0x0000021ee0357e90 nid=22356 waiting on condition [0x0000004ae7eff000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007ffca3c41c44 ntdll!NtWaitForSingleObject + 0x14
>> ----------------- 5 -----------------
>> 
>> 
>> This is long standing bugs since JDK 9 at least (maybe this includes older JDK releases).
>> We cannot depend on base pointer to unwind call frames, but SA do that.
>> 
>> This PR use [GetStackTrace](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugcontrol-getstacktrace) to find caller frame, then native call frames would be unwinded.
>> 
>> However it has still problems for JIT'ed frames because it does not have a hint for unwinder like [RtlAddFunctionTable](https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable). But it would affect entire of JIT compilers, so I've limited the change to SA.
>> 
>> This change passed serviceability/sa tests on Windows 11.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract the owner thread retrieval function

PING: Can I get second reviewer? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/29019#issuecomment-3833251357

From ysuenaga at openjdk.org  Mon Feb  2 06:41:04 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 2 Feb 2026 06:41:04 GMT
Subject: RFR: 8376052: Use AttachOperationFailedException rather than
 AttachNotSupportedException in findTargetProcessTmpDirectory() [v3]
In-Reply-To: <Yr6EK6_BuaQ9yFtowEv7U9QMjmIixy3J9br2hnul1NA=.61430f44-b4e6-4c82-8d61-cedd225768a6@github.com>
References: <evB9QDFPTEtUD1kT-BBmzcqXSxisULjrwaBnt3R5tTs=.17519e5e-2a97-44be-9432-f2d3a5e978ed@github.com>
 <Yr6EK6_BuaQ9yFtowEv7U9QMjmIixy3J9br2hnul1NA=.61430f44-b4e6-4c82-8d61-cedd225768a6@github.com>
Message-ID: <-b4xlxeF_UpxhyoKVWrDLZD6srszSxDLx7X_LTBDUHg=.17e38a7f-eaf1-45a7-9440-61f069295071@github.com>

On Sun, 25 Jan 2026 11:02:32 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8373867](https://bugs.openjdk.org/browse/JDK-8373867) improves the logic to find tmp directory for using in attaching procedure. It might throw `IOException` or `AttachNotSupportedException` when it failed.
>> 
>> In review thread #28867, we reached conclusion we should use `AttachOperationFailedException` rather than `AttachNotSupportedException` because `AttachNotSupportedException` would be thrown when a compatible AttachProvider does not exist.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update comments in findTargetProcessTmpDirectory()
>  - Throw AssertionError when URISyntaxException happens at findTargetProcessTmpDirectory()

PING: Can I get second reviewer? CSR for this PR has been already approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/29355#issuecomment-3833254016

From aartemov at openjdk.org  Mon Feb  2 08:23:54 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 2 Feb 2026 08:23:54 GMT
Subject: Integrated: 8366659: ObjectMonitor::wait() liveness problem with a
 suspension request
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <j6nfFvu4bXF5ZL0zdyE9cc4dYoafNwDuxgwMR4Bk51w=.1ff18d68-a7d8-4b08-8d97-af845dbffd33@github.com>

On Tue, 2 Sep 2025 08:10:32 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 following liveness issues can happen in the `ObjectMonitor::wait()` method.
> 
> 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 three 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
> 
> 3:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1951
> 
> 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. 
> 
> Case 3 is handled by not transferring a thread to the `entry_list` in `notify_internal()` in case the corresponding JVMTI event is allowed. Instead, a tread is unparked and let run. Since it is not on the `entry_list`, it will not be chosen as a successor and it is no harm to suspend it if needed when posting the event. 
> 
> Possible issue of posting a `waited` event while still be suspended is addressed by adding a suspension check just before the posting of event.
> 
> Tests are added.
> 
> Tested in tiers 1 - 7.

This pull request has now been integrated.

Changeset: 1f3fd3da
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f3fd3da1d24118a29d28f01d3fa59d7712607e5
Stats:     1390 lines in 9 files changed: 903 ins; 437 del; 50 mod

8366659: ObjectMonitor::wait() liveness problem with a suspension request

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Co-authored-by: Daniel D. Daugherty <dcubed at openjdk.org>
Reviewed-by: dcubed, sspitsyn, dholmes, pchilanomate

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

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

From mbaesken at openjdk.org  Mon Feb  2 12:51:32 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 12:51:32 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
Message-ID: <1EEdtXLniIshhnjOfBislr1nXmV0_xMMDeuB0MmJguA=.a98f3c41-6ed5-4ca6-9830-ff7ae64cc81a@github.com>

On Sat, 31 Jan 2026 01:15:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
>> 
>> 
>> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
>> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
>> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> at java.base/java.lang.Thread.run(Thread.java:1516)
>> 
>> 
>> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
>> See JBS for details.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comments regarding debuginfo retrieval

So without nm/readelf tools , we get potentially a RuntimeException and fail is that correct ?
Should we better skip the test in case the tools are not available ?

Btw. the PR fixed our issues on Alpine, so I think it is a good thing!

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

PR Comment: https://git.openjdk.org/jdk/pull/29480#issuecomment-3834923538
PR Comment: https://git.openjdk.org/jdk/pull/29480#issuecomment-3834929290

From ysuenaga at openjdk.org  Mon Feb  2 13:22:07 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 2 Feb 2026 13:22:07 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <1EEdtXLniIshhnjOfBislr1nXmV0_xMMDeuB0MmJguA=.a98f3c41-6ed5-4ca6-9830-ff7ae64cc81a@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
 <1EEdtXLniIshhnjOfBislr1nXmV0_xMMDeuB0MmJguA=.a98f3c41-6ed5-4ca6-9830-ff7ae64cc81a@github.com>
Message-ID: <mAg9lUMqRnUoUqaEJdHCP0RdxRZgJbri0mgFTq0egpc=.bb2286cd-76a5-4b20-b809-512649db1c9e@github.com>

On Mon, 2 Feb 2026 12:47:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So without nm/readelf tools , we get potentially a RuntimeException and fail is that correct ?

Yes, we would see RuntimeException which has IOException as the cause.
According to Javadoc, IOException would be thrown when the error happens at `ProcessBuilder.start()`.

However I guess we wouldn't see RuntimeException in most case because both `nm` and `readelf` are provided by binutils, and it seems to be required in make/devkit/Tools.gmk.
(In addition, gcc package in Fedora requires binutils)

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

PR Comment: https://git.openjdk.org/jdk/pull/29480#issuecomment-3835080199

From cjplummer at openjdk.org  Mon Feb  2 18:26:11 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Feb 2026 18:26:11 GMT
Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
In-Reply-To: <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com>
References: <uuIlp_hOYph6-tswXgMWQZmLvfaCcjYSK0jqCQNeDVI=.b7b4c883-7910-40a5-a810-c30a25f52f17@github.com>
 <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com>
Message-ID: <QR_AgEeX1oudrue-om6uDx9kpheOrZ-wU93NuOGjz5I=.4788b43d-c57e-4782-a823-0a43f1b33048@github.com>

On Mon, 26 Jan 2026 07:31:44 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) has introduced to treat signal trampoline. It realized to unwind problematic frame from signal trampoline.
>> However it would fail if problematic frame is optimized by compiler - it means FDE (Frame Description Entry) of the function is NOP only.
>> 
>> 
>> 00000018 0000000000000010 0000001c FDE cie=00000000 pc=0000000000000200..0000000000000206
>>   DW_CFA_nop
>>   DW_CFA_nop
>>   DW_CFA_nop
>> 
>> 
>> Actually we can see following stacks and exception as following in TestJhsdbJstackMixedCore.java:
>> 
>> 
>> 0x00007f14d500204d      os::abort(bool, void const*, void const*) [clone .co
>> ld] + 0x4
>> 0x00007f14d6bd0001      VMError::report_and_die(int, char const*, char const
>> *, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char c
>> onst*, int, unsigned long) + 0x6f1
>> 0x00007f14d6bd07b9      VMError::report_and_die(Thread*, unsigned int, unsig
>> ned char*, void const*, void const*, char const*, ...) + 0x88
>> 0x00007f14d6bd0818      VMError::report_and_die(Thread*, unsigned int, unsig
>> ned char*, void const*, void const*) + 0x58
>> 0x00007f14d68ff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007f14d7964290      <signal handler called>
>> 0x00007f14d780b3a0      Java_jdk_test_lib_apps_LingeredApp_crash
>> 0x00007f14be7468ba
>> ----------System.err:(20/1429)----------
>> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because the return value of "sun.jvm.hotspot.runtime.Frame.getFP()" is null
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.addressOfStackSlot(Frame.java:255)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.amd64.AMD64Frame.addressOfInterpreterFrameMethod(AMD64Frame.java:532)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.getInterpreterFrameMethod(Frame.java:389)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InterpretedVFrame.getMethod(InterpretedVFrame.java:36)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.getJavaNames(PStack.java:251)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:135)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun....
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring for simplifying

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29398#pullrequestreview-3741180762

From cjplummer at openjdk.org  Mon Feb  2 18:26:13 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Feb 2026 18:26:13 GMT
Subject: RFR: 8376264: Mixed jstack could not unwind optimized frame [v2]
In-Reply-To: <tjRDH00rVgbsEv1o5h-bdLVpNGNBhX3vt4g8Es0rv1g=.d9d039d5-dfee-4768-adea-ffdb46704b85@github.com>
References: <uuIlp_hOYph6-tswXgMWQZmLvfaCcjYSK0jqCQNeDVI=.b7b4c883-7910-40a5-a810-c30a25f52f17@github.com>
 <2qQ8HeuGVPeW_025qUeL0l0nHzJUIWViRiucVMk3VOM=.8c856b6a-f446-4226-ae71-35bb5859ec27@github.com>
 <cJDmRHrM6unt9HBzXH_iLV_GdJwFyy-1OQz6f5I1Px0=.f1d92ca8-14aa-4508-a1ee-396b6e1b72c1@github.com>
 <Gth_rUAWv8m5zhvLqe89p2r2F_v4IA97fHK9-_By5zA=.72a35d08-79b7-444d-9bce-2fbec445e3a1@github.com>
 <tjRDH00rVgbsEv1o5h-bdLVpNGNBhX3vt4g8Es0rv1g=.d9d039d5-dfee-4768-adea-ffdb46704b85@github.com>
Message-ID: <v9d8Z6pq-R9opUOQY9ycsk72TiJ2JpV88XbPKm7J3M8=.571891f5-e03a-445a-befc-5dee2419b9ec@github.com>

On Thu, 29 Jan 2026 03:43:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> Remember states can be stacked, but your implementation only supports one push onto the state stack. I suppose you did this because you never saw a case where the stack was more than one deep.
>> 
>> Yes.
>> Remember states should be stacked, but I haven't seen that case. So I implemented to save (push) once so far.
>> I can fix it, but I want to do it in subsequent PR (for AArch64) because I will update register offset handling for generalization.
>
> Yes, a separate PR would be best.

Thinking about this a bit more, it's probably ok to continue to just support a 1 deep stack since that is all we'll likely every see. But if there is ever a second "push", an error should be produced, and if we ever see that error then we can then improve the stack handling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29398#discussion_r2755673651

From cjplummer at openjdk.org  Mon Feb  2 19:15:39 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Feb 2026 19:15:39 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <TbCCihcM_r0IxtIr7Bf3cXoijI7ulHWCgzSh57fR4Tw=.39a56dcb-4269-4402-a59c-342360f5c554@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <DkU3ia5H7pUNaeVZAe19C1XvGceXXxEWXCCIUItnONM=.466627ba-2c8f-49ab-b769-f9de134817ae@github.com>
 <TbCCihcM_r0IxtIr7Bf3cXoijI7ulHWCgzSh57fR4Tw=.39a56dcb-4269-4402-a59c-342360f5c554@github.com>
Message-ID: <QFR0kJ6G2ElDihrzhWOxZciHJ9v9Zr-3fObik5xqU-Y=.69b3e102-9e56-45c0-969d-1bb4e9a67613@github.com>

On Sat, 31 Jan 2026 01:08:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 71:
>> 
>>> 69:         // Check whether the symbol of signal trampoline is available.
>>> 70:         var libc = SATestUtils.getLibCPath();
>>> 71:         if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) {
>> 
>> Do we have any reason to support the lookup of symbols not in libc? I'm just wondering if `SATestUtils.isSymbolAvailable()` should just take the symbol argument not the libc argument.
>
> I want to use `isSymbolAvailable()` in JDK-8376269 (PR #29400) to find the symbol relates to `gettimeofday()` in vDSO.
> (so I defined `getDebugInfo(()` as public to check vDSO debuginfo availability)

ok

>> test/lib/jdk/test/lib/SA/SATestUtils.java line 345:
>> 
>>> 343:     }
>>> 344: 
>>> 345:     private static boolean isSymbolAvailableInternal(String lib, String symbol) throws IOException {
>> 
>> Should `lib` be named something more like `debugInfoPath`?
>
> This function is used for finding symbol from lib (not debuginfo) in L361.

Ok. I see now it is called in two places, once with a lib path and once with a debuginfo path. And nm refers to the argument as `objfile`, but makes no mention of what format `objfile` can be (presumably .o, .so, .debuginfo, or executable).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2755598410
PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2755618737

From cjplummer at openjdk.org  Mon Feb  2 19:15:43 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Feb 2026 19:15:43 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
Message-ID: <MeRB96Y_Bb2mgX62v5DLo8likAcdkvMj7EUu4tDxdog=.f04e6e76-f8bc-4998-be88-9c15034e6544@github.com>

On Sat, 31 Jan 2026 01:15:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
>> 
>> 
>> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
>> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
>> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> at java.base/java.lang.Thread.run(Thread.java:1516)
>> 
>> 
>> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
>> See JBS for details.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comments regarding debuginfo retrieval

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 72:

> 70:         var libc = SATestUtils.getLibCPath();
> 71:         if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) {
> 72:             throw new SkippedException("Signal trampoline (__restore_rt) not found in libc.");

I think you should clarify with a comment here that the presence of the __restore_rt trampoline is what triggers SA to generate the frame with the name "<signal handler called>", and if the __restore_rt symbol does not exist, then SA will not know to call the frame  "<signal handler called>".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2755834642

From cjplummer at openjdk.org  Mon Feb  2 19:46:01 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Feb 2026 19:46:01 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <MeRB96Y_Bb2mgX62v5DLo8likAcdkvMj7EUu4tDxdog=.f04e6e76-f8bc-4998-be88-9c15034e6544@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
 <MeRB96Y_Bb2mgX62v5DLo8likAcdkvMj7EUu4tDxdog=.f04e6e76-f8bc-4998-be88-9c15034e6544@github.com>
Message-ID: <R3cSp-RgKfVcnKaB2_5STt-ufg7j2OpJMuW9RQxJtNI=.661d1d45-6fb3-4929-b059-d30819da736a@github.com>

On Mon, 2 Feb 2026 19:11: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:
>> 
>>   Clarify comments regarding debuginfo retrieval
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 72:
> 
>> 70:         var libc = SATestUtils.getLibCPath();
>> 71:         if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) {
>> 72:             throw new SkippedException("Signal trampoline (__restore_rt) not found in libc.");
> 
> I think you should clarify with a comment here that the presence of the __restore_rt trampoline is what triggers SA to generate the frame with the name "`<signal handler called>`", and if the __restore_rt symbol does not exist, then SA will not know to call the frame  "`<signal handler called>`".

...and maybe SA should generate the frame as "__restore_rt <signal handler called\>" or "__restore_rt <signal handler trampoline\>".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2755914781

From ysuenaga at openjdk.org  Tue Feb  3 00:29:16 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 00:29:16 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v4]
In-Reply-To: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
Message-ID: <TyCeTgCFd-t7HNpOe8in4MQZPtt8J1VuueAPnQFRJqc=.135bd590-54db-4d7f-b7bb-5b3beb7b24ca@github.com>

> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
> 
> 
> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
> See JBS for details.

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

  Update the symbol for signal trampoline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29480/files
  - new: https://git.openjdk.org/jdk/pull/29480/files/1913d6bb..68530e4a

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

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

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

From ysuenaga at openjdk.org  Tue Feb  3 00:29:17 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 00:29:17 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v3]
In-Reply-To: <R3cSp-RgKfVcnKaB2_5STt-ufg7j2OpJMuW9RQxJtNI=.661d1d45-6fb3-4929-b059-d30819da736a@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <WnRx5-0F99KsA2Qok01hRSrBo24WduyRz7L2v49tmsA=.c83ea2e5-43e9-4848-8932-b00f59fb26a6@github.com>
 <MeRB96Y_Bb2mgX62v5DLo8likAcdkvMj7EUu4tDxdog=.f04e6e76-f8bc-4998-be88-9c15034e6544@github.com>
 <R3cSp-RgKfVcnKaB2_5STt-ufg7j2OpJMuW9RQxJtNI=.661d1d45-6fb3-4929-b059-d30819da736a@github.com>
Message-ID: <VqL3VlJlTN5JpU41HxMXPhrTBVueWHlCk_6wfnPxnXY=.6f1aca78-00f8-4374-aee5-663cabbc1d29@github.com>

On Mon, 2 Feb 2026 19:43:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java line 72:
>> 
>>> 70:         var libc = SATestUtils.getLibCPath();
>>> 71:         if (!SATestUtils.isSymbolAvailable(libc, "__restore_rt")) {
>>> 72:             throw new SkippedException("Signal trampoline (__restore_rt) not found in libc.");
>> 
>> I think you should clarify with a comment here that the presence of the __restore_rt trampoline is what triggers SA to generate the frame with the name "`<signal handler called>`", and if the __restore_rt symbol does not exist, then SA will not know to call the frame  "`<signal handler called>`".
>
> ...and maybe SA should generate the frame as "__restore_rt <signal handler called\>" or "__restore_rt <signal handler trampoline\>".

I updated to show `__restore_rt <signal trampoline>` for signal trampoline, and also I added comments for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29480#discussion_r2756571945

From cjplummer at openjdk.org  Tue Feb  3 03:04:01 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Feb 2026 03:04:01 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v4]
In-Reply-To: <TyCeTgCFd-t7HNpOe8in4MQZPtt8J1VuueAPnQFRJqc=.135bd590-54db-4d7f-b7bb-5b3beb7b24ca@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <TyCeTgCFd-t7HNpOe8in4MQZPtt8J1VuueAPnQFRJqc=.135bd590-54db-4d7f-b7bb-5b3beb7b24ca@github.com>
Message-ID: <6BPYL4rlDY7LPlIlR-iE8yTVfQI3iMw24nLjydDlIpw=.7d446483-919d-4be1-ad12-935235219fe1@github.com>

On Tue, 3 Feb 2026 00:29:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
>> 
>> 
>> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
>> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
>> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> at java.base/java.lang.Thread.run(Thread.java:1516)
>> 
>> 
>> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
>> See JBS for details.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the symbol for signal trampoline

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29480#pullrequestreview-3742668845

From mbaesken at openjdk.org  Tue Feb  3 08:29:10 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 08:29:10 GMT
Subject: RFR: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine [v4]
In-Reply-To: <TyCeTgCFd-t7HNpOe8in4MQZPtt8J1VuueAPnQFRJqc=.135bd590-54db-4d7f-b7bb-5b3beb7b24ca@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
 <TyCeTgCFd-t7HNpOe8in4MQZPtt8J1VuueAPnQFRJqc=.135bd590-54db-4d7f-b7bb-5b3beb7b24ca@github.com>
Message-ID: <z3X0AaoB-fCQecP-TYcQuKYWijxHSB_uyTz-uBCC4ZU=.9e708072-9d17-4995-b92c-6c5926f33b91@github.com>

On Tue, 3 Feb 2026 00:29:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
>> 
>> 
>> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
>> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
>> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> at java.base/java.lang.Thread.run(Thread.java:1516)
>> 
>> 
>> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
>> See JBS for details.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the symbol for signal trampoline

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29480#pullrequestreview-3743787665

From sspitsyn at openjdk.org  Tue Feb  3 09:20:55 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Feb 2026 09:20:55 GMT
Subject: RFR: 8373367: interp-only mechanism fails to work for carrier
 threads in a corner case [v3]
In-Reply-To: <rp_LdS9tesqo6LnrBY7w-b6Jk7hu9kXEBtrOkIZA3M0=.b869aeca-5af5-42e1-9a05-ec0878f11d59@github.com>
References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com>
 <vhbGSOm1m9j1cm-FxG3Hv_QW8mpVw_T8SWflx-6HxT0=.52b8a864-86f8-41b3-965c-f7dfdccaa721@github.com>
 <rp_LdS9tesqo6LnrBY7w-b6Jk7hu9kXEBtrOkIZA3M0=.b869aeca-5af5-42e1-9a05-ec0878f11d59@github.com>
Message-ID: <5reQqFFmFv9fMfLlNkBbrK_M7KwSrhsJ7N8IR4Fl-zs=.ecaf046d-23f1-42b9-9fcf-99226efa5826@github.com>

On Mon, 2 Feb 2026 02:06:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: moved and extended comment in JvmtiThreadState ctor
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 61:
> 
>> 59: 
>> 60:   // The _thread field is a link to the JavaThread associated with JvmtiThreadState.
>> 61:   // The _thread_saved field is used for carrier threads only when a virtual thread,
> 
> Suggestion:
> 
>   // The _thread_saved field is used for carrier threads only when a virtual thread

Good catches, thanks! Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2758063991

From sspitsyn at openjdk.org  Tue Feb  3 09:29:06 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Feb 2026 09:29:06 GMT
Subject: RFR: 8373367: interp-only mechanism fails to work for carrier
 threads in a corner case [v4]
In-Reply-To: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com>
References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com>
Message-ID: <AW5cdnDG143YQN6zM4Rj_Xqfb8dU3mdCOOTNie3tDtY=.4187e186-378e-4cee-8cf9-ce89d9cff9b4@github.com>

> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and virtual threads can temporary share the same `JavaThread`. The `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a back link to the `JavaThread` which is also set for virtual thread at a `mount` and carrier thread at an `unmount`. Just one of these two links at the same time is set to the `JavaThread`, the other one has to be set to `nullptr`. The `interp-only` mechanism needs this invariant.
> However, there is a corner case when this invariant is broken. It happens when the `JvmtiThreadState` for carrier thread has just been created. In such case, the link to `JavaThread` is always `non-nullptr` even though a virtual thread is currently mounted on a carrier thread. This simple update fixes the issue in the  `JvmtiThreadState` ctor.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fixed minor typos in newly added comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29436/files
  - new: https://git.openjdk.org/jdk/pull/29436/files/e5735668..65784f93

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

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

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

From sspitsyn at openjdk.org  Tue Feb  3 09:29:08 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Feb 2026 09:29:08 GMT
Subject: RFR: 8373367: interp-only mechanism fails to work for carrier
 threads in a corner case [v3]
In-Reply-To: <rp_LdS9tesqo6LnrBY7w-b6Jk7hu9kXEBtrOkIZA3M0=.b869aeca-5af5-42e1-9a05-ec0878f11d59@github.com>
References: <4kL5ukI7hOKtKX0zkyc6K_7RMq3v1t_fJdvdwvmXfsw=.60ebbe1d-0133-4bff-953c-db953eed86db@github.com>
 <vhbGSOm1m9j1cm-FxG3Hv_QW8mpVw_T8SWflx-6HxT0=.52b8a864-86f8-41b3-965c-f7dfdccaa721@github.com>
 <rp_LdS9tesqo6LnrBY7w-b6Jk7hu9kXEBtrOkIZA3M0=.b869aeca-5af5-42e1-9a05-ec0878f11d59@github.com>
Message-ID: <jebUZO9rKEaF71gCKQPhTtbZ85cNeQJmQKKc4eQ_Kt8=.09ada366-e0f0-43f9-9634-e2e24d0a3f3d@github.com>

On Mon, 2 Feb 2026 02:11:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I appreciate the expanded comments but I still don't fully understand what _thread and _saved_thread point to at different times. The lifecycle of these fields really needs to be clearly described somewhere.

I had a plan to get rid of the `_saved_thread` filed. I can try to do that in this PR to make it simpler. Removing this field can also simplify the description of the `_thread` field lifecycle. Please, let me try to do this first.

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

PR Comment: https://git.openjdk.org/jdk/pull/29436#issuecomment-3840113575

From ysuenaga at openjdk.org  Tue Feb  3 09:47:12 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 09:47:12 GMT
Subject: Integrated: 8376284: New test
 serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on
 Linux Alpine
In-Reply-To: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
References: <6bbPeHZuFjI80_fe85tbvnzod_RjZOfG9WEV3i9EkB4=.6be720da-aa3f-4612-b124-19accd31b070@github.com>
Message-ID: <BWn48X-qBk3g68LnuVTytlKKcSsntQlFs0oUmaXxBBI=.606e8284-e829-45a2-a133-2eda7cc77ec9@github.com>

On Thu, 29 Jan 2026 06:20:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> TestJhsdbJstackMixedCore.java introduced in [JDK-8374482](https://bugs.openjdk.org/browse/JDK-8374482) failed on Alpine because musl-c does not provide the symbol of signal trampoline (`__restore_rt` on Linux Kernel for AMD64) as following:
> 
> 
> java.lang.RuntimeException: '<signal handler called>' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
> at TestJhsdbJstackMixedCore.runJstackMixed(TestJhsdbJstackMixedCore.java:62)
> at TestJhsdbJstackMixedCore.main(TestJhsdbJstackMixedCore.java:74)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> at java.base/java.lang.Thread.run(Thread.java:1516)
> 
> 
> It would success if debuginfo is installed, but it should be skipped if the symbol is not available.
> See JBS for details.

This pull request has now been integrated.

Changeset: 9c83dff8
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c83dff811c038ba8b20a9781ea3ac0f4f95b1b9
Stats:     130 lines in 3 files changed: 125 ins; 0 del; 5 mod

8376284: New test serviceability/sa/TestJhsdbJstackMixedCore.java from JDK-8374482 fails on Linux Alpine

Reviewed-by: cjplummer, mbaesken

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

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

From ysuenaga at openjdk.org  Tue Feb  3 10:24:43 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 10:24:43 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
Message-ID: <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>

> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
> 
> 
> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
> 0x00007faae4ad9290      <signal handler called>
> 0x00007faae4cd8e69              ????????
> 0x00007faaca78ffa1      <nep_invoker_blob>
> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
> 
> 
> It should be:
> 
> 
> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
> 0x00007fb584fd9290      <signal handler called>
> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
> 0x00007fb56a78f321      <nep_invoker_blob>
> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
> 
> 
> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.

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

 - Update testcase to skip if kernel debuginfo is not available
 - Merge branch 'master' into JDK-8376269
 - Add new function to handle vDSO
 - Remove unneeded change
 - Remove 32 bit support
 - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
   
   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
 - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
   
   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
 - 8376269: Mixed jstack cannot find function in vDSO

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29400/files
  - new: https://git.openjdk.org/jdk/pull/29400/files/38daaa32..264250a9

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

  Stats: 49993 lines in 766 files changed: 23834 ins; 16528 del; 9631 mod
  Patch: https://git.openjdk.org/jdk/pull/29400.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29400/head:pull/29400

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

From ysuenaga at openjdk.org  Tue Feb  3 10:24:45 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 10:24:45 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v3]
In-Reply-To: <KO-OANcxSa2hBSgUKNGTirs8vWA8BaRWmHQET7QZAk4=.0033fcf7-2c46-4592-bd04-777f42a8e9cb@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <KO-OANcxSa2hBSgUKNGTirs8vWA8BaRWmHQET7QZAk4=.0033fcf7-2c46-4592-bd04-777f42a8e9cb@github.com>
Message-ID: <R3guAnZBQ3cROnjCnMquAISFjMwm7lYULEoUbPjlCdA=.073561bb-5660-4dc2-be61-d7b6eac02c9a@github.com>

On Thu, 29 Jan 2026 01:28:02 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
>> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
>> 
>> 
>> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007faae4ad9290      <signal handler called>
>> 0x00007faae4cd8e69              ????????
>> 0x00007faaca78ffa1      <nep_invoker_blob>
>> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> It should be:
>> 
>> 
>> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007fb584fd9290      <signal handler called>
>> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
>> 0x00007fb56a78f321      <nep_invoker_blob>
>> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.
>
> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add new function to handle vDSO
>  - Remove unneeded change
>  - Remove 32 bit support

I've updated this PR to run TestJhsdbJstackMixedWithVDSOCallCore.java intdoduced in this PR if kernel debuginfo is available only. Otherwise the test would be skipped.
@plummercj Could you review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3840428338

From ysuenaga at openjdk.org  Tue Feb  3 10:25:30 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 3 Feb 2026 10:25:30 GMT
Subject: RFR: 8374577: Heap dump from core does not contain
 HPROF_GC_ROOT_JAVA_FRAME [v3]
In-Reply-To: <dmnUb_sT1Okmp2XTEa2x3Venrg4YZUoLG1BdejUDiV8=.2c3db891-cc86-4473-81b5-d69b7e296aa6@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
 <dmnUb_sT1Okmp2XTEa2x3Venrg4YZUoLG1BdejUDiV8=.2c3db891-cc86-4473-81b5-d69b7e296aa6@github.com>
Message-ID: <-zQ3ta_QEkxcjwnAPcAq8iAEZdsTQn6MU7-1eaNwsLg=.06eac3c1-72d4-43d3-8d1d-d800d86ce9af@github.com>

On Thu, 29 Jan 2026 23:41:33 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack.
>> 
>> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options:
>> 
>> 
>> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError
>> 
>> 
>> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
>> 
>> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
>> 
>> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
>> 
>> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects.
>> 
>> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that.
>> 
>> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d .
>> 
>> This change works fine with both interpreter and `-Xcomp`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapCacheEntry.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

@turbanoff Could you approve this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/29058#issuecomment-3840436823

From kfarrell at openjdk.org  Tue Feb  3 12:05:42 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 3 Feb 2026 12:05:42 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v8]
In-Reply-To: <Z8w6XfsVYyvo1ldK9NAmOuI_7yaZaE94brtu_k94X4k=.63ce087d-cc98-47d8-831e-d78a757d7a15@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rNCHUq-vodKsv9E1Dk6PN6gYJ6mqWFi6gHwuL-BOb_E=.383b606a-1f61-4bec-8265-bcef49e1c8d7@github.com>
 <Z8w6XfsVYyvo1ldK9NAmOuI_7yaZaE94brtu_k94X4k=.63ce087d-cc98-47d8-831e-d78a757d7a15@github.com>
Message-ID: <YvJbeepAL7M4aHXfP4A7dumTn1cdB-9lDRzPyhfzDf8=.fe357c0b-07dd-485e-a448-9a1ed4e80b80@github.com>

On Thu, 29 Jan 2026 09:40:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor updates
>
> src/hotspot/os/linux/os_linux.cpp line 5412:
> 
>> 5410:         timed_out = true;
>> 5411:         break;
>> 5412:       }
> 
> Can you please do a little manual test like this:
> 
> if (fds > some number) sleep(Timeout * 2);
> 
> and check if the timeout works?

the above returns `Open File Descriptors: > (number)` as expected

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2758735078

From mbaesken at openjdk.org  Tue Feb  3 13:36:46 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 13:36:46 GMT
Subject: RFR: 8376956: Add JVMTI phase entering/setting to hserr event log
Message-ID: <I1hDaSidg5EacXhZY3tLAVxyMf2NeAogJmzUuZpHj_c=.bd0ae291-6de8-41f1-b93a-5b4a46e62f9f@github.com>

We should add some info to the hserr/hsinfo event logs about JVMTI phases.

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

Commit messages:
 - JDK-8376956

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

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

From stuefe at openjdk.org  Tue Feb  3 14:17:14 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 3 Feb 2026 14:17:14 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v8]
In-Reply-To: <rNCHUq-vodKsv9E1Dk6PN6gYJ6mqWFi6gHwuL-BOb_E=.383b606a-1f61-4bec-8265-bcef49e1c8d7@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rNCHUq-vodKsv9E1Dk6PN6gYJ6mqWFi6gHwuL-BOb_E=.383b606a-1f61-4bec-8265-bcef49e1c8d7@github.com>
Message-ID: <wWI8H1DXyIQoQYhTHll5lc8_P9ylEFeITcFkhcs8aog=.6046460a-c8fc-4005-9308-c747cabe900b@github.com>

On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
>> 
>> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor updates

src/hotspot/os/bsd/os_bsd.cpp line 2589:

> 2587: #ifdef __APPLE__
> 2588:   const int MAX_SAFE_FDS = 1024;
> 2589:   struct proc_fdinfo fds[MAX_SAFE_FDS];

Hmm, this may be a bad idea. This function is called during signal handling. Don't allocate massive amounts of stack storage here, that may lead to secondary crashes during error handling which we could not recover from.

See below, I am not sure it is even necessary.

src/hotspot/os/bsd/os_bsd.cpp line 2608:

> 2606: 
> 2607:   nfiles = res / sizeof(struct proc_fdinfo);
> 2608:   if (nfiles >= MAX_SAFE_FDS) {

About MAX_SAFE_FDS:

What is really returned by `pid_for_task`? 

If return values > MAX_SAFE_FDS are possible, would that be the reliable "number of open fds" ? If so, why not print that instead of ">1024"? In fact, if so, why even bother returning an array at all, why not make the array 1-element-sized only, pro format? All we are interested in is the number.

src/hotspot/os/bsd/os_bsd.cpp line 2615:

> 2613:   st->print_cr("Open File Descriptors: %d", nfiles);
> 2614: #else
> 2615:     st->print_cr("Open File Descriptors: unknown");

Indentation looks off

Also, the code could be condensed quite a bit.

src/hotspot/os/linux/os_linux.cpp line 5406:

> 5404:     if (isdigit(dentp->d_name[0])) fds++;
> 5405:     if (fds % 100 == 0) {
> 5406:       clock_gettime(CLOCK_MONOTONIC, &now);

You don't query the return code here. If clock_gettime fails, content of `now` is undefined. Could lead to premature abortion of this loop.

If runtime errors are possible, they should be handled; otherwise an assertion would be the right thing to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759298203
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759274151
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759277532
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759289309

From kfarrell at openjdk.org  Tue Feb  3 14:29:33 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 3 Feb 2026 14:29:33 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v9]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <GpsVN7UWYXQB5Ho02llNKs-zd31sgNrjgp4wNxI49JE=.51c6d6d3-bf77-457a-afbc-c57f45dff0c8@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/926fc920..e9ed58ad

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

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

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

From syan at openjdk.org  Tue Feb  3 14:31:20 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 14:31:20 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
Message-ID: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>

Hi all,

This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.

Additional testing:

- [ ] Full jtreg tests include vmTestbase

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

Commit messages:
 - Update comment
 - Remove test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.bak
 - Add "import jdk.test.lib.classloader.ClassUnloadCommon;"
 - Add "import jdk.test.lib.classloader.ClassUnloadCommon;"
 - Replace ClassUnloader as ClassUnloadCommon
 - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter001/TestDescription.java
 - Fix vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/TestDescription.java
 - Fix vmTestbase/nsk/jdi/ReferenceType/fields/fields003/TestDescription.java
 - Fix vmTestbase/nsk/jvmti/ObjectFree/objfree001/TestDescription.java
 - Fix vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e21cb852...458fb127

Changes: https://git.openjdk.org/jdk/pull/29545/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376023
  Stats: 613 lines in 71 files changed: 244 ins; 275 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/29545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29545/head:pull/29545

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

From syan at openjdk.org  Tue Feb  3 15:16:40 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 15:16:40 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted
 [v6]
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <o_M3wQJCxQnux3qoM1-5-rO1Hx9CK3GY8osgG_1zgVs=.4ce470b3-902e-4f84-aa40-c9b760f234e2@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests.
> 
> Change has been verified locally. Test-fix only, no risk.

SendaoYan 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 'openjdk:master' into jbs8374364
 - Update comment "If cgroups is not configured, the test is skipped." which suggestion from @dholmes-ora
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java
 - Check cpu period and cpuset avaialable before test
 - Fix year
 - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester
 - 8374364: TestCgroupMetrics.java fails when docker service unavailable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28996/files
  - new: https://git.openjdk.org/jdk/pull/28996/files/8e2ee419..109302e5

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

  Stats: 130803 lines in 3552 files changed: 62581 ins; 31208 del; 37014 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

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

From cjplummer at openjdk.org  Tue Feb  3 19:46:13 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Feb 2026 19:46:13 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
Message-ID: <kPIH58-05D7X8H7Hoq8-w7uhj5FzlqqrGa-06vSoukU=.5d30e61f-5fbf-46d3-bb5b-fdbcc1affa87@github.com>

On Tue, 3 Feb 2026 10:24:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
>> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
>> 
>> 
>> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007faae4ad9290      <signal handler called>
>> 0x00007faae4cd8e69              ????????
>> 0x00007faaca78ffa1      <nep_invoker_blob>
>> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> It should be:
>> 
>> 
>> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007fb584fd9290      <signal handler called>
>> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
>> 0x00007fb56a78f321      <nep_invoker_blob>
>> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update testcase to skip if kernel debuginfo is not available
>  - Merge branch 'master' into JDK-8376269
>  - Add new function to handle vDSO
>  - Remove unneeded change
>  - Remove 32 bit support
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - 8376269: Mixed jstack cannot find function in vDSO

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29400#pullrequestreview-3747224405

From sspitsyn at openjdk.org  Tue Feb  3 23:43:40 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Feb 2026 23:43:40 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be
In-Reply-To: <X07vsLLAE9Yzbh9LIkD7k_uebrRzzMgGHvCjBv-c8NE=.977647b8-30ce-4120-9cf0-56e5578c51e8@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
 <OPNw8R3EHZ3HUN2yJEpboj9x6fQ25CCS99nVoyVeRIE=.b52dc72a-e947-42c8-abc0-22513b7d0dd0@github.com>
 <X07vsLLAE9Yzbh9LIkD7k_uebrRzzMgGHvCjBv-c8NE=.977647b8-30ce-4120-9cf0-56e5578c51e8@github.com>
Message-ID: <uxUMmic3GsxCCgb9sw9wZHnLJlmOs2WOw0G9A6kF_7g=.2ab7236f-468a-4454-81a3-c7d205ac3087@github.com>

On Fri, 30 Jan 2026 07:08:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 92:
>> 
>>> 90:     assert(!_current->is_suspended() ||
>>> 91:            (_current->is_vthread_transition_disabler() && _result != freeze_ok), "must be");
>>> 92: #endif
>> 
>> Suggestion:
>> 
>>     assert(!_current->is_suspended() 
>>            JVMTI_ONLY(|| (_current->is_vthread_transition_disabler() && _result != freeze_ok))
>>            , "must be");
>> 
>> Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ??
>
>> Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ??
> 
> Good suggestion. JVMTI is the only way to suspend threads.

In fact, we have more suspend/resume related places that could be moved under INCLUDE_JVMTI. Then we may want to do a separate cleanup for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2761515742

From pchilanomate at openjdk.org  Wed Feb  4 00:30:29 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 00:30:29 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be [v2]
In-Reply-To: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
Message-ID: <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>

> Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  apply David suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29473/files
  - new: https://git.openjdk.org/jdk/pull/29473/files/ad4e987c..1b2960c5

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

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

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

From pchilanomate at openjdk.org  Wed Feb  4 00:30:30 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 00:30:30 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be [v2]
In-Reply-To: <uxUMmic3GsxCCgb9sw9wZHnLJlmOs2WOw0G9A6kF_7g=.2ab7236f-468a-4454-81a3-c7d205ac3087@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
 <OPNw8R3EHZ3HUN2yJEpboj9x6fQ25CCS99nVoyVeRIE=.b52dc72a-e947-42c8-abc0-22513b7d0dd0@github.com>
 <X07vsLLAE9Yzbh9LIkD7k_uebrRzzMgGHvCjBv-c8NE=.977647b8-30ce-4120-9cf0-56e5578c51e8@github.com>
 <uxUMmic3GsxCCgb9sw9wZHnLJlmOs2WOw0G9A6kF_7g=.2ab7236f-468a-4454-81a3-c7d205ac3087@github.com>
Message-ID: <SOg4KPi_4r2Pwas8fhqjmHLEhgRfxDXJBd4TL3J0oUg=.00a03719-49f2-41c9-bcea-0640a98876a0@github.com>

On Tue, 3 Feb 2026 23:41:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> Is this a worthwhile distinction? I guess these days the only way to suspend is through JVMTI. ??
>> 
>> Good suggestion. JVMTI is the only way to suspend threads.
>
> In fact, we have more suspend/resume related places that could be moved under INCLUDE_JVMTI. Then we may want to do a separate cleanup for this.

Sounds good, I updated it based on David's suggestion. We can move all suspend code under JVMTI in a separate cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29473#discussion_r2761620112

From sspitsyn at openjdk.org  Wed Feb  4 04:02:27 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 4 Feb 2026 04:02:27 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be [v2]
In-Reply-To: <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
 <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
Message-ID: <60WZxrZET7zrEqfzytnl4kMtzp5qiIJ-vzYm288uA-A=.76207aae-3907-423e-bd14-d1b4a2b02ef0@github.com>

On Wed, 4 Feb 2026 00:30:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply David suggestion

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3748814496

From dholmes at openjdk.org  Wed Feb  4 07:04:02 2026
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Feb 2026 07:04:02 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be [v2]
In-Reply-To: <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
 <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
Message-ID: <wQc31CXLcjgzSz7biNqDVEWomg3JwkkNDVNo5RgnqOA=.e05f2709-5f2a-4250-b023-90f0f4a11784@github.com>

On Wed, 4 Feb 2026 00:30:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply David suggestion

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29473#pullrequestreview-3749338404

From ayang at openjdk.org  Wed Feb  4 08:11:35 2026
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 4 Feb 2026 08:11:35 GMT
Subject: RFR: 8377143: Parallel: Remove special treatment in
 JstatGcCapacityResults.java
Message-ID: <YHWQgTP0PYh7nJadGUp-Guak-EO3KwZWAxYaoj94Q_M=.db15a2cb-a60e-441b-ac34-4d7f10aebb3d@github.com>

Remove the `if (isTenuredParallelGC) {` path in `JstatGcCapacityResults.java` because ParallelGC ensures `NGC == S0C + S1C + EC` like other GCs nowadays.

Test: tier1-5

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

Commit messages:
 - pgc-svc-remove-if-check

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

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

From lucy at openjdk.org  Wed Feb  4 10:09:15 2026
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 4 Feb 2026 10:09:15 GMT
Subject: RFR: 8376956: Add JVMTI phase entering/setting to hserr event log
In-Reply-To: <I1hDaSidg5EacXhZY3tLAVxyMf2NeAogJmzUuZpHj_c=.bd0ae291-6de8-41f1-b93a-5b4a46e62f9f@github.com>
References: <I1hDaSidg5EacXhZY3tLAVxyMf2NeAogJmzUuZpHj_c=.bd0ae291-6de8-41f1-b93a-5b4a46e62f9f@github.com>
Message-ID: <biZwZ--bDxN0XIbzw-23gyiMGcM2-8EGi-IoMHXhWB8=.c26291bc-2b1b-4958-8819-308e6e77111a@github.com>

On Mon, 2 Feb 2026 15:30:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should add some info to the hserr/hsinfo event logs about JVMTI phases.

Looks good.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29525#pullrequestreview-3750136064

From kfarrell at openjdk.org  Wed Feb  4 11:16:55 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 4 Feb 2026 11:16:55 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v8]
In-Reply-To: <wWI8H1DXyIQoQYhTHll5lc8_P9ylEFeITcFkhcs8aog=.6046460a-c8fc-4005-9308-c747cabe900b@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rNCHUq-vodKsv9E1Dk6PN6gYJ6mqWFi6gHwuL-BOb_E=.383b606a-1f61-4bec-8265-bcef49e1c8d7@github.com>
 <wWI8H1DXyIQoQYhTHll5lc8_P9ylEFeITcFkhcs8aog=.6046460a-c8fc-4005-9308-c747cabe900b@github.com>
Message-ID: <jRPDJsXS83vWVS1M9BnvIVF-A6qjZQTTvdtQuWO3Pb8=.c7d90274-4153-488e-a5f2-e3577d533cd0@github.com>

On Tue, 3 Feb 2026 14:07:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor updates
>
> src/hotspot/os/bsd/os_bsd.cpp line 2608:
> 
>> 2606: 
>> 2607:   nfiles = res / sizeof(struct proc_fdinfo);
>> 2608:   if (nfiles >= MAX_SAFE_FDS) {
> 
> About MAX_SAFE_FDS:
> 
> What is really returned by `pid_for_task`? 
> 
> If return values > MAX_SAFE_FDS are possible, would that be the reliable "number of open fds" ? If so, why not print that instead of ">1024"? In fact, if so, why even bother returning an array at all, why not make the array 1-element-sized only, pro format? All we are interested in is the number.

proc_pidinfo allocates a buffer to hold a struct proc_fdinfo for each FD. To avoid using malloc and allocating potentially large amounts of memory in a signal-handling context, we decided to use a pre-allocated struct and read onto that. 

proc_pidinfo will return once the buffer is full, in that case we have to assume the actual number of open FDs is >= 1024

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2763467160

From kfarrell at openjdk.org  Wed Feb  4 11:16:57 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 4 Feb 2026 11:16:57 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v8]
In-Reply-To: <jRPDJsXS83vWVS1M9BnvIVF-A6qjZQTTvdtQuWO3Pb8=.c7d90274-4153-488e-a5f2-e3577d533cd0@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
 <rNCHUq-vodKsv9E1Dk6PN6gYJ6mqWFi6gHwuL-BOb_E=.383b606a-1f61-4bec-8265-bcef49e1c8d7@github.com>
 <wWI8H1DXyIQoQYhTHll5lc8_P9ylEFeITcFkhcs8aog=.6046460a-c8fc-4005-9308-c747cabe900b@github.com>
 <jRPDJsXS83vWVS1M9BnvIVF-A6qjZQTTvdtQuWO3Pb8=.c7d90274-4153-488e-a5f2-e3577d533cd0@github.com>
Message-ID: <LT-NkaowRuYPa6QXiGtzjCP0YMlV9Fq1djwuXK5L5Ks=.ed3a0112-664a-453d-a4b4-e58df98757e5@github.com>

On Wed, 4 Feb 2026 11:12:28 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> src/hotspot/os/bsd/os_bsd.cpp line 2608:
>> 
>>> 2606: 
>>> 2607:   nfiles = res / sizeof(struct proc_fdinfo);
>>> 2608:   if (nfiles >= MAX_SAFE_FDS) {
>> 
>> About MAX_SAFE_FDS:
>> 
>> What is really returned by `pid_for_task`? 
>> 
>> If return values > MAX_SAFE_FDS are possible, would that be the reliable "number of open fds" ? If so, why not print that instead of ">1024"? In fact, if so, why even bother returning an array at all, why not make the array 1-element-sized only, pro format? All we are interested in is the number.
>
> proc_pidinfo allocates a buffer to hold a struct proc_fdinfo for each FD. To avoid using malloc and allocating potentially large amounts of memory in a signal-handling context, we decided to use a pre-allocated struct and read onto that. 
> 
> proc_pidinfo will return once the buffer is full, in that case we have to assume the actual number of open FDs is >= 1024

the only way to count the number of open FDs on macOs is to allocate an array of proc_fdinfo structs and count the total number

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2763476172

From kfarrell at openjdk.org  Wed Feb  4 11:26:46 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 4 Feb 2026 11:26:46 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v10]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <m_bPbkSD_-pO1yzlENCPS9iRohE7X_PlLS-N7MGaN2s=.4ff480cf-c07a-47c8-8d1b-6b1cac59d21a@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  assertions for clock_gettime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/e9ed58ad..cf54d9f9

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

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

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

From kevinw at openjdk.org  Wed Feb  4 12:23:28 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Feb 2026 12:23:28 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
Message-ID: <N7s-yIqaX0YkVJIpi7oVwkPTCCE2wQUXvd8_WtN7ZJ8=.7d41d4c3-0253-49c9-9dfb-6134cb124185@github.com>

On Tue, 3 Feb 2026 10:24:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
>> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
>> 
>> 
>> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007faae4ad9290      <signal handler called>
>> 0x00007faae4cd8e69              ????????
>> 0x00007faaca78ffa1      <nep_invoker_blob>
>> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> It should be:
>> 
>> 
>> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007fb584fd9290      <signal handler called>
>> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
>> 0x00007fb56a78f321      <nep_invoker_blob>
>> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update testcase to skip if kernel debuginfo is not available
>  - Merge branch 'master' into JDK-8376269
>  - Add new function to handle vDSO
>  - Remove unneeded change
>  - Remove 32 bit support
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - 8376269: Mixed jstack cannot find function in vDSO

OK great, I see I have the vdso file in /lib/modules on my Oracle Linux, so that should work for me also.  Added a couple of questions, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3847125286

From ysuenaga at openjdk.org  Wed Feb  4 14:06:20 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 4 Feb 2026 14:06:20 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <N7s-yIqaX0YkVJIpi7oVwkPTCCE2wQUXvd8_WtN7ZJ8=.7d41d4c3-0253-49c9-9dfb-6134cb124185@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
 <N7s-yIqaX0YkVJIpi7oVwkPTCCE2wQUXvd8_WtN7ZJ8=.7d41d4c3-0253-49c9-9dfb-6134cb124185@github.com>
Message-ID: <0fSEmj6XQaDCK_BR2pRTziRC8aIRF_tr7YSckVMoy10=.04427808-0e5c-416a-85ec-0299d1f1721d@github.com>

On Wed, 4 Feb 2026 12:20:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Update testcase to skip if kernel debuginfo is not available
>>  - Merge branch 'master' into JDK-8376269
>>  - Add new function to handle vDSO
>>  - Remove unneeded change
>>  - Remove 32 bit support
>>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>>    
>>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>>    
>>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>>  - 8376269: Mixed jstack cannot find function in vDSO
>
> OK great, I see I have the vdso file in /lib/modules on my Oracle Linux, so that should work for me also.  Added a couple of questions, thanks.

@kevinjwalls Could you share your questions again? I cannot see them...

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

PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3847653108

From kevinw at openjdk.org  Wed Feb  4 14:58:17 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Feb 2026 14:58:17 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
Message-ID: <gKmQgnKimlgB7j7NoFOR-dU4B_Ev-a1D8Mf4e9AY-tI=.41da95e9-05a2-4ac9-9594-3b61e8dc5a64@github.com>

On Tue, 3 Feb 2026 10:24:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
>> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
>> 
>> 
>> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007faae4ad9290      <signal handler called>
>> 0x00007faae4cd8e69              ????????
>> 0x00007faaca78ffa1      <nep_invoker_blob>
>> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> It should be:
>> 
>> 
>> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
>> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
>> 0x00007fb584fd9290      <signal handler called>
>> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
>> 0x00007fb56a78f321      <nep_invoker_blob>
>> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
>> 
>> 
>> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update testcase to skip if kernel debuginfo is not available
>  - Merge branch 'master' into JDK-8376269
>  - Add new function to handle vDSO
>  - Remove unneeded change
>  - Remove 32 bit support
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - 8376269: Mixed jstack cannot find function in vDSO

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 609:

> 607: // Otherwise copy vDSO memory in coredump to temporal memory generated by memfd_create().
> 608: // Returns FD for vDSO (should be closed by caller).
> 609: static int handle_vdso(struct ps_prochandle* ph, char* lib_name, size_t lib_name_len) {

handle_vdso is called with: handle_vdso(ph, lib_name, sizeof(lib_name)):

Was it meant to pass strlen(lib_name)? 
But lib_name here is from the linker info, so that is the short name "linux-vdso.so.1" ?
handle_vdso then mallocs something of the same size, but snprintfs something much longer?   We should just allocate a reasonable sized buffer to create vdso_path, and maybe we don't need the lib_name_len parameter.

Then handle_vdso checks /lib/modules... exists, and then opens it with pathmap_open?  So it has to exist without pathmap, but may also be in the SA_ALTROOT directory.
Should handle_vdso also try pathmap_open() first?

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 732:

> 730: 
> 731:       if (lib_name[0] != '\0') { // ignore empty lib names
> 732:          if (strcmp("linux-vdso.so.1", lib_name) == 0 ||

Could we check this lib is at the VDSO address, so we know for sure it's the one and only system vdso?
 link_map_addr + LINK_MAP_ADDR_OFFSET == ps_prochandle->core->vdso_addr
Could do that instead of the name check, or in addition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2763722155
PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2763636696

From kevinw at openjdk.org  Wed Feb  4 14:58:12 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Feb 2026 14:58:12 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <0fSEmj6XQaDCK_BR2pRTziRC8aIRF_tr7YSckVMoy10=.04427808-0e5c-416a-85ec-0299d1f1721d@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
 <N7s-yIqaX0YkVJIpi7oVwkPTCCE2wQUXvd8_WtN7ZJ8=.7d41d4c3-0253-49c9-9dfb-6134cb124185@github.com>
 <0fSEmj6XQaDCK_BR2pRTziRC8aIRF_tr7YSckVMoy10=.04427808-0e5c-416a-85ec-0299d1f1721d@github.com>
Message-ID: <A2LYQ_EU9xTRIN3popyYHbqs8Ky4ahNpJNM2UVXQGnE=.2074b50a-10e1-44c1-8fa7-fffe4af09406@github.com>

On Wed, 4 Feb 2026 14:03:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> OK great, I see I have the vdso file in /lib/modules on my Oracle Linux, so that should work for me also.  Added a couple of questions, thanks.
>
> @kevinjwalls Could you share your questions again? I cannot see them...

@YaSuenag oops, had not "submitted" my review/comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/29400#issuecomment-3847942415

From pchilanomate at openjdk.org  Wed Feb  4 15:20:24 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 15:20:24 GMT
Subject: RFR: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be [v2]
In-Reply-To: <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
 <5AbHw4FfafR0jkXTNdgWKeOD6Zm_0WwqWORsSzNdBdM=.2a27b8d8-edf4-4c58-a4d4-b850e139f52f@github.com>
Message-ID: <CE1ZBe15OrkI7BX8IFn452lAba1r-RrHBXuugvIkTcE=.362a5797-7621-4e78-aae1-7485053eec89@github.com>

On Wed, 4 Feb 2026 00:30:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply David suggestion

Thanks for the reviews David and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/29473#issuecomment-3848056734

From pchilanomate at openjdk.org  Wed Feb  4 15:23:07 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 15:23:07 GMT
Subject: Integrated: 8376405: Virtual thread crash:
 assert(!_current->is_suspended()) failed: must be
In-Reply-To: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
References: <RBEY1Nz8FkN5x9WwExarw0yIoS11JA0eS1gwuKaY0vE=.ef4043f0-8d39-4bff-879d-ccd5f8ef1a05@github.com>
Message-ID: <cEFcP-ZTtdilkuTE1Aon2w7WtbRcG0AUuFRQLm--VOo=.5f731eed-bbb8-4d3f-a748-90bdc83a0973@github.com>

On Wed, 28 Jan 2026 21:56:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. In 8375362 we skipped the suspend check in `MountUnmountDisabler::start_transition` for transition disablers to avoid deadlocks, but that means we also need to update the assert in `~UnmountBeginMark()`. I was able to reproduce the crash locally using ThreadStateTest2.java and confirmed it is now fixed.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: d49e29aa
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d49e29aa8c88a0f966446de4288f32a529f0dd52
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8376405: Virtual thread crash: assert(!_current->is_suspended()) failed: must be

Reviewed-by: sspitsyn, dholmes

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

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

From sspitsyn at openjdk.org  Wed Feb  4 18:51:15 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 4 Feb 2026 18:51:15 GMT
Subject: RFR: 8376956: Add JVMTI phase entering/setting to hserr event log
In-Reply-To: <I1hDaSidg5EacXhZY3tLAVxyMf2NeAogJmzUuZpHj_c=.bd0ae291-6de8-41f1-b93a-5b4a46e62f9f@github.com>
References: <I1hDaSidg5EacXhZY3tLAVxyMf2NeAogJmzUuZpHj_c=.bd0ae291-6de8-41f1-b93a-5b4a46e62f9f@github.com>
Message-ID: <qvXE0cYt0wO3WBU2DklZuVq_6ZfX__XKdjzGb_9xpmw=.ee00a5b9-e855-46ca-abb4-d9328e16055c@github.com>

On Mon, 2 Feb 2026 15:30:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should add some info to the hserr/hsinfo event logs about JVMTI phases.

Marked as reviewed by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiExport.cpp line 822:

> 820:   }
> 821: 
> 822:   Events::log(Thread::current_or_null(), "JVMTI - dead phase");

Nit: Maybe "enter dead phase" to make it consistent with other lines above.

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

PR Review: https://git.openjdk.org/jdk/pull/29525#pullrequestreview-3752768918
PR Review Comment: https://git.openjdk.org/jdk/pull/29525#discussion_r2765500354

From ysuenaga at openjdk.org  Thu Feb  5 00:53:22 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 5 Feb 2026 00:53:22 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <gKmQgnKimlgB7j7NoFOR-dU4B_Ev-a1D8Mf4e9AY-tI=.41da95e9-05a2-4ac9-9594-3b61e8dc5a64@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
 <gKmQgnKimlgB7j7NoFOR-dU4B_Ev-a1D8Mf4e9AY-tI=.41da95e9-05a2-4ac9-9594-3b61e8dc5a64@github.com>
Message-ID: <WlBH479XnNzc-9qoXq7zWWRdtsWov51lYvn3UjnbOQ4=.cd8d1e38-89ea-4e03-9eb1-f32cabf885cc@github.com>

On Wed, 4 Feb 2026 11:56:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Update testcase to skip if kernel debuginfo is not available
>>  - Merge branch 'master' into JDK-8376269
>>  - Add new function to handle vDSO
>>  - Remove unneeded change
>>  - Remove 32 bit support
>>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>>    
>>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>>  - Update src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>>    
>>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>>  - 8376269: Mixed jstack cannot find function in vDSO
>
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 732:
> 
>> 730: 
>> 731:       if (lib_name[0] != '\0') { // ignore empty lib names
>> 732:          if (strcmp("linux-vdso.so.1", lib_name) == 0 ||
> 
> Could we check this lib is at the VDSO address, so we know for sure it's the one and only system vdso?
>  link_map_addr + LINK_MAP_ADDR_OFFSET == ps_prochandle->core->vdso_addr
> Could do that instead of the name check, or in addition.

I think it is better to compare with `lib_base` like this:

         if (lib_base == ph->core->vdso_addr) {
           lib_fd = handle_vdso(ph, lib_name, sizeof(lib_name));
         } else {

However it is difficult because `lib_base` is calculated in subsequent code with program header in ELF (in `find_base_address`).

Maybe we can use `lib_base_diff` at here because debug log says virtual address for vDSO is same with vaddr in `l_addr` in `struct link_map` as following, but I'm not sure.

libsaproc DEBUG: first link map is at 0x7fa08970d2f0
libsaproc DEBUG: replace vDSO: linux-vdso.so.1 -> /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so
libsaproc DEBUG: reading library /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so @ 0x7fa0896d2000 [ 0x7fa0896d2000 ]
libsaproc DEBUG: overwrote with new address mapping (memsz 8192 -> 8192)
libsaproc DEBUG: /lib/modules/6.18.6-200.fc43.x86_64/vdso/vdso64.so [0] 0x7fa0896d2000-0x7fa0896d4000: base = 0x7fa0896d2000, vaddr = 0x0, memsz = 0x1883, filesz = 0x1883

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2766575815

From ysuenaga at openjdk.org  Thu Feb  5 01:08:21 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 5 Feb 2026 01:08:21 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v5]
In-Reply-To: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
Message-ID: <81b29T29mAyF5I-ccW0od5Hp-c_sg-1HTPzITmpr5ZM=.9d8258ba-1c43-4b35-b7c7-e7a82351cac0@github.com>

> Some functions / signal trampoline would be provided by vDSO in Linux. However SA cannot find symbols in it because it is not a regular ELF, it is on the memory only.
> For example, mixed jstack could not decode the symbol in the coredump crashed in gettimeofday(2) as following:
> 
> 
> 0x00007faae3dd0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
> 0x00007faae3aff1ba      JVM_handle_linux_signal + 0x42a
> 0x00007faae4ad9290      <signal handler called>
> 0x00007faae4cd8e69              ????????
> 0x00007faaca78ffa1      <nep_invoker_blob>
> 0x00007faaca73fd48      * java.lang.invoke.LambdaForm$MH+0x0000000028156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
> 
> 
> It should be:
> 
> 
> 0x00007fb5841d0818      VMError::report_and_die(Thread*, unsigned int, unsigned char*, void const*, void const*) + 0x58
> 0x00007fb583eff1ba      JVM_handle_linux_signal + 0x42a
> 0x00007fb584fd9290      <signal handler called>
> 0x00007fb5851d8e69      __cvdso_gettimeofday_data.constprop.0 + 0x99
> 0x00007fb56a78f321      <nep_invoker_blob>
> 0x00007fb56a73fd48      * java.lang.invoke.LambdaForm$MH+0x000000000e156c00.invoke(java.lang.Object, long, long, long) bci:12 (Interpreted frame)
> 
> 
> Some platforms (Ubuntu 24.04 and Fedora 43 at least) provide vDSO binary in `/lib/modules/<kernel version>/vdso`. This patch attempts to load it if we can refer it because we want to use debuginfo of vDSO if possible. Otherwise load vDSO memory.

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

  Try pathmap_open() first for vDSO

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29400/files
  - new: https://git.openjdk.org/jdk/pull/29400/files/264250a9..72256c45

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

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

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

From ysuenaga at openjdk.org  Thu Feb  5 01:10:24 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 5 Feb 2026 01:10:24 GMT
Subject: RFR: 8376269: Mixed jstack cannot find function in vDSO [v4]
In-Reply-To: <gKmQgnKimlgB7j7NoFOR-dU4B_Ev-a1D8Mf4e9AY-tI=.41da95e9-05a2-4ac9-9594-3b61e8dc5a64@github.com>
References: <OeTUuzAeOfFCYlsIHKhWay9ONjSBd95pxXWTEMlqb0E=.52aa9589-ef9c-47e8-985f-61c325a3315c@github.com>
 <CoCl22sohgZseP-qaXCBfo8u54lHfOrgfjUT-XtTMRU=.9da2c00d-411d-423d-adb0-91d5e79efbc1@github.com>
 <gKmQgnKimlgB7j7NoFOR-dU4B_Ev-a1D8Mf4e9AY-tI=.41da95e9-05a2-4ac9-9594-3b61e8dc5a64@github.com>
Message-ID: <fAYm35NFvz4ASg1g_iDH6ZJd6Yr8LpSF-dG1AVHcJgU=.ca8401a8-91b9-4bdf-a8d5-38f7e7e3ee88@github.com>

On Wed, 4 Feb 2026 12:17:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Was it meant to pass strlen(lib_name)?

`lib_name` is allocated with `char[BUF_SIZE]`, and is used in subsequent code in `read_shared_lib_info()`, thus I want to overwrite it to real path of vDSO binary at `handle_vdso()`. Hence I passed buffer size, not length of string.

> Then handle_vdso checks /lib/modules... exists, and then opens it with pathmap_open? So it has to exist without pathmap, but may also be in the SA_ALTROOT directory.
Should handle_vdso also try pathmap_open() first?

Good catch! Fixed in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29400#discussion_r2766618139

From aturbanov at openjdk.org  Thu Feb  5 03:49:26 2026
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Feb 2026 03:49:26 GMT
Subject: RFR: 8374577: Heap dump from core does not contain
 HPROF_GC_ROOT_JAVA_FRAME [v3]
In-Reply-To: <dmnUb_sT1Okmp2XTEa2x3Venrg4YZUoLG1BdejUDiV8=.2c3db891-cc86-4473-81b5-d69b7e296aa6@github.com>
References: <YJGxMxvDYEGPz81SaI_ZQNGwLHKpFZd_hDYp4ru2_JE=.41bc79d4-31f6-4c8b-932d-6d2baa1b1dd5@github.com>
 <dmnUb_sT1Okmp2XTEa2x3Venrg4YZUoLG1BdejUDiV8=.2c3db891-cc86-4473-81b5-d69b7e296aa6@github.com>
Message-ID: <A7Kb_efC_7GYJsez4-KRa3s0frfpAlram9ZSGGW0QwI=.f42eead7-3730-44aa-8975-414e129c4664@github.com>

On Thu, 29 Jan 2026 23:41:33 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can extract heap dump from coredump with `jhsdb jmap --binaryheap`, but it does not contain `HPROF_GC_ROOT_JAVA_FRAME`. It means we cannot detect leaked object on thread stack.
>> 
>> I attached 2 images which I saw on Eclipse Memory Analyzer Tool (MAT). Heap dumps were created following options:
>> 
>> 
>> -Xmx256m -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError
>> 
>> 
>> <img width="801" height="127" alt="heapdumponoutofmemoryerror" src="https://github.com/user-attachments/assets/7293e909-1c73-465a-a57c-2102251ba463" />
>> 
>> This image shows "thread overview" from the heapdump by `-XX:+HeapDumpOnOutOfMemoryError`. It reports `OOME.main` has large retained heap.
>> 
>> <img width="825" height="87" alt="from-core" src="https://github.com/user-attachments/assets/15fd3d86-76f9-452c-8103-45b631165238" />
>> 
>> On the other hand, this image extracted by `jhsdb jmap --binaryheap` does not report it - leaked object is reported as unreachable objects.
>> 
>> heapDump.cpp in HotSpot dumps `HPROF_GC_ROOT_JAVA_FRAME` for each Java frames. SA should do that.
>> 
>> Essensially, we need to apply the fix in https://github.com/openjdk/jdk/commit/290c5bae15154a9df1c2f3cfd90ebd6de1a20210 , however it fails with exception due to access `oop` in out of range. We need to fix the number of objects in expression stack like HotSpot. I fixed it in https://github.com/openjdk/jdk/commit/0697df16e2aa3f3ace7d82da0a263663fba2e2df . And also I saw error relates to `invokedynamic` because ConstantPool in SA has not followed curre t HotSpot implementation. So I fixed it in https://github.com/openjdk/jdk/pull/29058/commits/a9c9e6c9a345aeb4b2773fd0402342741d180f4d .
>> 
>> This change works fine with both interpreter and `-Xcomp`.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/OopMapCacheEntry.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29058#pullrequestreview-3754334426