RFR: 8369944: Notification can be lost due to interrupt in Object.wait [v2]

[Patricio Chilano Mateo]

On Fri, 17 Oct 2025 03:10:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1885:
>> 
>>> 1883:       if (interrupted || HAS_PENDING_EXCEPTION) {
>>> 1884:         // Intentionally empty
>>> 1885:       } else if (node.TState == ObjectWaiter::TS_WAIT) {
>> 
>> I must have misread the code previously, as I thought this was read under the wait_set_lock, but it isn't. So what stops us from seeing a stale TS_WAIT here and continuing with the park even though we were already notified? I'm assuming the implicit barriers in the TBIVMP? Or is it much more subtle than that, and the successor protocol will unpark us once the monitor could be available?
>
> I think it is the latter. We could read a stale TState value no matter what, as it may have only just been set before we read it. But not seeing TS_WAIT is just an optimisation to skip the park.

Exactly. If the notifier already issued the unpark then the park permit will be set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27856#discussion_r2440379137