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

[Chris Plummer]

On Mon, 4 Mar 2024 23:35:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 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.

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

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