JEP 132: More-prompt finalization

[David Holmes]

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.

Cheers,
David

> 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:
>     <snip>
>
>
>             So at best this is a heuristic, so the library tracks the
>         resource
>             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
>         being
>             tracked.
>
>
>         Yes, it would be a heuristic-driven policy (or set of policy
>         choices),
>         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
>         libraries
>         (+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
>         tracking.
>
>
>     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.
>
>     David
>     -----
>
>
>         -- ramki
>
>
>             Cheers,
>             David
>
>
>                 Tony
>
>                     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
>         actual
>                     finalization
>                     cost may still be unacceptably high.
>
>                     Cheers,
>                     David
>
>                         Tony
>
>                             Afterall the key thing about GC is it
>         relieves the
>                             programmer from
>                             having to manage object lifetimes, so if you
>         don't
>                             know when the
>                             object is no longer used you don't know when
>         to call
>                             close.
>
>                             David
>
>
>