RFR: 8346792: serviceability/jvmti/vthread/GetThreadState/GetThreadState.java testObjectWaitMillis failed

[Patricio Chilano Mateo]

On Wed, 15 Jan 2025 08:15:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The ugliness comes from the fact that the ObjectMonitor::wait() is called from two places: ObjectSynchronizer::wait() and ObjectSynchronizer::waitUninterruptibly(). We do not need the JavaThreadInObjectWaitState in the second cases, so the object is defined in the JVM_MonitorWait() but not in the ObjectMonitor::wait()
>
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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23126#issuecomment-2593725050