On Wed, 6 Mar 2024 09:14:18 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 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp src/hotspot/share/runtime/javaThread.cpp line 573: > 571: > 572: Handle thread_h(current, vthread_or_thread()); > 573: ObjectLocker lock(Handle(current, > java_lang_Thread::interrupt_lock(thread_h())), current); For this version then I assume you should limit it when its a virtual thread and when clear_interrupted is true. Also need to think through if Object.wait will need to be changed as part of this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1514126817
