RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension request [v13]

[Anton Artemov]

On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:
> 
> ```
> wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor
> ```
> 
> whereas the new code, if we kept the placement of the event, would do
> 
> ```
> wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor
> ```
> 
> and what the proposed code actually does is
> 
> ```
> wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 
> ```
> 
> Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

@dholmes-ora I have done a bit of refactoring and introduced a private method `post_waited_event()`, which we can call in different places depending on the scenario. 

For instance, for the timed-out case, the sequence of events is now unchanged, i.e.:
`wait -> waited -> contended enter -> contended entered`

For notified case, using your extended notation, it is now behaving like this: 
`wait  -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor`

I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits? 
The JVMTI tests pass, the extended testing is in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3558649501