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

[Kevin Walls]

On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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

Hi, looks good!

(The flag is easier than trying to look at the name of the thing they are blocked on.)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25119#pullrequestreview-2826251302