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

[Anton Artemov]

On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.
>
> My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event.

Thanks @pchilano, I was not aware of that property of agents. With that in mind, it makes sense to check the state in the condition. Modified the code accordingly.

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

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