JDK-8364343 : Virtual Thread transition management needs to be independent of JVM TI
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 26
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-07-30
  • Updated: 2025-11-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26Unresolved
Related Reports
Duplicate :  
JDK-8361913 - Thread.dump_to_file is not protected from mount/unmount
Duplicate :  
JDK-8366438 - Crash when running java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java#id0 on macos-aarch64
Duplicate :  
JDK-8371053 - diagnostic command Thread.dump_to_file crash
Duplicate :  
JDK-8372013 - JVM crashes with SIGSEGV in GC barrier (G1/ZGC) during handshake
Duplicate :  
JDK-8371913 - SIGSEGV in ZBarrierSet::AccessBarrier during virtual thread status query
Description
I've attached a stress test for com.sun.management.HotSpotDiagnosticMXBean.dumpThreads. The test invokes the dumpThreads method while many virtual threads are parking and unparking. There test currently triggers several asserts, even when the (currently in-progress) changes for JDK-8364314 and JDK-8361103 included.

The assert when when an empty stack chunk is encountered looks like this:

V  [libjvm.dylib+0x1226c20]  VMError::report(outputStream*, bool)+0x1b00  (stackChunkOop.cpp:102)
V  [libjvm.dylib+0x122a4c0]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
V  [libjvm.dylib+0x5ac01c]  print_error_for_unit_test(char const*, char const*, char*)+0x0
V  [libjvm.dylib+0x1033bb4]  stackChunkOopDesc::num_java_frames() const+0x0
V  [libjvm.dylib+0x1013fd0]  frame::sender_raw(RegisterMap*) const+0x78
V  [libjvm.dylib+0x51a4e8]  vframeStreamCommon::next()+0x404
V  [libjvm.dylib+0x117a2ec]  GetThreadSnapshotHandshakeClosure::do_thread(Thread*)+0xa9c
V  [libjvm.dylib+0x11792fc]  ThreadSnapshotFactory::get_thread_snapshot(_jobject*, JavaThread*)+0x93c
V  [libjvm.dylib+0xa68648]  JVM_CreateThreadSnapshot+0xe4
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28361 Date: 2025-11-17 20:19:58 +0000
20-11-2025
Patricio has prototype changes that generalize the disabled so that JvmtiVTMSTransitionDisabler is replaced with a transition disabler that is not tied to JVMTI. This allows ThreadSnapshotFactory::get_thread_snapshot to reliably handshake with a mounted or unmounted virtual thread.
07-09-2025
This does not crash anymore if the JvmtiVTMSTransitionDisabler is correctly installed and enabled. Also, this issue looks like a dup of JDK-8364314. At least, with the suggested patch there is also no crash anymore.
31-07-2025
JDK-8364314 doesn't fix the issue. It is need related to transitions. The loom repo has the support for suspending an unmounted virtual thread (allows use beyond Thread::getStackTrace) and also has changes to ThreadSnapshot/implementation to retry when in transition. This fixes JDK-8361913 too.
31-07-2025