Integrated: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

[Patricio Chilano Mateo]

On Thu, 8 May 2025 13:46:02 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

This pull request has now been integrated.

Changeset: 9ebb5d42
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ebb5d42d43a743cf3a5197c7dabe46ac8120474
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock

Reviewed-by: kevinw, dholmes, alanb

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

PR: https://git.openjdk.org/jdk/pull/25119