RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed
Serguei Spitsyn
sspitsyn at openjdk.org
Wed Jan 15 22:49:52 UTC 2025
On Wed, 15 Jan 2025 19:02:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
> I tried to think if this is by design or we just missed the JavaThreadInObjectWaitState on the second case. Reading the comments in Thread.java on enum State it seems we shouldn’t change the Thread.State, but then we shouldn’t also change the Thread.State to BLOCKED when using ObjectLocker and facing contention, since we are not entering a synchronized block/method. I guess the ObjectLocker::wait_uninterruptibly() is particularly sensible, because we don’t want another thread to see the Thread.State as WAITING/TIMED_WAITING since it could try interrupting it and expect the target to transition out of the WAITING/TIMED_WAITING state as in a normal Object.wait() call.
Another thing I noticed for the ObjectLocker::wait_uninterruptibly() case is that we don’t post the monitor_wait event but we do post the monitor_waited one.
Thank you for the comment. I was also thinking if it is by design or not. But changing the `Thread.State` to `WAITING/TIMED_WAITING` in the `ObjectLocker::wait_uninterruptibly()` case makes many tests to fail.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23126#issuecomment-2594089997
More information about the hotspot-runtime-dev
mailing list