On Aug 25, 2015, at 5:08 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: > > Greetings, > > I have a "fix" for a long standing race between JVM shutdown and the > JVM statistics subsystem: > > JDK-8049304 race between VM_Exit and _sync_FutileWakeups->inc() > https://bugs.openjdk.java.net/browse/JDK-8049304 > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8049304-webrev/0-jdk9-hs-rt/
Looking at the webrev, I was initially surprised at the limited number of places that are being changed to check the new predicate for PerfData validity. (The webrev only changes the Java monitor subsystem to call the new predicate, and the RFR even says that, so I really shouldn't have been surprised.) There are lots of places that use PerfData. Don't they all need to be updated? I was hoping the answer would be no, but after reviewing the bug thread and code, I think that hope was in vain. The problem is that exit_globals (and so, ultimately, perfMemory_exit and the proposed modification in PerfDataManager::destroy) is called from a variety of contexts, some of which may have concurrent threads that may touch non-monitor PerfData. A crash in the GC is just one example of the places where this situation could arise. Unfortunately, this puts me back in the position of thinking we should just leak the memory when we're on our way to process exit. That is, callers of exit_globals indicate (via a new flag argument) whether we're on the way to process exit, and that flag gets passed down to perfMemory_exit, which elides the call to PerfDataManager::destroy (but still must call PerfMemory::destroy) when we're exiting the process. Dan, sorry for reversing positions on you, but I'd been so focused on the monitor crashes that we were looking at that I missed the wider scope of the problem.
