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

[Anton Artemov]

On Thu, 22 Jan 2026 04:59:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1933:
>> 
>>> 1931:     // Post monitor waited event. Note that this is past-tense, we are done waiting.
>>> 1932:     // An event could have been enabled after notification, need to check the state.
>>> 1933:     if (JvmtiExport::should_post_monitor_waited() && node.TState != ObjectWaiter::TS_ENTER) {
>> 
>> I don't think this is correct - if the state is TS_ENTER then where do we post the event? I think this should be:
>> 
>>      if (JvmtiExport::should_post_monitor_waited()) {
>>        if (node.TState != ObjectWaiter::TS_ENTER) {
>>          // Process suspend requests now if any, before posting the event.
>>          ThreadBlockInVM tbvm(current, true);
>>        }
>>        JvmtiExport::post_monitor_waited(current, this, ret == OS_TIMEOUT);
>>      }
>
> Thinking more, that is not correct either. I don't think there is any way to accommodate the event being enabled after notification and still avoid the liveness bug. The code as it stands will not post the event if the state is TS_ENTER - so we have a "missing event". If it does post the event (per my suggestion) then we are back to the problem of the successor potentially being suspended.

Agree, in this case, the ultimate solution would be for a successor thread to stop being a successor and let any other thread become, if there is any on the `entry_list`. IIRC it was discussed a few times, and seems to be a rather complex thing to do.

I think having no missing event is more important than hitting a successor being suspended. Moreover, this should be a rather rare case, its probability would be the probability of someone enabling `monitor_waited` event after notifying times the probability of having a suspension request around this point.

I added the changes you suggested.

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

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