RFR: 8366659: ObjectMonitor::wait() liveness problem with a suspension request [v31]

[David Holmes]

On Wed, 28 Jan 2026 11:31:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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