On Wed, 28 Jan 2026 18:36:46 GMT, Serguei Spitsyn <[email protected]> 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
