On Tue, 5 Mar 2024 01:06:32 GMT, Serguei Spitsyn <sspit...@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. > > 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. > 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. I meant it would need to use ObjectLocker to hold the lock in the VM when changing both fields. It should only need to do this for RawMonitorWait at this time. For Object.wait, the clearing of the interrupt status is done in the Java code, something that will change once Object.wait changes to freeze/unmount when not pinned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1512274259
