On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo <pchilanom...@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 <pchilanom...@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
