On Wed, 28 Jan 2026 20:54:42 GMT, Serguei Spitsyn <[email protected]> wrote:
>> 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. Okay I see the concern - that we should check if the event is enabled immediately before posting it, just in case it was disabled whilst the thread was suspended. Though we could check it in both places and skip the TBIVM and thus the potential suspend if the event was already disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2738624642
