RFR: 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
Serguei Spitsyn
sspitsyn at openjdk.org
Thu Mar 7 00:29:53 UTC 2024
On Tue, 5 Mar 2024 23:11:07 GMT, David Holmes <dholmes at openjdk.org> wrote:
> Okay so that is where the carrier and virtual thread states get back in sync, and that is what is missing in the `RawMonitorWait` case. The proposed fix/change to `is_interrupted` is what threw me as that is the wrong place to make a change because it affects both cases. What is missing is an upcall from `RawMonitorWait` to some Java code to do the same job as the `Object.wait` Java code does.
There was a duplication in the `Object.wait` which has been just removed.
Please, see the incremental update 07: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=07) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=06-07) ([923a3ff5](https://git.openjdk.org/jdk/pull/18093/files/923a3ff580cfc4d0a68775e5f849b63c691b8eb3)).
Now, both `Object.wait` and `RawMonitorWait` clear the interrupt status with the `JavaThread::is_interrupted()` only.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1982105087
More information about the hotspot-runtime-dev
mailing list