On Thu, 8 May 2025 19:52:17 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 > > Patricio Chilano Mateo has updated the pull request incrementally with one > additional commit since the last revision: > > Rename awaitBlocked to awaitTrueAndBlocked > we don’t change the state to Thread.State.WAITING when using ObjectLocker and > calling wait_uninterruptibly(). No, because that is an internal implementation detail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25119#issuecomment-2864508184
