RFR: 8373366: HandshakeState should disallow suspend ops for disabler threads [v13]

[Patricio Chilano Mateo]

On Wed, 21 Jan 2026 05:36:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1186:
>> 
>>> 1184: bool JavaThread::java_suspend(bool register_vthread_SR) {
>>> 1185:   // Suspending a vthread transition disabler can cause deadlocks.
>>> 1186:   // The HandshakeState::has_operation does not allow such suspends.
>> 
>> So for a thread trying to self-suspend we don't use handshakes. We identify this case and call `do_owner_suspend()` directly, which would now hit the new assert added there. I think self-suspend within a `MountUnmountDisabler` scope is actually possible if some event is posted during the `interrupt` Java upcall. But maybe we should fix this case in a separate issue? (it's preexistent to this change)
>
> Good check, thanks.
> The `JvmtiJavaUpcallMark` hides the JVMTI events during the `interrupt` upcall:
> 
> JvmtiEnv::InterruptThread(jthread thread) {
>   . . .
>   if (java_lang_VirtualThread::is_instance(thread_obj)) {
>     // For virtual threads we have to call into Java to interrupt:
>     Handle obj(current_thread, thread_obj);
>     JvmtiJavaUpcallMark jjum(current_thread); // hide JVMTI events for Java upcall          <== !!!
>     JavaValue result(T_VOID);
>     JavaCalls::call_virtual(&result,
>                             obj,
>                             vmClasses::Thread_klass(),
>                             vmSymbols::interrupt_method_name(),
>                             vmSymbols::void_method_signature(),
>                             current_thread);

I see, could we keep the original assert? Should not be possible to request suspend on a transition disabler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28740#discussion_r2713776399