RFR (S) 8049304: race between VM_Exit and _sync_FutileWakeups->inc()

[Kim Barrett]

On Aug 25, 2015, at 5:08 PM, Daniel D. Daugherty <daniel.daugherty at 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.