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

[Serguei Spitsyn]

On Mon, 4 Mar 2024 11:51:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alan and David, thank you for the comments!
>> The initial implementation of the `is_iterrupt()` intentionally avoided any synchronization and allowed a potential raises with the concurrent interrupts. Please, see the comment above at lines: `573-587`. It is why David mentioned the need to update the comment. I agree with Alan that that interrupt status of virtual and carrier threads have to be kept in sync. But as we already discussed with Alan before, an upcall to Java does not looks good and can cause some issues on the JDWP side. I'm thinking to model a CAS kind of operation to keep the two interrupt statuses in sync but still need to prove it is going to be safe. Also, there is a question if it worth the complexity.
>> The need to keep interrupt status in both virtual and carrier threads comes from virtual thread pinning. I believe, there would be no need to keep interrupt status for both threads in the Java object monitors inplementations. AFAICS, then the implementation of the `is_interrupted()` can be kept as it is now. 
>> So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.
>
> David can correct me, but I think the only cases in the VM where a thread may clear its interrupt status is Thread.interrupted, Thread.sleep, Object.wait, and JVMTI RawMonitorWait.  Thread.interrupted and Thread.sleep are different implementation and not interesting here. Right now, Object.wait does wait on the carrier. If the virtual thread is interrupted while in the monitor's wait set then InterruptedException will be thrown when the thread reenters and the interrupt status of both threads will be cleared at that point (it will have of course have been cleared by the VM too prior to throwing). If something sneaky were to go behind our backs and interrupt the carrier directly then it will be benign for this case but might cause a spurious InterruptedException at other times, say where the mounted  virtual thread were to call Object.wait soon after its carrier was interrupted directly. We've mostly ignored that concern.
> 
> For JVMTI RawMonitorWait then it has to coordinate with Thread.interrupt and JVMTI InterruptThread. The latter does do an upcall when the target is a virtual thread so it's the same as Thread.interrupt. So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.

@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?

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

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