On Wed, 21 Jan 2026 05:36:32 GMT, Serguei Spitsyn <[email protected]> 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
