JEP 132: More-prompt finalization

[David Holmes]

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