On Tue, 5 Mar 2024 06:16:04 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: > > review: addressed a couple of comments on new test Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/InterruptRawMonitor.java line 51: > 49: System.out.println(thread); > 50: thread.start(); > 51: Thread.sleep(2000); I think it would be better to check 'thread' status or the same monitor to sync instead of sleep. The sleep is always looks suspect, especially when intermittent failure happens. Also, it helps to save 2 seconds. ------------- PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1917793041 PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1513292890
