RFR: 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is

[Serguei Spitsyn]

On Tue, 5 Mar 2024 00:54:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @AlanBateman said:
>>> So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.
>> 
>> If we do it with a Java upcall to the `VirtualThread.getAndClearInterrupt()` then we also have to skip the JVMTI events, AFAIK, as it is not a good idea to post the JVMTI events recursively. This is going to touch many spots in the `jvmtiExport.cpp`. Otherwise, I do not see how to hold the interruptLock from the VM side. Any advices?
>
>> AFAIK, as it is not a good idea to post the JVMTI events recursively
> 
> We already do. When the debug agent is handling a JVMTI event and RawMonitorWait is interrupted, that results in the debug agent later on calling InterrtupThread before exiting the event handler. For virtual threads that results in an upcall to Thread.interrupt(), and therefore the potential for a JVMTI event to be triggered (and that is exactly what happens frequently in the com/sun/jdi/InterruptHang.java test). At least in that case the debug agent is somewhat in control of the situation because it is just doing "cleanup" before exiting the event handler. For example, no locks are being held. Having RawMonitorWait do a java upcall sounds a potential big can of worms.

Thank you for sharing this, Chris. It sounds like we need to introduce a mechanism to temporarily hide the JVMTI events. The question is if it is worth the complexity we add with it, especially if it is used just in a couple of cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511997287