On Mon, 17 Nov 2025 20:19:58 GMT, Patricio Chilano Mateo <[email protected]> wrote:
> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a > virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable > mount/unmount transitions. However, this only works if a JVMTI agent has > attached to the VM, otherwise virtual threads don’t honor the disable > request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` > and `HotSpotDiagnosticMXBean` which don’t require a JVMTI agent to be > present, getting the snapshot of a virtual thread in such cases can lead to > crashes. > > This patch moves the transition-disabling mechanism out of JVMTI and into a > new class, `MountUnmountDisabler`. The code has been updated so that > transitions can be disabled independently of JVMTI, making JVMTI just one > user of the API rather than the owner of the mechanism. Here is a summary of > the key changes: > > - Currently when a virtual thread starts a mount/unmount transition we only > need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to > go to the slow path. With these changes, JVMTI is now only one user of the > API, so we instead check the actual transition disabling counters, i.e the > per-vthread counter and the global counter. Since these can be set at any > time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or > during a safepoint in case of late binding agents), we follow the classic > Dekker pattern for the required synchronization. That is, the virtual thread > sets the “in transition” bits for the carrier and vthread *before* reading > the “transition disabled” counters. The thread requesting to disable > transitions increments the “transition disabled” counter *before* reading the > “in transition” bits. > An alternative that avoids the extra fence in `startTransition` would be to > place extra overhead on the thread requesting to disable transitions (e.g. > using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance > analysis show no difference with current mainline so for now I kept this > simpler version. > > - Ending the transition doesn’t need to check if transitions are disabled > (equivalent to not need to poll when transitioning from unsafe to safe > safepoint state). But we still require to go through the slow path if there > is a JVMTI agent present, since we need to check for event posting and JVMTI > state rebinding. As such, the end transition follows the same pattern that we > have today of only needing to check `_VTMS_notify_jvmti_events`. > > - The code was previously structured in terms of mount and un... This pull request has now been integrated. Changeset: e534ee99 Author: Patricio Chilano Mateo <[email protected]> URL: https://git.openjdk.org/jdk/commit/e534ee99327fed2263302a00061fb46fcdc6e302 Stats: 1957 lines in 41 files changed: 914 ins; 823 del; 220 mod 8364343: Virtual Thread transition management needs to be independent of JVM TI Co-authored-by: Alan Bateman <[email protected]> Reviewed-by: coleenp, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28361
