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

[Anton Artemov]

On Wed, 28 Jan 2026 11:51:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 has been made 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.

Moving `ThreadBlockInVM` outside will make it possible to suspend the successor thread, which we don't want to happen. Getting rid of it completely will make it possible, as David said, to post the waited event while being suspended, which we also do not want to happen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2736447830