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