RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

[Patricio Chilano Mateo]

> 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