> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a > virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable > mount/unmount transitions. However, this only works if a JVMTI agent has > attached to the VM, otherwise virtual threads don’t honor the disable > request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` > and `HotSpotDiagnosticMXBean` which don’t require a JVMTI agent to be > present, getting the snapshot of a virtual thread in such cases can lead to > crashes. > > This patch moves the transition-disabling mechanism out of JVMTI and into a > new class, `MountUnmountDisabler`. The code has been updated so that > transitions can be disabled independently of JVMTI, making JVMTI just one > user of the API rather than the owner of the mechanism. Here is a summary of > the key changes: > > - Currently when a virtual thread starts a mount/unmount transition we only > need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to > go to the slow path. With these changes, JVMTI is now only one user of the > API, so we instead check the actual transition disabling counters, i.e the > per-vthread counter and the global counter. Since these can be set at any > time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or > during a safepoint in case of late binding agents), we follow the classic > Dekker pattern for the required synchronization. That is, the virtual thread > sets the “in transition” bits for the carrier and vthread *before* reading > the “transition disabled” counters. The thread requesting to disable > transitions increments the “transition disabled” counter *before* reading the > “in transition” bits. An alternative that avoids the extra fence would be to > place extra overhead on the thread requesting to disable transitions (e.g. by > usi ng a safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so I believe this approach is simpler. > > - Ending the transition doesn’t need to check if transitions are disabled > (equivalent to not need to poll when transitioning from unsafe to safe > safepoint state). But we still require to go through the slow path if there > is a JVMTI agent present, since we need to check for event posting and JVMTI > state rebinding. As such, the end transition follows the same pattern that we > have today of only needing to check `_VTMS_notify_jvmti_events`. > > - The code was previously structured in terms of mount and unmount cases, and > a...
Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add fixes to DumpThreadsWithEliminatedLock.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28361/files - new: https://git.openjdk.org/jdk/pull/28361/files/70f96a7d..976486cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361 PR: https://git.openjdk.org/jdk/pull/28361
