On Thu, 9 May 2024 21:40:42 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> I guess there could be a race if one thread is destroying this monitor while >> another is trying to use it. Thus a thread could be doing something like a >> RawMonitorEnter in the middle of (or after) the monitor being destroyed. >> Fixing that would require holding dbgRawMonitor during RawMonitorEnter, and >> that would cause deadlocks all over the place. Also, this same potential >> issue exists already, but doesn't seem to ever arise. It seems we only call >> debugMonitorDestroy for cmdQueueLock. Not sure why that is. > > FWIW Deleting monitors is a tricky business and needs to be done with great > care. You have to ensure all threads using the monitor are completely done > with it. Simply locking it first to check it is "unused" is not sufficient. This is probably the reason that the debug agent only destroys one of the 20 or so monitors it creates. I'm not sure how it got to that point. It may have destroyed more at one point but there were issues, and only one survived destruction without issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1598885045
