On Thu, 22 Jan 2026 04:59:04 GMT, David Holmes <[email protected]> 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
