On Fri, 1 Mar 2024 23:26:48 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> Please, review this fix correcting the JVMTI `RawMonitorWait()` > implementation. > The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to update > the interrupt status of the interrupted waiting thread. The issue is that > when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt > status` of the virtual thread, this information is not propagated to the > `java.lang.Thread` instance. > In the `VirtualThread` class implementation the `interrupt status` for > virtual thread is stored for both virtual and carrier threads. It is because > the implementation of object monitors for virtual threads is based on pinning > virtual threads, and so, always operates on carrier thread. The fix is to > clear the interrupt status for both virtual and carrier `java.lang.Thread` > instances. > > Testing: > - tested with new test > `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is > passed with the fix and failed without it > - ran mach5 tiers 1-6 src/hotspot/share/runtime/javaThread.cpp line 594: > 592: // thread_oop is virtual, clear carrier thread interrupt status as > well > 593: java_lang_Thread::set_interrupted(threadObj(), false); > 594: } This isn't right for the case that Thread::interrupt it called around the same time. The interrupt status on both the virtual thread and the carrier need to be kept in sync so the changes here need to work like an up call to VirtualThread.getAndClearInterrupt and use the interrupt lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1509909644
