Please review this small test fix. We need to make sure the two threads are blocked on the expected locks before invoking findMonitorDeadlockedThreads. In the failing cases, one of the threads is seen as blocked while waiting for a class to be initialized by the other thread (I've added the stack traces showing where this occurs in the bug comments).
I should point out that there is an inconsistency in the VM here though. We are changing the state to Thread.State.BLOCKED while using ObjectLocker internally when there is contention to enter the monitor, but we don’t change the state to Thread.State.WAITING when using ObjectLocker and calling wait_uninterruptibly(). I still think the test should be improved to avoid having to think if there is some other synchronize statement executed along the way (CyclicBarrier implementation for instance, or code run by a vthread during startup). I was able to reproduce the failure and verified it doesn’t reproduce anymore with the fix. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/25119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346255 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25119/head:pull/25119 PR: https://git.openjdk.org/jdk/pull/25119
