RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v12]
Patricio Chilano Mateo
pchilanomate at openjdk.org
Fri Jan 16 00:46:52 UTC 2026
On Thu, 15 Jan 2026 09:58:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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
More information about the serviceability-dev
mailing list