RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31]

[David Holmes]

On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Okay. Then what about this ? :
>> 
>>    if (interruptible && node.TState != ObjectWaiter::TS_ENTER) {   
>>      // Process suspend requests now if any, before posting the event.
>>      // The monitor waited events can be disabled while suspended.
>>      {
>>        ThreadBlockInVM tbvm(current, true);
>>      }
>>      if (JvmtiExport::should_post_monitor_waited()) {
>>       JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT);
>>      }
>
> Just want to explain my concern better.
> At the monitor notification point there is a check for `JvmtiExport::should_post_monitor_waited()`.
> If it is `false` then the `node.TState` is set to `ObjectWaiter::TS_RUN`. There is no `ThreadBlockInVM` for this case, so there is no need to re-check for `JvmtiExport::should_post_monitor_waited()`. The monitor waited event is not posted in this case.
> If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. We intent to post a monitor waited event in this case. There is a `ThreadBlockInVM` for this case, so thread can be suspended. The JVMTI thread state still has a bit `JVMTI_THREAD_STATE_WAITING`, so the debugger can disable `JVMTI_EVENT_MONITOR_WAIT` events while the target thread is being suspended in WAITING state. However the event will be posted after suspension. This does not match the debugger's expectation.

> At the monitor notification point there is a check for JvmtiExport::should_post_monitor_waited(). 
> If it is false then the node.TState is set to ObjectWaiter::TS_RUN. 
> If it is true the node.TState is set to ObjectWaiter::TS_ENTER.

@sspitsyn you have that the wrong way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738525236