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_ENTER`.
> 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_RUN`. 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.
> @sspitsyn you have that the wrong way around.
Thanks! Corrected in place.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738567428
