On Tue, 5 Mar 2024 00:54:10 GMT, Chris Plummer <cjplum...@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
