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

[David Holmes]

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

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewers' comments.
>
> 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.

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

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