On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <[email protected]> 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
