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

[Daniel D. Daugherty]

Kim,

Thanks for the review!


On 8/26/15 3:00 PM, Kim Barrett wrote:
> 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.

I have only seen sightings of this crash in the monitor subsystem.
Do you know of sightings with other PerfData usage?


> 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.

Sorry, I'm not in favor of leaking memory.


> 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.

It's a little disappointing, but I'll live. :-)

Dan