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

Patricio Chilano Mateo pchilanomate at openjdk.org
Thu Nov 13 21:49:46 UTC 2025


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

> 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!
>
The PR description of the cases isn’t quite accurate. The explanation in `1.` applies to both deadlocks, the only difference is where the successor could be suspended:
[1]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 (exercised by doWork2)
[2]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 (exercised by doWork3)

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

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


More information about the serviceability-dev mailing list