On 28/08/2015 3:47 AM, Kim Barrett wrote:
On Aug 27, 2015, at 11:51 AM, Daniel D. Daugherty <daniel.daughe...@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.
