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

[Daniel D. Daugherty]

On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.
> 
> I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended
> thread made the successor over and over again so that none of the other contending threads
> ever get the monitor even though it is unlocked.
> 
> I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread
> manages to re-enter the monitor and then gets suspended while on its way back to Java.
> 
> @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two
> new test cases to the two deadlocks. Thanks!

> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario? @dcubed-ojdk, what do you think?

Sorry for the long delay in getting back to this thread.

Yes, the original SuspendWithObjectMonitorWait demonstrated a real-world scenario and it
reproduced a bug in the JVM where a suspended thread was allowed to enter a monitor.
That violated the SuspendThread contract that after return from the call, the target thread
will execute no more bytecode or byte-code equivalents.

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

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