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

[Serguei Spitsyn]

On Wed, 28 Jan 2026 15:59:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen.
>
> 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()`.
If it is `true` the `node.TState` is set to `ObjectWaiter::TS_ENTER`. There is a `ThreadBlockInVM` for this case, so the 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. However the event will be posted after suspension.

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

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