On Mon, 6 Nov 2023 23:22:03 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> The handshakes support for virtual threads is needed to simplify the JVMTI >> implementation for virtual threads. There is a significant duplication in >> the JVMTI code to differentiate code intended to support platform, virtual >> threads or both. The handshakes are unified, so it is enough to define just >> one handshake for both platform and virtual thread. >> At the low level, the JVMTI code supporting platform and virtual threads >> still can be different. >> This implementation is based on the `JvmtiVTMSTransitionDisabler` class. >> >> The internal API includes two new classes: >> - `JvmtiHandshake` and `JvmtiUnifiedHandshakeClosure` >> >> The `JvmtiUnifiedHandshakeClosure` defines two different callback >> functions: `do_thread()` and `do_vthread()`. >> >> The first JVMTI functions are picked first to be converted to use the >> `JvmtiHandshake`: >> - `GetStackTrace`, `GetFrameCount`, `GetFrameLocation`, `NotifyFramePop` >> >> To get the test results clean, the update also fixes the test issue: >> [8318631](https://bugs.openjdk.org/browse/JDK-8318631): >> GetStackTraceSuspendedStressTest.java failed with "check_jvmti_status: JVMTI >> function returned error: JVMTI_ERROR_THREAD_NOT_ALIVE (15)" >> >> Testing: >> - the mach5 tiers 1-6 are all passed > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: get rid of the VM_HandshakeUnmountedVirtualThread I've pushed an update which removes newly introduced VM_op and its use: `VM_HandshakeUnmountedVirtualThread`. Patricio convinced me that it has to be handshake-safe to execute a `HanshakeClosure` callback on the current (handshake requesting) thread when target thread is an unmounted virtual threads. At an earlier development stage I saw various intermittent crashes and concluded it is not handshake-safe. It is why there was a decision to use the `VM_HandshakeUnmountedVirtualThread`. I do not see these crashes anymore after a full testing cycle. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16460#issuecomment-1797026470
