On Tue, 26 Sep 2023 01:16:11 GMT, David Holmes <dhol...@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
