JEP 132: More-prompt finalization

[Srinivas Ramakrishna]

Ah, I see what you meant. Yes, there'd probably be some (theoretical)
overhead from such tracking,
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>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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120108/eb15576d/attachment.html