On Wed, 28 Jan 2026 11:31:03 GMT, Serguei Spitsyn <[email protected]> wrote:
>> IIUC Dan's concern is not a concern because another suspend request can be
>> initiated but it won't be actioned until the target executes the handshake -
>> which can only happen at well-defined points where we allow for suspension.
>
> Sorry, but I have a concern about line 1939 with `ThreadBlockInVM`.
> As Patricio already explained, enabling and posting JVMTI events are
> intentionally racy, so we normally do not care about missing racy events.
> However, suspend points are synchronous. We should honor both enabled and
> disabled event requests that are present at a suspend point.
> The problem here is a decision to post the monitor waited event at the line
> 1935. But the `JvmtiExport::post_monitor_waited()` can be found disabled at
> the `ThreadBlockInVM` suspend point.
>
> One approach would be to refactor this as below:
>
> // Process suspend requests now if any, before posting the event
> {
> ThreadBlockInVM tbvm(current, true);
> }
> if (interruptible && JvmtiExport::should_post_monitor_waited() &&
> node.TState != ObjectWaiter::TS_ENTER) {
> JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT);
>
> Another approach would be to get rid of this `ThreadBlockInVM`.
> But it is hard to predict all the consequences.
The `ThreadBlockInVM` is there so that a thread suspended before being notified
does not expose that fact by issuing a monitor_waited event whilst suspended.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736280646
