> 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
Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Rename awaitBlocked to awaitTrueAndBlocked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25119/files - new: https://git.openjdk.org/jdk/pull/25119/files/7c067865..c36728d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25119&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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
