JEP 132: More-prompt finalization
david.holmes at oracle.com
Sun Jan 8 23:44:35 PST 2012
On 9/01/2012 5:27 PM, Srinivas Ramakrishna wrote:
> Ah, I see what you meant. Yes, there'd probably be some (theoretical)
> overhead from such tracking,
I'm not considering multiple apps per VM I'm just thinking of a
programmer using java.io.* or java.net.* classes which have been
"enhanced" to support resource tracking.
If the proposal involves new wrapper classes that an application has to
opt-in to use then that is fine.
But I think this has gone off-track somewhat - finding alternatives to
finalization. The JEP is more about speeding up finalization for those
apps that (for better or worse) rely on it. I think there are two main
aspects of this:
- adding more threads to process finalizers and/or reference objects
- adding an API to request and run finalization etc (more efficiently
that doing: System.gc(); System.gc(); System.runFinalization() )
Although we "all" know "finalizers are evil", they exist and are
(mis-)used by some apps and cause some issues.
> if there are multiple applications within a single JVM some of which
> wanted to use these APIs
> and some did not, then the ones that do not care for such tracking or
> policies would pay
> the price (and besides one would have to resolve composition issues in
> such cases). But
> if one confined oneself for the moment to the simpler case of a single
> application per JVM,
> then if that application chose not to use such tracking, then there
> would be little to no overhead
> for it.
> Even in the case of multiple applications, my guess is that the overhead
> for other applications
> could be managed. I suspect that, compared to the JNI transition
> overheads, resource tracking
> overheads per se (and not the implementation of specific finalization
> triggering policies thereof)
> could, i think, be engineered to be very small.
> If, on the other hand, you are referring to the overhead of the work
> done for prompt finalization
> related to specific resources that one of a set of applications running
> on a JVM cares about
> and that others do not, that is a legitimate concern, but seems to me to
> be no different from these disparate
> applications sharing the same JVM heap which is subject to a global
> collection which stops
> the threads of each application (or of concurrent collection which
> imposes an overhead on
> all the applications sharing that JVM, or indeed the hardware), if you
> know what i am getting at...
> -- ramki
> On Sun, Jan 8, 2012 at 4:14 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> Hi Ramki,
> On 9/01/2012 10:08 AM, Srinivas Ramakrishna wrote:
> So at best this is a heuristic, so the library tracks the
> and at some threshold it invoke System.runFinalization. The GC
> itself doesn't make an informed decision because, as you
> said your
> self, the VM (and hence GC) knows nothing about the resource
> Yes, it would be a heuristic-driven policy (or set of policy
> but it's better than each application rolling its own policy and
> infrastructure from scratch.
> If it can be provided as an additional feature that applications
> only pay for if they need it.
> But would we want to burden all users of these classes with the
> overhead of resource tracking?
> The objective is to do the resource tracking from within the
> (+JVM), so the user wouldn't have to bother.
> For example, by providing suitable high level API's at the
> library level
> which would be wrappers
> around specific native resources that would be subject to such
> That's exactly the overhead I'm referring to. If these resources are
> always managed then all applications pay the price for the few that
> need it.
> -- ramki
> I can imagine something like:
> void setFinalizationLimit(Class<?> cls, int limit)
> so that GC runs finalization once a "reference count"
> reaches "limit".
> That limits the frequency of finalization, but the
> cost may still be unacceptably high.
> Afterall the key thing about GC is it
> relieves the
> programmer from
> having to manage object lifetimes, so if you
> know when the
> object is no longer used you don't know when
> to call
More information about the hotspot-dev