RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

David Holmes dholmes at openjdk.org
Tue Sep 26 01:29:11 UTC 2023


On Tue, 26 Sep 2023 01:16:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Edit: I missed the intermediate comments above where Roman explained.
>> 
>> @plummercj the SA code sees T2 is pending on the monitor for object O, which is locked anonymously but actually by T1. The SA code then goes hunting for the owner. But the VM is not standing still. T1 continued execution and went to release the lock, it sees it has been inflated and sets itself as the true owner, then releases the lock thus clearing the owner and potentially unblocking T2. T2 could now proceed to acquire the lock. But the SA sees  none of this because it has a stale view of things.
>
> To expand if deadlock detection does not run at a safepoint then this logic is non-atomic and completely broken:
> 
>  threads = VM.getVM().getThreads();
>  heap = VM.getVM().getObjectHeap();
>  createThreadTable();  // calls getThreads() again
> 
> Without a stable VM you could have three almost completely different set of threads when each of these statements run!

If the SA is working from a snapshot then it has to create that snapshot atomically. It can't snapshot the threads, then snapshot the heap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336527632


More information about the serviceability-dev mailing list