On Wed, 28 Jan 2026 15:59:58 GMT, Serguei Spitsyn <[email protected]> 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
