On Thu, 15 Jan 2026 09:58:41 GMT, Serguei Spitsyn <[email protected]> wrote:
>> An asynchronous handshake operation (`ThreadSelfSuspensionHandshakeClosure`) >> can be installed when the target thread is not in a `MountUnmountDisabler` >> scope. But the target thread can enter such scope by the time the operation >> is self-processed by the target thread. >> >> This is fixed by a small tweak in the function >> `HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, >> bool check_async_exception)`. >> The tweak is to skip a `HandshakeOperation` if >> `_handshakee->is_vthread_transition_disabler() == true`, so the same >> temporary suspension disabling mechanism would be used as for >> `_handshakee->is_disable_suspend() == true`. >> >> All other changes are to move the `is_vthread_transition_disabler()` out of >> DEBUG to product. >> >> Testing: >> - In progress: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: fix typo in comment Thanks for adding the reproducer test Serguei. Looking at the newly filed [JDK-8375362](https://bugs.openjdk.org/browse/JDK-8375362) I see the problem is the same one described in this PR, it's just that the suspend checkpoint is not in the handshake processing logic but in `MountUnmountDisabler::start_transition`. So maybe it would make sense to fix them both here? BTW, looking at `JvmtiEnv::InterruptThread`, do we really need the disabler? `Thread.interrupt()` could be called directly from Java and we don't disable transitions on the target. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28740#issuecomment-3757546393
