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

[David Holmes]

On 28/08/2015 3:47 AM, Kim Barrett wrote:
> On Aug 27, 2015, at 11:51 AM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> 3) We don't like the "fast but safe" solution of leaking the PerfData
>>    memory. We try to make ourselves feel better about this by saying
>>    there are plenty of other leaks in the VM... slippery slope?
>
> "Leak" is perhaps misleading and overly perjorative.  A better
> description of what I've suggested is "pass the buck for memory
> cleanup to the OS".  When we're on our way to process exit, we know
> the OS will deal with our memory resources.  We already (and would
> still) clean up relevant non-memory resources (like shared memory
> files for the PerfData) - I'm not suggesting any change there.
> perfMemory_exit already has that separation of memory vs non-memory
> resource cleanup.

I agree this is not a "leak" in the regular sense it is simply memory 
not explicitly returned before process exit - of which we already have a 
lot. Hence I'm not opposed to simply making PerfData objects "permanent".

> I submit that in many situations when we're on our way to process
> exit, the sleep being introduced by this change may actually have a
> significant negative impact.  If we're on our way to dumping a core
> file for debugging an error, putting a sleep along the way just allows
> other threads more time to run further from the state where the error
> occurred.  I wish we were running less code rather than more in that
> situation.

If we're on our way to dumping a core file, the error was in the current 
thread. But point noted other threads will continue longer and 
potentially hit secondary errors.

> If we're not on our way to process exit, and instead want to achieve a
> state where we can restart the VM or unload the VM code, we clearly
> need to make sure that other cleanup has been done, such as bringing
> all threads to quiescence and eventually tearing them down.  But if we
> don't have other threads running then the problem of some thread
> trying to touch the PerfData after we've destroyed it simply doesn't
> happen.

Right - once we have solved the problem of how to terminate all the 
existing threads and reclaim their resources, then reclaiming a shared 
resource like the PerfData objects is "trivial".

> And indeed, there is at least the beginnings of code to do that sort
> of thing; see jni_DestroyJavaVM.  And what I've proposed is that we do

I think you misunderstand what jni_DestroyJavaVM is doing. It implements 
the normal lifecycle management for the JVM - which is that the JVM 
keeps running as long as there is one non-daemon thread running. So the 
only waiting in that method is for the non-daemon thread count to hit 
zero, at which point VM termination is initiated. But there can be a 
zillion daemon threads still running (application and VM).

Cheers,
David

> the PerfData memory cleanup exactly and only when that's the goal
> state, since in that case it is safe and necessary to do the PerfData
> memory cleanup.
>