RFR: 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
Serguei Spitsyn
sspitsyn at openjdk.org
Tue Mar 5 20:10:47 UTC 2024
On Tue, 5 Mar 2024 07:47:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> 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.
Got it. Thank you, Alan.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1513425638
More information about the hotspot-runtime-dev
mailing list